Каковы плюсы (и минусы) использования «Войти через Twitter / Facebook» для нового сайта? [закрыто]

Я и мой друг собираемся запустить небольшой форум на сайте. Я рассматриваю возможность использования API-интерфейсов «Войти через Facebook / Twitter», возможно, исключительно (например, Lanyrd ), для входа пользователя. Я не использовал ни один из них раньше, ни сайт с пользовательскими логинами вообще.

Каковы плюсы (и минусы) этих API? В частности:

1. Какие преимущества я получаю как разработчик от их использования? Какие есть недостатки?

2. Действительно ли они нравятся / не нравятся конечным пользователям?

3. Были ли у вас какие-либо технические / логистические проблемы с этими API-интерфейсами?

Вот плюсы и минусы, которые я до сих пор получил:

Pros

• Удобнее для пользователя («зарегистрируйтесь» двумя щелчками, войдите одним)
• Возможно, нет необходимости поддерживать нашу собственную систему входа

 Cons

• Нет контроля над нашим процессом входа
• Исключить пользователей Facebook / Twitter, которые обеспокоены тем, что у нас есть какой-то доступ к их аккаунтам
• Аккаунты пользователей на нашем сайте скомпрометированы, если скомпрометированы их аккаунты в Facebook / Twitter.
• И если мы не поддерживаем нашу собственную альтернативную систему входа в систему:
  • Зависимость от Facebook / Twitter для нашей системы входа
  • Исключить не-Facebook / не Twitter пользователей нашего сайта

Против, я бы сказал, что пользователь может быть параноиком, что теперь они вошли на ваш сайт, используя свои учетные данные Facebook / Twitter, они считают, что у вашего сайта есть полный доступ ко всей их информации в соответствующих учетных записях.

Пожалуйста, не делай этого.

Многие люди, особенно те, которые не проживают в США, не будут иметь учетной записи Facebook и не создадут ее, помня все, что было сказано в отношении Facebook и его невежества в отношении конфиденциальности пользователей.

Вопреки тому, во что многие верят, есть много людей, которые счастливо живут без этих социальных шумов и мусорных сайтов и наплевать на них.

Зачем плевать им в лицо и отвергать их только потому, что они не поддавались массовой истерии под названием Facebook?

Другие моменты для рассмотрения:

1. Вы введете одну точку отказа, сделав ее зависимой от внешней системы. Если они решат закрыть свой OpenID или заставят вас заплатить за это, вы сильно облажались.

2. Они будут собирать данные о ваших пользователях, и кто знает, что с ними делать. По крайней мере, они будут использовать его в маркетинговых целях и в конечном итоге заработать на этом, и они не дадут вам кусок пирога.

3. Принимая их в качестве поставщика OpenID, вы будете и дальше поддерживать их квазимонополию и помогать им расти еще дальше. Делайте общественные работы и не вносите вклад в эту чуму.

Еще один минус: исключить пользователей не из Facebook и не из Twitter (или пользователей, которые просто не чувствуют себя в безопасности, обмениваясь информацией для входа на другие сайты). Или причинить им неудобства, заставив их создать внешнюю учетную запись. Мне лично не нравится идея единой точки отказа, что если кто-то получит мою регистрационную информацию в Facebook / Twitter, он может попасть на любой другой сайт, который использует ту же информацию. Но, возможно, я просто параноик.

Я вижу его в качестве опции , но вы потеряете много потенциальных посетителей, если вам потребуется логин FB или Twitter. Даже если у посетителей есть учетные записи FB, многие не захотят использовать их в целях конфиденциальности. Я, конечно, не хотел бы давать какой-то случайный сайт, идентифицирующий личность.

И вам все равно, вероятно, все равно понадобится какая-то форма системы отслеживания пользователей, так как вы можете отслеживать информацию о пользователе, связанную с вашим сайтом, такую ​​как настройки.

