Изменен параметр DotNetOpenAuth ClaimedIdentifier? Что следует хранить в базе данных для идентификации пользователей

Question

Существует немало вопросов, таких как this и this, которые, как утверждается, должны использоваться для однозначного определения каждого пользователя.

После успешного входа в систему я сохраняю ClaimedIndentifier в базе данных. Всякий раз, когда пользователь входит в систему, я просматриваю свои записи в поисках ClaimedIdentifier. Однако я заметил, что ClaimedIdentifiers меняются. Что я должен хранить в базе данных для идентификации моих пользователей. Я использую учетную запись Google. Это, как я извлечения его хранения в базе данных

OpenIdRelyingParty rp = new OpenIdRelyingParty(); 
IAuthenticationResponse r = rp.GetResponse(); 
UserController.addUser(new UserController.User(r.ClaimedIdentifier.ToString(), 0)); 

Answer 1

Это не DotNetOpenAuth уникальный вопрос. Это поведение Google. Провайдер OpenID от Google выдает то, что называется идентификаторами попарно-уникальных. Они всегда будут одинаковыми для данного пользователя , пока ваша область OpenID постоянна.

Если вы регистрируете пользователей без явного предоставления области DotNetOpenAuth's OpenIdRelyingParty.CreateRequest, DotNetOpenAuth просто использует корневой URL текущего веб-приложения. Это разумное значение по умолчанию, за исключением того, что если ваш сайт доступен более чем одним способом (например, http и https, или с именем хоста www и без него), чем область по умолчанию будет зависеть от URL, который пользователь использовал для использования перейдите на страницу входа в систему. И когда область меняется, так же генерируется заявленный идентификатор Google.

Исправление затем, для вас, чтобы выбрать один область (желательно с схемой HTTPS, если это опция) и явно поставить его в метод CreateRequest. Вы также должны убедиться, что аргумент return_to для того же метода имеет общий корень с выбранным вами царством. Например, если область, которую вы выберете: https://www.mysite.com/ Затем вы должны убедиться, что на основе этого return_to. Что-то вроде: https://www.mysite.com/login.aspx

Если пользователя просматриваемые в http://mysite.com/login.aspx, что будет URL по умолчанию для return_to, который не будет соответствовать области, который вы выбрали.

Так в целом, это может выглядеть следующим образом:

var request = relyingParty.CreateRequest(
    "https://www.google.com/accounts/o8/id", 
    "https://www.mysite.com/", 
    new Uri("https://www.mysite.com/login.aspx")); 

Обратите внимание, что ваш return_to делает не должны быть точно так же с каждым запросом как область делает. Таким образом, у вас может быть несколько URL-адресов для входа в систему, и каждый из них укажет свой собственный URL как параметр return_to. Но все URL-адреса return_to должны быть основаны на URL-адресе области.

С учетом того, что изменения постоянно применяются везде, где вы разрешаете пользователям регистрироваться, вы должны увидеть согласованные идентификаторы из Google. К сожалению, заявленные идентификаторы, которые вы уже получили в других сферах, не будут соответствовать тем, которые вы получите после этого исправления. Если вам нужно объединить эти учетные записи пользователей, и если у вас есть адреса электронной почты для пользователей, вы можете попробовать слияние на основе этого. Но будьте очень опасаются этого шага. Это можно сделать только безопасно, если вы уверены, что адреса электронной почты, которые у вас есть, принадлежат этим пользователям. Если вы получили эти адреса электронной почты через OpenID, когда пользователи вошли в систему, и дважды проверили, что это было от доверенного поставщика OpenID, и вы проверяете электронные письма, то вы, вероятно, все в порядке. Обратите внимание, что только жесткий код Google OP Identifier в CreateRequest делает не гарантирует, что в систему войдут только пользователи Google.Чтобы убедиться в этом, вам пришлось бы проверять, что свойство IAuthenticationResponse.Provider.Uri соответствует https://www.google.com/accounts/o8/ud, когда приходит положительное утверждение.