-
Очевидно, что для того чтобы авторизовать пользователя, необходимо сравнить полученный от openId провайдера идентификатор с тем, который хранится в БД. Чтобы идентификатор совпадал при каждой авторизации, необходимо приводить его к определенному виду. И вроде бы этот вид в стандарте прописан. И даже даны примеры использования:
http://openid.net/specs/openid-authentication-2_0.html#normalization_example
Но вот что мне непонятно: отчего такое странное отношение к завершающему слешу после path? Или считается что openID провайдер обязан возвращать идентификатор всегда единообразно?
Сейчас я "на всякий пожарный" завершающий слеш "откусываю" у всех. Понимаю что не по стандарту, но как-то мне так спокойнее. Или может погорячился я с подобным решением? -
В примерах вроде бы всё логично.
http://example.com → http://example.com/Здесь у URL'а есть схема ("http") и хост ("example.com"). Но совершенно пустой путь. Он нормализуется до единственного слеша. Пункт 6.2.3 RFC 3986:
In general, a URI that uses the generic syntax for authority with an empty path should be normalized to a path of "/".
А вот здесь:
http://example.com/user → http://example.com/user... у URL'а есть нормальный путь ("/user"), и поэтому к нему ничего не добавляется.
Сейчас я "на всякий пожарный" завершающий слеш "откусываю" у всех.
К указанному непустому пути ничего добавлять или убирать нельзя, его формат — дело сервера, который этот путь обслуживает.
То есть вопрос не в "завершающем слеше", а в том, что путь должен быть непустой.
-
Это как раз выглядит достаточно логичным. Меня смущает вот эти два примера:
Они вроде как оба вполне валидны и ничего с ними делать не надо... пока мы не сталкиваемся в реальностью:http://example.com/user -> http://example.com/user
http://example.com/user/ -> http://example.com/user/
захожу на http://openid.yandex.ru/, авторизуюсь, после чего мне яндекс говорит буквально следуюшее:
Верю ему. Вбиваю эти данные в свой профиль на сайте, пытаюсь авторизоваться и что же я вижу:Вашим OpenID-логином является адрес:
http://openid.yandex.ru/user/
То есть яндекс мне показал один валидный URI, а серверу отдал другой (тоже валидный). В итоге если бы сервер действовал по стандарту, то авторизовать бы он меня не смог.Данный OpenId не зарегистрирован: http://openid.yandex.ru/user -
Ну это совсем другое дело. Есть правила в спеке, а есть конкретный случай какой-то. Возможно это баг в openid.yandex.ru, возможно в консумере. Но так происходить не должно. Вообще, каноническим URL'ом на openid.yandex.ru считается именно вариант со слешом на конце, и только он всегда и отсылается наружу.
На каком сайте это происходит?
-
Ой :-). Пока тестировал, с другого аккаунта запостил.
-
Прошу прощения - я сам себя перехитрил: сначала откусил слеш в конце, а потом себе же и продемонстрировал что получилось:)
Из-за чего я занервничал: у меня на сайте пользователь может ввести в профиле любое количество openid аккаунтов с которых он может авторизоваться. Чтобы не гонять его при заполнении профиля к провайдеру(ам), ему разрешается ввести свой идентификатор как он его знает/помнит. Отсюда и возникает проблема слеша на конце.
С другой стороны, ведь стандарт касается межсайтового взаимодействия, а своей базе я могу хранить данные как сочту нужным... Так что, быть может, и нет смысла в данном случае придерживаться стандартов? -
ему разрешается ввести свой идентификатор как он его знает/помнит. Отсюда и возникает проблема слеша на конце.
Не возникает :-). Сервер пользователя, если ему интересен точный вид URL'а, делает редиректы со всех псевдонимов на один правильный канонический адрес. Поддержка этого тоже явно прописана в OpenID. Соответственно при определении конечного URL'а вам надо при отработке редиректов (а их всё равно придётся отрабатывать) запомнить в качестве OpenID последний адрес, на который всё в итоге придёт.
Если речь идёт о Питоне, то это вот здесь:
from urllib2 import urlopen f = urlopen('http://example.com/user') cliamed_id = f.geturl() # <- конечный URL после редиректовХотя по-честному, лучше взять python-openid и отдать эту кухню ей.
С другой стороны, ведь стандарт касается межсайтового взаимодействия, а своей базе я могу хранить данные как сочту нужным... Так что, быть может, и нет смысла в данном случае придерживаться стандартов?
Вы ищете себе лишних проблем. А если пользователь решит начать вводить свой ID по-другому? Или точнее, это решит за него плагин его браузера. Весь этот процесс описан как раз для того, чтобы решать то, что вы и хотите: юзер может ввести любой эквивалентный URL, и он в итоге сведётся к одному каноническому. Как ещё вы хотите это реализовать?
-
Проблема не в том что пользователь ввел при авторизации - тут действительно произойдут редиректы и ID будет приведен к требуемому виду (хотя, например, mail.ru этого не сделает). Проблема в том, чтобы сравнить то, что хранится в базе (то что забито самим пользователем в профиле) с тем что приходит от провайдера. При заполнении профиля пользователь может не задумываться или не знать о тонкостях с наличием/отсутствием слеша...
-
Проблема в том, чтобы сравнить то, что хранится в базе (то что забито самим пользователем в профиле) с тем что приходит от провайдера.
А почему это расходится? Если пользователь забивает в профиль новый OpenID, его надо тут же проверять, и в результате этого получать от провайдера канонический URL, и его уже сохранять. Хранить ровно то, что ввёл пользователь, как-то незачем...
-
Звучит разумно, но как-то уж больно неудобно. А если пользователь вводит несколько openid? Кидать его туда-сюда по всем провайдерам? Тоже самое если он их будет изменять... А можно ли получить от провайдера канонический вид минуя аутентификацию? То есть прямо с сервера запросить провайдера и узнать у него в каком виде он бы отобразил такой-то id? Может есть такая возможность?
-
Звучит разумно, но как-то уж больно неудобно.
Ну это как бы обязательно. Иначе я введу себе чужой OpenID.
А если пользователь вводит несколько openid? Кидать его туда-сюда по всем провайдерам?
Давать добавлять один за раз.
То есть прямо с сервера запросить провайдера и узнать у него в каком виде он бы отобразил такой-то id?
Это не работает в случаях, когда юзер указывает весь сервер, а не свой персональный URL. Его придётся сгонять на его сервер, чтобы из факта его залогиненности тот понял, какой у него должен быть персональный URL и прислал его обратно.
-
Ну это как бы обязательно. Иначе я введу себе чужой OpenID.Ну и что?:) Кстати, любопытная идея - можно сделать "групповой" аккаунт, когда несколько человек сидят под одним ником но не используют общий пароль:)
Наверное, Вы правы. Стоит подумать в этом направлении.Давать добавлять один за раз. -
Ну и что?:)
Это риторический вопрос? :-). Потому что если нет, то зачем тогда вообще какая-то система пользователей на сайте, где каждый может представиться кем угодно?
-
Секундочку! Представиться не может - только дать другому возможность представится собой. Собственно, тоже самое он может сделать разболтав свой пароль при традиционной авторизации. Ну уж если он это делает, то он сам себе злобный Буратина:)
-
Представиться не может - только дать другому возможность представится собой.
Если я могу ввести любой OpenID, и меня при этом не гоняют на сервер проверить, действительно ли это мой OpenID, то это как раз и значит, что я могу представиться кем угодно.
-
Чтобы представиться - надо авторизоваться, а для этого придется прогуляться к провайдеру. Это как в банке - девушке операционистке можете наплести что угодно про свою личность, но для получения денег все равно придется предъявить паспорт:)
-
Понял... Тем не менее, не понимаю, зачем переизобретать то, что уже в общем-то устоялось: OpenID к аккаунту привязываются всегда через проверку, и нет никаких проблем с формой их написания.
-
Спасибо! Сделал с проверкой. Теперь должен быть полный дзен:)
-
А как обстоит дело с https идентификаторами? Тоесть ведь по сути:
http://username.ya.ru/ и https://username.ya.ru/ разные?
Внимание! Это довольно старый топик, посты в него не попадут в новые, и их никто не увидит. Пишите пост, если хотите просто дополнить топик, а чтобы задать новый вопрос — начните новый.