У сайта, который я часто посещаю, есть своя локальная система входа в систему / учетные записи пользователей, но пользователи могут при желании связать свою учетную запись с учетной записью Facebook. Таким образом, для тех людей у ​​них есть преимущества простого входа в систему, если они захотят, и никто не будет вынужден использовать логин Facebook, если они этого не хотят. Это работает довольно хорошо, я бы сказал.

Я играл с использованием OpenID, Facebook и Twitter для входа в систему. Однажды я просто тестировал его, и по какой-то причине я не мог войти через Facebook. Посмотрев страницу разработчика Facebook, я заметил, что их сервер API не работает. Так что это большой недостаток, когда пользователи не могут войти в систему, потому что у Facebook некоторое время простоя. У Twitter могут быть те же проблемы, что и у OpenID.

Это действительно зависит от вашего целевого рынка. Например, на некоторых целевых рынках проблема «исключить не пользователей» является крошечной (почти все пользователи имеют ее и с удовольствием делятся). В других это огромная проблема.

Вы можете увидеть это здесь в ответах: Программисты, как правило, очень осторожны с безопасностью и не хотят предоставлять доступ, поэтому все "НЕТ!" ответы :-p Нетехнические люди менее осторожны с этим.

Но очевидный ответ таков: используйте fb / twitter и вашу собственную систему, если можете. Тогда все счастливы.

У меня есть учетная запись Facebook, но когда я сталкиваюсь с сайтом, который хочет, чтобы я вошел в систему, используя его, я не могу. Если есть альтернативный метод, я буду его использовать. Если нет, то я действительно не хочу видеть, что находится на этом сайте. Я ненавижу ходить на сайты и видеть то, что другие друзья Facebook сделали на этом сайте, это жутко и навязчиво из-за вашей конфиденциальности (особенно когда я не заходил через Facebook или не сообщал сайту свою учетную запись Facebook).

Один из доводов состоит в том, чтобы делать это чисто так - как вы тестируете локально без сложных внешних зависимостей? Как вы настраиваете случайные тестовые аккаунты? Демо-счета? Учетные записи нечеловеческих пользователей? Как правило, вам нужна локальная схема аутентификации для покрытия этих перестановок, даже если большинство пользователей хранят учетные данные извне.

Самое главное - если у вас нет подключения к Интернету, вы даже не сможете взломать, а тем более сделать материальную работу над своим приложением. И, если у вас есть ошибки в аутентификации или авторизации, как вы можете быть уверены, что это не проблема Facebook / Twitter / Other oauth, если вы не можете запустить что-то простое и локальное, чтобы убедиться, что ваш код правильный?

Я бы сказал, что использование внешней системы входа в систему может работать очень хорошо - посмотрите, как openID мы использовали в stackoverflow и stackexchange. Преимущество велико: вам не нужно кодировать всю систему входа в систему, а это большой кусок исходной кодовой базы, которую вы можете просто проигнорировать, и у вас нет шансов ошибиться, и может позволить кому - то еще беспокоиться о том, какой пароль достаточно, как его сбросить, и так далее. И если у них где-то уже есть openid (либо из учетной записи в блоге, либо из той, которую они настроили для доступа к stackoverflow), им не нужно запоминать другую комбинацию имени пользователя и пароля.

Недостатки в том, что многие пользователи находят это немного запутанным и могут не захотеть создавать openid на внешнем сайте, если они еще не использовали его.

Использование входа в систему Facebook имеет все эти преимущества, а также возможность взаимодействия с их учетной записью Facebook, если они позволяют.

Недостатком является то, что если вы полагаетесь исключительно на Facebook, вы привязываете себя к ним: если Facebook когда-либо изменит свой API или забанит ваш сайт, или такие пользователи, как я, откажутся входить на сайт, который может делиться данными Facebook (кто известно, что он не очень осторожен, когда речь идет о том, чтобы не передавать эти данные другим компаниям). Обратите внимание, что IIRC, даже если на вашей странице есть ссылка «Мне нравится» или «Войти» на Facebook, позволит Facebook отслеживать, какие зарегистрированные пользователи просматривают ваш сайт, по принципу двойного щелчка.

Итак, я бы сказал:

