Подтвердить что ты не робот

OpenID. Как выйти из системы

На веб-сайте я внедрил логин, используя OpenID (на основе StackOverflow).

Но я не могу выйти из системы. На моем хосте я могу выйти из системы, но когда пользователь снова попытается войти в систему (особенно с Google), аутентификация проходит, не требуя от пользователя ввода имени и пароля.

Как я могу указать поставщику OpenID, что пользователь больше не зашел на сайт?

4b9b3361

Ответ 1

OpenID аутентифицирует пользователей на вашем сайте, а затем запускает сеанс на вашем сайте. Вы уничтожаете или аннулируете сеанс вашего сайта отдельно из сеанса пользователя с помощью своего поставщика OpenID.

Пользователь посещает joewidgets.com > Пользователь входит в систему с OpenID (с новым или существующим сеансом провайдера) > ... Пользователь нажимает logout > joewidgets.com уничтожает/отменяет сеанс.

Если у пользователя есть свой провайдер OpenID, они будут входить в систему, и ваша система автоматически проверяет, то он создаст новый локальный сеанс. (Un), к счастью, вы не можете/не можете беспокоиться о том, что пользователь делает или не делает у своего провайдера, что является pro/con OpenID.

Существует аргумент Социальная губная помада, которая требует "Single Sign Out", но OpenID в настоящее время не предоставляет эту функцию.

Ответ 2

Это называется Single Logout или Single Sign-Out, который OpenID не поддерживает. На мой взгляд, SSO без выхода из системы - большая дыра в безопасности. Выйти из одного сайта не означает многого, если другие могут просто войти с несколькими щелчками мыши.

На данный момент мы должны помнить поставщика. Если это кто-то знает, мы запускаем процесс выхода из системы. Для Google URL-адрес:

https://www.google.com/accounts/Logout

Выходной поток является уродливым, но он выполняет задание.

Ответ 3

Как правило, что-то обрабатывается провайдером OpenID - например, если пользователь остается включенным в свою учетную запись Google и установил флажок, чтобы "запомнить" авторизацию OpenID для вашего конкретного сайта, поставщик будет прозрачно регистрировать их и перенаправлять их обратно без отображения приглашения для входа.

Ответ 4

"Это не ошибка"

Поставщик идентификаторов может выбрать, чтобы пользователь разрешал провайдеру с помощью куки файлов, а также может не требовать повторного запроса пользователю о том, чтобы использовать ту же информацию, которая была ранее предоставлена ​​(с подсказкой). Поэтому, когда пользователь на сайте А, просящий авторизоваться через сайт B и перенаправленный, на сайте B сначала попросил пользователя проверить его подлинность. Затем сайт B спросил, следует ли ему предоставлять какую-либо информацию (а иногда и какую информацию) на сайте A. На этом этапе также будет обычно задаваться вопрос, хотите ли вы автоматически передавать эту же информацию в будущем. Некоторые провайдеры предпочтут "да", некоторые нет, некоторые не спросят. Затем сайт B переадресовывает на сайт A и делится информацией, теперь вы вошли в систему.

Если сайт A выполняет второе перенаправление на сайт B для запроса логина, сайт B может 1) Уже есть cookie, который аутентифицирует текущего пользователя сайта B. 2) Уже есть запись о том, какая информация приемлема для совместного использования с сайтом B. 3) Автоматически передавать эту информацию через перенаправление без паузы, чтобы запросить пользователя вообще.

Это функция, ориентированная на удобство.