Я считал другие вопросы, и они главным образом говорят о безопасности выполнения так. Это - не полностью мое беспокойство, главным образом потому что веб-сайт является вопросом, игра на базе браузера. Однако большей проблемой является пользователь - не, каждый пользователь является достаточно грамотным для понимания OpenID. Верный RPX делает это довольно легким, который является тем, что я буду использовать, но что, если у пользователя нет учетной записи в Google или Facebook или что бы то ни было, или не доверяет системе для входа в систему с существующей учетной записью? Они должны были бы добраться, учетная запись в другом обеспечивают - я уверен, что большинство будет знать, как сделать это, уже не говоря о быть побеспокоенным, чтобы сделать это.
Существует также проблема того, как управлять ею в приложении. Пользователь мог бы хотеть использовать несколько идентификационных данных с единственной учетной записью, таким образом, это не столь просто как имя пользователя + пароль для контакта с. Как я храню идентификационные данные OpenID пользователя в базе данных? Используя OpenID приносит мне пользу также: RPX может предоставить обширную информацию о профиле, таким образом, я могу просто предварительно заполнить форму профиля и попросить, чтобы пользователь отредактировал как требуется.
У меня в настоящее время есть это:
Users:
------
ID Email Etc.
-- --------------- ----
0 bob@yahoo.com ...
1 alice@yahoo.com ...
UserOpenIDs:
------------
ID UserID OpenID
-- ------ ------
0 0 0
1 0 2
2 1 1
OpenIDs:
--------
ID Provider Identifier
-- -------- ----------------
0 Yahoo https:\\me.yahoo.com\bob#d36bd
1 Yahoo https:\\me.yahoo.com\alice#c19fd
2 Yahoo https:\\me.yahoo.com\bigbobby#x75af
С этими внешними ключами:
UserOpenIDs.UserID -> Users.ID
UserOpenIDs.OpenID -> OpenIDs.ID
Это - правильный способ сохранить идентификаторы OpenID в базе данных? Как я соответствовал бы идентификатору, который RPX дал мне с одним в базе данных для входа в систему пользователя (если идентификатор известен).
Таким образом, вот конкретные вопросы:
Делаем его доступным
Первое, что касается пользователей, у которых нет OpenID, вы можете создать небольшую страницу, которая объясняет, как создать учетную запись (или даже указывать на некоторых провайдеров). Таким образом, создать учетную запись OpenID не сложнее, чем обычную учетную запись.
Для людей, которые не хотят использовать OpenID, у вас есть два варианта. Первый: внедрить старый стиль входа в систему рядом с вашим именем входа OpenID и позволить пользователям выбирать, какой метод они хотят. {{1} } Во-вторых, иметь только OpenID ... это упрощает вашу работу. Сказать, что некоторые пользователи больше доверяют веб-сайту, чем проверенному провайдеру OpenID для входа в систему, на мой взгляд, довольно странно, поскольку провайдеры OpenID часто используют зашифрованные соединения и т. д.
Хранение в базе данных
Схема, предложенная johnny g , - это то, что вам нужно. (Я просто не знаю, зачем вы храните URL-адреса с обратной косой чертой вместо косой черты)
Вы можете нормализовать свои URL-адреса перед их использованием, чтобы избежать таких вещей, как http://openid.test.com/abc и http: // openid.test.com/abc/ обрабатывается как разные URL-адреса.
Дополнительные меры, которые необходимо предпринять
Нет. Вам следует просто использовать библиотеку из http://openid.net/developers/libraries .
Подтверждение личности пользователя - проблема провайдера. Только пользователь и веб-сайт знают пароль к учетной записи.
Если у кого-то есть ваш URL-адрес OpenID (который является общедоступным) , ему все равно понадобится пароль (или другой способ аутентификации, например сертификат SSL), чтобы иметь возможность войти в систему.
{ {1}}Аргумент, опровергающий мой предыдущий комментарий выше.
На ваш третий вопрос «меры ...чтобы кто-то не мог войти в систему как другой пользователь ... ", насколько я понимаю OpenId, вы никогда никогда не принимаете URL OpenId из ненадежного источника. При реализации на вашем сайте размещается логин провайдера, сайт провайдера связывается с вами напрямую , поэтому вы всегда принимаете URL OpenId с надежного сайта.
Другими словами, даже если злонамеренный пользователь собирает OpenId, например Pokemon, у него нет средств для доступа к вашей системе.
На ваш второй вопрос «как мне хранить ...» ваша схема будет работать, хотя она выглядит немного расслабленной. Например, при использовании сопоставления «многие ко многим» [например, UserID to OpenID
]] вы разрешаете пользователю принадлежать ко многим OpenId, а один OpenId - ко многим пользователям. Вы хотите, чтобы первое было без второго.
Достаточно простого ограничения внешнего ключа.
UserID Email
------ ---------------
86000 bob@yahoo.com
86001 alice@yahoo.com
UserID Identifier
------ ----------------
86000 https:\\me.yahoo.com\bob#d36bd
86000 https:\\me.yahoo.com\bigbobby#x75af
86001 https:\\me.yahoo.com\alice#c19fd
Provided UserID
- это внешний ключ для таблицы Users
, и существует ограничение уникального ключа для идентификатора
, это означает по существу заявляет, что Пользователь
владеет нулем или несколькими уникальными идентификаторами
. В принципе, я бы, наверное, тоже наложил первичный ключ на эту таблицу, но это подливка.
Надеюсь, это поможет :)
PS если у вас есть сомнения по поводу интеграции или использования OpenId, выполните реализацию. Определите каждый бит источника, который принимает URL-адрес OpenId, а затем спросите себя, может ли злоумышленник получить доступ к этой точке входа. Я надеюсь, что есть только одна такая точка входа, и она недоступна для всех, кроме доверенных провайдеров OpenId.
Я заметил один ответ на первый вопрос:
Если пользователь не может или не хочет использовать OpenID, сотрудничайте с существующим провайдером и регистрируйте их прямо на сайте, или станьте провайдером сами (хотя это означает наличие классических учетных записей с именем пользователя и паролем, и как бы упускает суть вопроса -> использование только OpenID).