Comments
OpenID не имеет никакого отношения к SSO (Single Sign On или по русски авторизация одновременно на нескольких сайтах/доменах). Проблемы изложенные в моем посте относятся именно к SSO.
Простите за может быть странный вопрос, но каковы цели создания SSO и как хорошо от этого будет пользователю?
Наш проект перерос себя и мы выделяем разделы в одельные подроекты на своих доменах.
Авторизовавшись на одном нашем проекте, вы авторизовались сразу на всех.
UFO landed and left these words here
UFO landed and left these words here
А если нет то что? Как мы запомним что тест не прошел? Вариант с сохранением ip?
UFO landed and left these words here
Роботы не могут отправлять POST-запросы (спецификацией запрещено), поэтому об этом можно не беспокоиться.

Огромный минус второго варианта: какая-то картинка может не загрузиться и выход не произойдёт. Аналогично и со входом, но с выходом хуже последствия.
UFO landed and left these words here
К сожалению редирект у нас идет GET-ом: 307 Temporary Redirect. Постом сделать можно только с помощью JS я предполагаю.
Я надеюсь вы понимаете что должен быть редирект броузера, а не внутренний запрос, иначе как вы получите куки из броузера на домене сервера авторизации.

Минуса тут нет никакого, вы удаляете сессию и привязку в базе юзера к сессии. Поэтому при переходе на домен у которого не загрузилась картинка, мы обратимся к базе и увидем что нету привязки к ид пользователя и просто удалим куку.
Я не понимаю тогда зачем вы беспокоитесь о роботах. Или у вас сайт с гостевым доступом, где можно при желании авторизоваться, тогда редирект не нужен (будет ссылка «войти», которая указывает на сервер авторизации), или у вас сайт только для зарегистрированных, и тогда сразу редирект на сервер авторизации, а роботы как неавторизованные ничего не получат.
Я писал в начале, что сайт не иммеет открытых/закрытых зон, то есть сайт не только для зарегистрированных.
Авторизовавшись на одном проекте, вы авторизовываетесь сразу на всех.
Вариант 1, авторизация:
1) Зачем шифровать и передавать URL, HTTP_REFERER недостаточно?
2) Может все-таки передавать только логин + зашифровынный (необратимо) пароль и сравнивать хеш?
3) Зачем редирект на самого себя, почему сразу не отправить то что нужно через POST, чтобы ничего потом не очищать?
1) Реферер на совести броузреа — его может не быть. Мы можем подсунуть любой реферер какой хотим. Некоторые прокси сервера обрезают этот заголовок.
2) Нам нужно чтобы наш токен протухал (действовал только для текущего реквеста), иначе его смогут постоянно использовать злоумышленники.
3) Оставлять страницу после поста — дурной тон. Пользователь нажмет F5, ему предложат отправить заново, и так как токен уже протухнет у нас будет коллапс.
И почему кошмар с роботами? Это какие такие роботы будут у вас на сайтах авторизироваться?
Вы меня не правильно поняли, в первом варианте я говорю о проблеме авторизации по кукам. Вы залогинились и кука поставилась на домене site1.com и сервере авторизации. Вы зашли на другой наш проект site2.com. Там кука не стоит. Чтобы поднять авторизацию вас автоматически редиректит на сервер авторизации и проверяется есть ли кука, если есть то идет обратный редирект и ставится кука на site2.com. Вы авторизованы. Если куки не принимаются, то редирект будет происходить каждый ваш реквест на site2.com.
есть такая штука как CROWD от фирма Atlassian. Как раз по этой теме. пользуемся им для всех наших порталов внутри компании.
Я так понимаю что доступ к ресурсам порталов только для зарегистрированных пользователей. Тоесть при входе всегда спрашивается логин. Я писал что варианты интранета я не рассматривал, так как наши проекты имеют публичный доступ.
Хм… помоему все забыли про такую вещь как фреймы, просто вставляем нужные нам сайты в фреймы и авторизуемся, передавая данные во фрейм и всё. Авторизация происходит сразу на всех сайтах, то есть куки создаются прямо на сайтах с их доменными именами и проблем нету.
Точно! Вообщем это аналогичное второму варианту решение, но лишенное недостатка отключенных картинок в броузере и не надо колдовать с заголовками при отдаче картинок.
Правда ифреймы могут блокироваться экстеншенами броузера, которые занимаются безопасностью и рекламой.
делаю авторизацию по первому варианту. Все хорошо, но возникла проблема
Когда пользователь не авторизирован, он получает куку со значением no_auth и больше на сервер авторизации браузер не ходит. Когда пользователь авторизируется, допустим, на другом сайте а потом перейдет на исходный то он не будет авторизирован потому как у него есть кука, а у нее висит значение no_auth. Я установил время жизни куки с no_auth на 5 минут, но это не решение проблемы а только «костыль»
Может я что-то делаю не так изначально?
Only those users with full accounts are able to leave comments. Log in, please.