Внутренняя регистрация против OpenID против Google Friend Connect против Facebook Connect против (и т. Д.)

Я пытаюсь решить, как разрешить пользователям регистрироваться на моем веб-сайте ... есть openID, clickpass, facebook connect, google friend connect и т. д. или старый добрый внутренний "введите имя пользователя, адрес электронной почты, пароль и т. д. "

Если коротко взглянуть на Как настроить OpenID , то кажется, что много работы openID работает.

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

Как всегда, спасибо за Ваш вклад.

22 голоса | спросил Sam 9 TueEurope/Moscow2008-12-09T05:53:41+03:00Europe/Moscow12bEurope/MoscowTue, 09 Dec 2008 05:53:41 +0300 2008, 05:53:41

6 ответов


0

Это действительно зависит от типа сайта и от того, кто ваши пользователи.

Мы рассмотрели возможность использования OpenID для нашего интернет-магазина (мы продаем одежду), и пришли к выводу, что мы упустим возможности для его реализации. Я ни в коем случае не самый умный разработчик программного обеспечения в мире, но если я едва смогу обдумать это достаточно, чтобы получить учетную запись для StackOverflow (почему я должен идти к какой-то третьей сторонний провайдер? Почему я должен им доверять? Что произойдет с моей учетной записью, если они подойдут? Как бизнес, что мне делать, если клиент просит меня изменить свой пароль?), тогда не просто анекдотично говорить, что наши клиенты будут есть проблемы с этим. Кроме того, для любого бизнеса электронной коммерции, как правило, неразумно брать на себя стороннюю зависимость, если она не будет тщательно продумана, и особенно для чего-то такого важного, как вход в систему. Если крупный поставщик OpenID потерпит неудачу, вы потеряете продажи. Если бы мы реализовали OpenID, это определенно была бы альтернативная, рыжая пошаговая реализация по сравнению с собственным механизмом входа.

Даже при нашей внутренней регистрации адресов электронной почты и паролей нам приходилось использовать форму входа в систему на стиле Amazon.com, потому что пользователи продолжали заполнять форму «новый клиент», даже когда у них уже была учетная запись:

  

Экран входа в систему. Экран входа в Amazon остается примером для подражания, сводя к минимуму общую проблему новых клиентов, которые пытаются войти в систему без регистрации. Amazon представляет два вопроса в линейном порядке: (1) «Какой у вас адрес электронной почты?» и (2) «У вас есть пароль Amazon.com?» По второму вопросу пользователи могут выбрать одну из двух переключателей: «Нет, я новый клиент» или «Да, у меня есть пароль». Многие другие сайты представляют разделы для новых и созданных пользователей бок о бок и, таким образом, перенаправляют новых пользователей в раздел для установленных пользователей посредством магнитного притяжения полей ввода. - Якоб Нисен, useit.com

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

Если вы внедряете социально-ориентированный веб-сайт, предназначенный для интеграции с Facebook или некоторыми из подкованных в Web-2.0 потребителей, то эти альтернативные механизмы аутентификации могут иметь смысл. Пока пыль не осядет на OpenID, я не буду добавлять ее на коммерческий сайт: никто не просил об этом. Они попросили PayPal и Google Checkout, которые мы внедрили, но там есть небольшое совпадение.

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

Просто мои два цента; надеюсь, это поможет.

ответил Nicholas Piasecki 9 TueEurope/Moscow2008-12-09T07:28:51+03:00Europe/Moscow12bEurope/MoscowTue, 09 Dec 2008 07:28:51 +0300 2008, 07:28:51
0

@ Николас имеет несколько очень хороших моментов.

Я рекомендую начать со стандартного имени пользователя /пароля и добавить OpenID и т. д. в качестве параметров позже, если их попросит достаточное количество пользователей (как в учебнике по Plaxo).

Всегда лучше иметь работающий сайт сейчас, а не проект, который становится консервированным с отметкой 90%. : -)

ответил devstuff 20 SatEurope/Moscow2008-12-20T09:24:22+03:00Europe/Moscow12bEurope/MoscowSat, 20 Dec 2008 09:24:22 +0300 2008, 09:24:22
0
  

Кратко рассмотрим, как настроить   OpenID, похоже, много работы для   заставить работать openID.

Это действительно не так много работы. Для проекта, который еще даже не близок к общедоступности, я скачал Dope OpenID и всего несколько У меня были часы (в основном потраченные на работу с CSS /HTML, которые мне очень не нравятся). Я настроил процедуру входа в систему, которая выглядит и работает так же, как и при входе в SO.

  

Например .. если вы разрешите оба   внутренняя регистрация и openID, что   процент ваших пользователей используют   OpenID?

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

Конечно, вы также можете предоставить обычный логин, но тогда вам все равно придется нести все хорошее, что OpenID снимает с ваших плеч. Не так страшно просить пользователей зарегистрировать учетную запись Gmail или Yahoo, которую они могут использовать, у большинства из них, вероятно, уже есть такая.

ответил Fredrik 22 J000000Wednesday09 2009, 23:00:34
0

Если вам потребуется сохранить информацию о состоянии ваших пользователей (предпочтения и т. д.), вам, вероятно, следует предоставить собственный механизм ввода имени пользователя и пароля. Это не мешает вам разрешить пользователям использовать OpenID и тому подобное. Вопрос, на который вам нужно ответить, состоит в том, сколько времени вы должны посвятить в своем проекте поддержке более чем одного метода. Как и во всех дизайнерских решениях, у всех есть свои издержки и выгода. Взвесьте их обоих и выберите ответ, который соответствует вашему бюджету.

ответил jmucchiello 9 TueEurope/Moscow2008-12-09T07:40:40+03:00Europe/Moscow12bEurope/MoscowTue, 09 Dec 2008 07:40:40 +0300 2008, 07:40:40
0

Другой возможный вариант, вместо того, чтобы самостоятельно разбирать код OpenID с помощью библиотек, - это использовать сервис SaaS, например RPX . Вы можете получить OpenID, Facebook & Вход в MySpace через пару часов. Ваше приложение просто должно иметь возможность создавать HTTPS и анализировать JSON или XML-адреса.

ответил ltd 9 TueEurope/Moscow2008-12-09T14:39:02+03:00Europe/Moscow12bEurope/MoscowTue, 09 Dec 2008 14:39:02 +0300 2008, 14:39:02
0

Я планирую сделать что-то похожее на моем сайте социальной сети, но немного по-другому, чем другие сайты. Большинство сайтов позволяют пользователям входить в систему с помощью этих сервисов, я планирую добавить эти сервисы в мою форму регистрации, затем они выбирают там сервис, openID, facebook connect, myspace ID, а затем я планирую получить всю информацию, которую предоставляют эти сервисы, и Сохраните их как переменную в моем php-скрипте, а затем сохраните в БД. Идея состоит в том, чтобы позволить им импортировать информацию из других сервисов при регистрации, чтобы облегчить их регистрацию, то есть меньше полей профиля, которые им придется заполнять позже такие

ответил JasonDavis 22 J000000Wednesday09 2009, 22:45:06

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132