Comments 27
Возмите OpenID сервер и примените его :)
UFO just landed and posted this here
UFO just landed and posted this here
Роботы не могут отправлять POST-запросы (спецификацией запрещено), поэтому об этом можно не беспокоиться.
Огромный минус второго варианта: какая-то картинка может не загрузиться и выход не произойдёт. Аналогично и со входом, но с выходом хуже последствия.
Огромный минус второго варианта: какая-то картинка может не загрузиться и выход не произойдёт. Аналогично и со входом, но с выходом хуже последствия.
UFO just landed and posted this here
К сожалению редирект у нас идет GET-ом: 307 Temporary Redirect. Постом сделать можно только с помощью JS я предполагаю.
Я надеюсь вы понимаете что должен быть редирект броузера, а не внутренний запрос, иначе как вы получите куки из броузера на домене сервера авторизации.
Минуса тут нет никакого, вы удаляете сессию и привязку в базе юзера к сессии. Поэтому при переходе на домен у которого не загрузилась картинка, мы обратимся к базе и увидем что нету привязки к ид пользователя и просто удалим куку.
Я надеюсь вы понимаете что должен быть редирект броузера, а не внутренний запрос, иначе как вы получите куки из броузера на домене сервера авторизации.
Минуса тут нет никакого, вы удаляете сессию и привязку в базе юзера к сессии. Поэтому при переходе на домен у которого не загрузилась картинка, мы обратимся к базе и увидем что нету привязки к ид пользователя и просто удалим куку.
Я не понимаю тогда зачем вы беспокоитесь о роботах. Или у вас сайт с гостевым доступом, где можно при желании авторизоваться, тогда редирект не нужен (будет ссылка «войти», которая указывает на сервер авторизации), или у вас сайт только для зарегистрированных, и тогда сразу редирект на сервер авторизации, а роботы как неавторизованные ничего не получат.
Вариант 1, авторизация:
1) Зачем шифровать и передавать URL, HTTP_REFERER недостаточно?
2) Может все-таки передавать только логин + зашифровынный (необратимо) пароль и сравнивать хеш?
3) Зачем редирект на самого себя, почему сразу не отправить то что нужно через POST, чтобы ничего потом не очищать?
1) Зачем шифровать и передавать URL, HTTP_REFERER недостаточно?
2) Может все-таки передавать только логин + зашифровынный (необратимо) пароль и сравнивать хеш?
3) Зачем редирект на самого себя, почему сразу не отправить то что нужно через POST, чтобы ничего потом не очищать?
1) Реферер на совести броузреа — его может не быть. Мы можем подсунуть любой реферер какой хотим. Некоторые прокси сервера обрезают этот заголовок.
2) Нам нужно чтобы наш токен протухал (действовал только для текущего реквеста), иначе его смогут постоянно использовать злоумышленники.
3) Оставлять страницу после поста — дурной тон. Пользователь нажмет F5, ему предложат отправить заново, и так как токен уже протухнет у нас будет коллапс.
2) Нам нужно чтобы наш токен протухал (действовал только для текущего реквеста), иначе его смогут постоянно использовать злоумышленники.
3) Оставлять страницу после поста — дурной тон. Пользователь нажмет F5, ему предложат отправить заново, и так как токен уже протухнет у нас будет коллапс.
И почему кошмар с роботами? Это какие такие роботы будут у вас на сайтах авторизироваться?
Вы меня не правильно поняли, в первом варианте я говорю о проблеме авторизации по кукам. Вы залогинились и кука поставилась на домене site1.com и сервере авторизации. Вы зашли на другой наш проект site2.com. Там кука не стоит. Чтобы поднять авторизацию вас автоматически редиректит на сервер авторизации и проверяется есть ли кука, если есть то идет обратный редирект и ставится кука на site2.com. Вы авторизованы. Если куки не принимаются, то редирект будет происходить каждый ваш реквест на site2.com.
есть такая штука как CROWD от фирма Atlassian. Как раз по этой теме. пользуемся им для всех наших порталов внутри компании.
Хм… помоему все забыли про такую вещь как фреймы, просто вставляем нужные нам сайты в фреймы и авторизуемся, передавая данные во фрейм и всё. Авторизация происходит сразу на всех сайтах, то есть куки создаются прямо на сайтах с их доменными именами и проблем нету.
oAuth может подойдет?
делаю авторизацию по первому варианту. Все хорошо, но возникла проблема
Когда пользователь не авторизирован, он получает куку со значением no_auth и больше на сервер авторизации браузер не ходит. Когда пользователь авторизируется, допустим, на другом сайте а потом перейдет на исходный то он не будет авторизирован потому как у него есть кука, а у нее висит значение no_auth. Я установил время жизни куки с no_auth на 5 минут, но это не решение проблемы а только «костыль»
Может я что-то делаю не так изначально?
Когда пользователь не авторизирован, он получает куку со значением no_auth и больше на сервер авторизации браузер не ходит. Когда пользователь авторизируется, допустим, на другом сайте а потом перейдет на исходный то он не будет авторизирован потому как у него есть кука, а у нее висит значение no_auth. Я установил время жизни куки с no_auth на 5 минут, но это не решение проблемы а только «костыль»
Может я что-то делаю не так изначально?
Вопрос конечно интересный. Я написал новый топик с результатами наших изысканий habrahabr.ru/blogs/webdev/80900/
Предлагаю продолжить дискуссию там.
Предлагаю продолжить дискуссию там.
Sign up to leave a comment.
Межсайтовая авторизация (SSO)