• в идеале вы должны разрешить вход в систему с нескольких внешних сайтов: openID, facebook, google и т. д.
• если у вас есть форма для входа в Facebook, вы не можете поместить ее правильно на первой странице, показывайте ее только тогда, когда пользователи нажимают «войти в систему с помощью Facebook» (я никогда не буду жаловаться на возможность сделать это :)) ,
• Для начала решите, что вам быстрее всего настроить, учетные записи и пароли, или openID или что-то еще.
• Решите, стоит ли также добавлять учетные записи и пароли, если у вас есть внешний вход. (Но убедитесь, что у вас есть хотя бы пара внешних логинов)

Я, по крайней мере, настороженно отношусь к хедлайнерам социальных сетей, и особенно к Facebook за их либеральное пренебрежение к избирательному обмену информацией. Это недоверие усугубляет тот факт, что, казалось бы, подавляющее большинство приложений, с которыми я столкнулся, запрашивают всю мою информацию, а затем информацию обо всех, кого я знаю, для участия в контексте их приложений. Чушь. Государственные интервью для проверки безопасности требуют много информации, как и следовало ожидать, но даже близко не соответствуют тому, что «требует» ФБ. У меня есть аккаунт, но его запас, используемый только для основных функций.

При этом мне нравится федеративный идентификатор в концепции и на практике (например, openid и open auth в целом). Я думаю, что с использованием провайдеров, поддерживаемых основными провайдерами веб-почты, трудно спорить с точки зрения пользователя по нескольким причинам. Одно из очевидных преимуществ федеративного идентификатора (например, меньшее количество пар данных для входа в систему, которые нужно запомнить или иным образом управлять с помощью еще одного локального приложения для хранения информации о входе в систему или надстройки). Во-вторых, я доверяю своему провайдеру электронной почты выполнять довольно хорошую работу по защите моей личной информации (и, как следствие, моего почтового ящика) до тех пор, пока я выполняю свою часть работы по защите своих учетных данных (сила имени пользователя / пароль и разумный контроль воздействия).

Я мог бы рассмотреть других провайдеров федеративного идентификатора, но они должны быть убедительными, в соответствии с целью федеративного идентификатора.

Наконец, интеграция множества провайдеров не обязательно легка. Команда stackexchange недавно прокомментировала проблемы. Если бы я не был на мобильном устройстве, я бы сделал поиск для вас.

Мех, очевидно, я в другом лагере. Для меня концепция Facebook - это испытание временем. Возможно, это не будет Facebook в будущем, кто знает. Однако, выходя за рамки интересов теоретика заговора о конфиденциальности (вы можете контролировать свою конфиденциальность), я считаю, что этот вид услуг станет «утилитарным». Так как вы берете трубку, чтобы позвонить кому-то, вы выбегаете в свой почтовый ящик, чтобы забрать почту ... вы будете "Facebook" со своими друзьями, чтобы войти в контакт.

Мы уже испытываем значительно меньший почтовый трафик, потому что вместо этого люди «Фейсбук» друг с другом. Это только вопрос времени, но использование электронной почты будет продолжать сокращаться.

Кроме того, имейте в виду, что типы людей, которые вы хотите войти в вашу систему, вполне могут быть теми, кто будет иметь учетную запись Facebook. Те, кто этого не делает, как правило (по моему опыту), не собираются «участвовать» на вашем сайте в любом случае (или на любом другом сайте, если на то пошло).

Дело в том, что, будь то Facebook или нет, система, в которой каждый может мгновенно общаться с людьми, которых они одобряют, станет лучшим кандидатом в систему «единого входа» в Интернете. Вы не можете просто отклонить «регистрацию в 2 клика и вход без клика / 1 клик» как маленьких профессионалов, они ОГРОМНЫ!

Для людей, которые беспокоятся о конфиденциальности, что вы размещаете в своем профиле на Facebook, что может нанести ущерб в случае их использования? Почему ты это делаешь?

Мой голос (за то, что он стоит) это пойти на это! Стремитесь, полностью замените свою систему членства на систему только для Facebook. У меня есть, и моим пользователям это нравится .