OpenID. Как выйти из системы
На веб-сайте я внедрил логин, используя OpenID (на основе StackOverflow).
Но я не могу выйти из системы.
На моем хосте я могу выйти из системы, но когда пользователь снова попытается войти в систему (особенно с Google), аутентификация проходит, не требуя от пользователя ввода имени и пароля.
Как я могу указать поставщику OpenID, что пользователь больше не зашел на сайт?
Ответы
Ответ 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) Автоматически передавать эту информацию через перенаправление без паузы, чтобы запросить пользователя вообще.
Это функция, ориентированная на удобство.