Должен ли я поддерживать «mysite.com» и «www.mysite.com»? Проблемы с OpenID?

Question

Я реализовал поддержку OpenID для веб-приложения ASP.Net 2.0, и на моем локальном компьютере все работает нормально.

Я использую библиотеку DotNetOpenId. Перед перенаправлением на сторонний веб-сайт я сохраняю оригинальный OpenID в сеансе, чтобы использовать его при аутентификации пользователя (я полагаю, что это стандартная практика).

Однако у меня есть привычка не вводить www при вводе URL-адреса в адресную строку. Когда я тестировал логин на работающем сервере, у меня возникали проблемы, когда сеанс очищался. Мой обратный URL был жестко запрограммирован как www.mysite.com.

Возможно ли, что переключение с mysite.com на www.mysite.com привело к переключению сеанса?

Другая проблема заключается в том, что www.mysite.com не относится к области mysite.com.

Каково стандартное решение этих проблем. Должен ли сайт автоматически перенаправлять на www.mysite.com? Я мог бы просто сделать мою ссылку на страницу входа абсолютным URL-адресом, содержащим www? Или они просто скрывают другую проблему?

Answer 1

Решить проблему области, которую вы упомянули, легко. Просто установите область * .mysite.com вместо mysite.com. Если вы используете один из элементов управления ASP.NET, включенных в библиотеку, вы просто устанавливаете свойство для элемента управления, чтобы установить область. Если вы делаете это программно, вы устанавливаете свойство объекта IAuthenticationRequest перед вызовом RedirectToProvider ().

Что касается проблемы сессий / файлов cookie, связанной с переключением между именем хоста www и не www, у вас есть два варианта:

1. Вместо сохранения исходного идентификатора в сеансе, что в любом случае является плохой идеей по нескольким причинам, используйте метод IAuthenticationRequest.AddCallbackArguments (name, value) для хранения введенных пользователем данных, а затем используйте IAuthenticationResponse.GetCallbackArgument (name) чтобы вызвать данные после аутентификации пользователя.
2. Забудь об этом. Есть причина, по которой библиотека dotnetopenid не сохраняет эту информацию автоматически для вас. Направленная идентификация - это всего лишь один сценарий: если пользователь вводит yahoo.com, вы, вероятно, не хотите говорить ему «Добро пожаловать, yahoo.com!». а лучше «Добро пожаловать, id.yahoo.com/andrewarnott»! Единственный способ получить правильное поведение - это использовать свойство IAuthenticationResponse.FriendlyIdentifierForDisplay, чтобы решить, что отображать пользователю в качестве его идентификатора, вошедшего в систему. Он дает более точную информацию и проще, чем сохранять значение в обратном вызове и возвращать его. :)

Answer 2

Файлы cookie, сеансы и все остальное теряются между сайтами www.site.com и site.com. У меня недостаточно терпения, чтобы полностью прочитать все спецификации, но http://www.w3.org/Protocols/rfc2109/rfc2109 утверждает, что

A является строкой полного доменного имени и имеет вид NB, где N - непустое имя строка, B имеет вид .B ', а B' строка FQDN. (Итак, x.y.com совпадает с доменом .y.com, но не y.com.)

Обратите внимание, что сопоставление доменов не является коммутативная операция: a.b.c.com доменные совпадения .c.com, но не задний ход.

Я думаю, это означает, что да, вам нужно переслать на www. Я всегда добавлял код исправления домена на свои сайты, когда используются файлы cookie и сеансы.

Answer 3

Я не знаю, как работает OpenID, но LiveID дает вам токен, основанный на комбинации пользователя и домена. Я бы просто отправил www на mysite.com.