является ВКонтакте.заявленный id статический?
Я читаю о Федеративный вход для пользователей учетной записи Google чтобы выяснить, как я могу иметь вход пользователя в веб-приложение, используя свою учетную запись Google.
таким образом, к концу процесса Google возвращает идентификатор, предоставленный Google, который добавляется как openid.claimed_id. Это означает, что веб-приложение использует этот идентификатор для распознавания пользователя и предоставления доступа к функциям и данным приложения. Мой вопрос в том, является ли этот идентификатор статическим? Могу я это использовать? идентификатор, чтобы повторно идентифицировать одного и того же пользователя?
3 ответов
да. Рассмотрим ВКонтакте.значение claimed_id имени пользователя. Особенно с Google, но это верно для любого провайдера OpenID, который действительно реализует "направленную идентификацию", не считает это имя пользователя коррелируемым с другими веб-сайтами. Любая другая полагающаяся сторона, кроме вашего собственного веб-сайта, получит другое значение claimed_id для того же пользователя Google по дизайну.
кроме того, не забудьте обработать этот claimed_id как регистр.
конкретный ответ на ваш вопрос находится в Googles OpenID API документация:
идентификатор Google, который не имеет никакого отношения к фактическому имени учетной записи или паролю пользователя Google, является постоянным значением; он остается постоянным, даже если пользователь изменяет свое имя пользователя Google и/или адрес электронной почты. Этот идентификатор также является "направленным идентификатором", то есть Google возвращает разные значения каждой проверяющей стороне. Google использует запрос параметр openid.realm распознает полагающуюся сторону, поэтому, если стороннее приложение решит изменить это значение, все идентификаторы пользователей будут изменены.
фактически, я только что столкнулся с экземпляром, где google claimed_id изменился для моего тестового пользователя. Я заканчивал реализацию OpenID в своем приложении, и по какой-то причине claimed_id в данных ответа был изменен.
Я тестировал с этой учетной записью в течение последних нескольких недель, и claimed_id был таким же все это время, как и ожидалось. А потом-бац! Я много раз просматривал данные ответа для проверки и базовый код для извлечения данные не изменились.
Я не уверен, как справиться с этим на данный момент, но я думаю, что это собирается накинуть на меня петлю. После первоначальной проверки подлинности пользователи регистрируются на сайте (как и следовало ожидать) и настраивают экранное имя. Как мы можем проверить, что это тот же пользователь, если claimed_id изменился? Мы, конечно, не можем использовать адрес электронной почты, в соответствии с лучшими практиками.
редактировать
теперь у меня есть пирог в моем лице! Я упустил одну маленькую деталь, которая обернулась в крупных деталях. Я меняю среду разработки и размещаюсь на другом v-хосте. Это эффективно изменяет область, и это изменит ответ claimed_id в соответствии с документами.
Это был хороший урок для меня, так как я собирался реализовать OID на поддомене, в котором realm автоматически устанавливался в моем коде. Теперь я избавил себя от головной боли по дороге, потому что я не смог бы использовать ту же пользовательскую базу данных во всех других поддоменах не нарушая идентичности.
ПОДРОБНЕЕ
просто в качестве примечания-даже если вы разрабатываете решение OpenID для одного из ваших поддоменов, было бы разумно указать realm для вашего домена верхнего уровня.
например, openid.realm = http://*.yourdomain.com
Это позволит вам расширить страницу входа во все ваши поддомены и сохранить идентификатор пользователя их.
(опционально), заверенные царство. Определяет домен, который заканчивается пользователя просят доверять. (Пример: "http://*.myexamplesite.com") Это значение должно соответствовать домену, определенному в openid.return_to. Если этот параметр не определен, Google будет использовать URL, на который ссылается openid.return_to.