Как стать автором
Обновить

Комментарии 61

НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Чем плохо? Зачем?
НЛО прилетело и опубликовало эту надпись здесь
Форма находится в iframe и постит сразу на сервер авторизации. Там мы авторизуем. Понятно. Вместо одного POST и двух GET мы делаем один POST и один GET — это хорошо. Но сможем ли мы из iframe перезагрузить страницу? Допустим сможем (google так вроде делает). Есть одна проблема — уникальный дизайн каждого проекта.
Это последне о чём надо думать. Можете хранить дизай формы на сервере авторизвции и в зависимости от параметров её отрисовывать, можете js'ом передавать шаблон формы во фрейм (наверно предпочтительно), можете подгружать .css в фрейме с адреса site1ru или site2.ru по выбору…

Пока писал, подумал, что всё что я написал — говно!
Заполняется форма, посылается аяксом во фрейм — всё готово и никаких редиректов и т.п.
Ну во первых, JS-ом у вас не получится поменять дизайн формы во фрейме — политика безопасности броузеров вам не даст.
Во вторых подгружать CSS тоже не вариант — может отличаться верстка (у нас она сильно отличается).
А вот послать форму в фрейм можно только с помощью JS (причем ajax тут не причем). Следовательно, если отключен JS, залогинится не получится.

Лишний GET — не такая большая проблема мне кажется. Хотя, действительно при определенных обстоятельствах iframe подойдет и можно его избежать.
Мне кажется, что если страничка породила фрейм и пока ни она, ни фрейм не рефрешились, то доступ есть…
Но можно и от противного пойти, пусть страничка на сервере авторизации дёргает сервис на site1.ru, который отдаст шаблон формы, но это что-то нездоровое.

Про аякс не совсем верно написал, или послать аяксом или засобмитить форму во фрейм (как при js аплоаде), потом прочитать что получилось.
послать форму в фрейм можно и средствами HTML без JS — смотрите атрибуты @action и @target на форме.
Отлично, это другое дело.
Я так и написал, что ИЛИ аяксом ИЛИ засобмитить
Ну если он ее украдет, то да. Но эта проблема решается добавлением времени и проверкой на устаревание этой строчки.
А это, на самом деле, зависит от деталей реализации. Ни чего не мешает связать с сессионой кукой еще и IP адрес. Если кука приходит не с ассоциированного адреса, то запрос считается не авторизованным. Да, конечно у пользователей с динамическим IP это может вызвать некоторые неудобства, но: 1) повышение уровня безопасности неизбежно приводит к некоторым ограничениям или неудобствам; 2) любой современный браузер представляет механизмы хранения логина и пароля; 3) сейчас, по сравнению с ситуацией этак 3-4 года назад, все больше и больше пользователей с реальными статическими адресами.

Ну и понятно, что это не спасет от перехвата на последней миле за натом. Но тут уж сфера влияния провайдера.
Лучше использовать User Agent
Нет. User Agent обычная текстовая строка, установить её значение в какую либо желаемую величину не проблема. Уж если злоумышленник смог увести куку, получить User Agent клиента труда не составит.
В статье автор наврное хотел рассказать об аутентификации, а не об авторизации, что разные вещи.
Я так понимаю, что то, о чем идет речь, непременно пересекается с такими понятиями как Claims-based Authorization, Federated Authorization, Security Token Service и всем таким подобным. Стоит погуглить на эти темы, решения подобной проблемы уже давно придуманы.
Вот если бы все эти понятия назывались как-нибудь попроще их бы поскорее находили и не изобретали велосипедов :) Сенкс фор йор коммент!
Ну вот с этим точно не поспоришь :) Насчет названий.
Так-так-так! Куки guest однако портит всю малину.

1) Допустим я зашел на site1 и логиниться не стал. Кука guest появилась
2) После этого перешел на site2 и залогинился
3) Возвращаюсь на site1, кука guest есть и как следствие я остаюсь незалогиненным
сколько она живет, как с ней работать и вообще?

Хочу чтобы стейт залогиненности был на всех доменах одинаковым.
С выходом тоже проблема есть:
1. Зашёл на site1, залогинился
2. Зашёл на site2, там меня узнали
3. Вышел на site1
4. На site2 кука осталась и сессия поднята

Это если я правильно понял где какая кука из статьи.
На самом деле, не вполне ясно какая кука «Сессионная», а какая просто «cookie».
Может если их называть site-cookie и sso-cookie понятней станет? То же с «поднята сессия».
Вы не правы, читайте внимательнее. Я писал выше, что хранилище сессий общее для всех проектов (используем memcached). При нажатии на кнопку «выход» мы удаляем сессию и связь ID пользователя к ID сессии, следовательно на site2 остается кука, которая при первом посещении будет удалена.
«Доступ к хранилищу сессий и к базе есть у каждого проекта.»

Проморгал, да.
Это я упустил, спасибо.

В голову пока приходить вообще отказаться от куки guest, что приведет к тому что пустой JS с сайта sso.com будет вставляться всегда. Меня лично это нисколько не пугает.
Давайте на государственном уровне создадим сайт sso.com, логины к нему будем выдавать по паспортам — проблема анонимности в сети решена :)

Это я так, одно из применений статьи в голову пришло.
а openID разве не так же работает?
имеется ввиду что принципы очень схожи. Тогда не проще ли использовать ту же методику без написания мегасложностей, т.к. велосипед-то придуман. Единственная разница будет в том, что мы ограничим потенциальные идентификаторы одним ресурсом
Хочется чтоб как в гугловых штуках.

Залогинился в гмыло. После этого ходишь по гридерам, гдоксам и тд а там ты уже залогинен. Потом гденить в одном месте залогофился и везде залогофился.

У гугла все на одном домене висит. А хочется сделать кросс-доменно.
Именно, причём аутентификацию (отправку на сайт провайдера и обратно) производить в фоне, чтобы пользователь её не замечал в случае удачи.
OAuth переизобрели?
Хотя не совсем, наверное…
Они изобрели SAML )))
Мы ничего не изобретали. У нас есть специфические особенности и нету задачи передачи профиля пользователя, а также желания гонять груду XML. Есть задача организовать только SSO и только. Брать для этого такую через чур усложненную (и не особо удачную по моему мнению) махину, как SAML я не вижу смысла.
Не совсем, но я тоже подумал именно о нем ;)
Единожды залогиниться на sso.com, и в других сайтах от него через OAuth получать доступ (как на куче сервисов вокруг twitter).
НЛО прилетело и опубликовало эту надпись здесь
Яндекс использует серию редиректов, что создает проблему с ботами и пользователями с отключенными cookie. Я описывал этот метод в первом посте.
Гм, а зачем ботам видеть требующие авторизации страницы, я не понимаю? А на cookie полагаются многие механизмы авторизации, и по умолчанию они в браузере включены, так что если кто-то их отключил — ССЗБ. Ну можно конечно проверять cookie и выводить сообщение об ошибке, если делать нечего.
Читайте внимательнее. На сайтах авторизация не обязательна. Нету четко разделенных зон. Авторизовавшись, пользователь получает доступ к дополнительному функционалу.
А если регистрация не обязательна, при чем тут «серия редиректов» в Яндексе? И как это может помешать ботам? Они что, не умеют обрабатывать заголовок Location?
Похоже вы запутались. Яндекс использует серию редиректов чтобы подцепить авторизацию. Посетите проект их проект moikrug.ru. Вы увидете что броузер сначала пойдет на pass.yadnex.ru (сервер авторизации), чтобы проверить есть ли кука.
Проверил moikrug.ru, если руками отправлять GET-запрос, получаешь 200 и страницу. Вы где-то ошиблись, видимо. Это во-первых.

Во-вторых, не понимаю, почему робот не может пройти туда-обратно через редирект, что тут страшного.

Видимо по User Agent проверяет бот вы или нет. Зайдите через броузер, увидете в строке статуса что сначала на pass.yandex.ru.

Ну так получается что каждый реквест на ваш сайт — редирект на сервер авторизации и обратно.
Юзер-агент моего скрипта — «Mozilla/5.0 (compatible; Googlebot/ 2.1; +http://www.google.com/bot.html)». Видимо, они поменяли схему авторизации и отказались от Single Sign On.

Это не может не радовать, так как, все эти схемы SSO создают проблемы, например, одно время при переходе из Google Reader на livejournal перекидывало на форму логина, неудобно было. Мне не нравятся такие мутные решения.
В основном все поисковые роботы ходят по локейшен (в обратном случае ваш сайт не будет индексироваться). Google к примеру босает это дело по 10 редиректа. Следовательно если вы хотите чтобы боты индексировали ваш сайт, то вам надо определять их и не делать редиректов за кукой. Я это подробнее описывал в предыдущем посте.
Иногда _лучше_ жевать
А почему у Вас сессия и пара user_id и session_id хранятся раздельно?
Не правильнее ли храня сессию в базе, хранить в одной таблице все? И user_id и session_id, и параметры сессии (ключ-значение)
Мы храним сессии в memcached.
> вставляем javascript файл c sso.com в начале страницы.

Не годится. Зачем javascript для авторизации? Незачем. Плохое решение.
Ваше заявление похоже на заявления из серии «вася лох». Пора уже начинать аргументировать.
Чем больше технологий вы задействуете, тем более ненадежной и сложной становится система. Яваскрипт тут даром не нужен, авторизация производится выставлением сессионной куки — а ее проще поставить сервером. Все, собственно.

Я уж молчу, о том, какое это уродливое решение: перезагрузка страницы яваскриптом или яваскриптовый редирект. Редирект делается (имхо) выставлением кода ответа 3** и заголовка Location, и никак иначе (почему — не помню точно, но вот как минимум одна причина: если вы захотите прочитать страницу сайта роботом, даже робот поймет, что это редирект, а в случае с яваскриптом/мета-редиректом — подумает, что ему отдали страницу, ведь у нее код ответа 200).

Также, я не понимаю, чем вам не угодили OpenID и OAuth? Лучше взять их и чуть-чуть поменять, чем лепить неудобный велосипед, строго полагающийся на наличие JS к тому же. В них ти другому человеку проще разобраться, они проверены на наличие уязвимостей сообществом, есть готовые библиотеки для работы с ними.
p.s. И с какого это перепоя при неправильной авторизации вы куда-то редиректите? Логичнее всего снова вывести форму с сообщением об ошибке и предложением попробовать еще раз.
Я как раз и делаю редирект на форму с выводом ошибки. Читайте внимательнее.
Вы какую-то ерунду пишете. У меня создается впечатление, что вы не поняли о чем идет речь.

При чем тут редиректы. Есть два варинта получения куки с сервера авторизации: серия редиректов и JS. Варинат с JS наиболее прозрачный для пользователя. Читайте внимательно первый пост.
Ну я понял, тут загвоздка именно в Single Sign On, чтоб работало без участия пользователя. Судя по тому, что аккуратного решения нет, это дурная вещь, от которой надо избавляться :)

Или, как вариант, всех пользователей без специальной куки — не оправлять на страницу авторизации автоматом, а считать разлогиненными.
А про проект Internet2 — shibboleth слышали?
Что-то слышал. Вы пробывали?
Чем не устроили готовые решения? Какие рассматривали? Я осваиваю weblogin.org, чем он вам не подошел? Очень актуальная для меня сейчас тема.
Вы о OAuth и SAML? Они показались чересчур перегруженными. Я выше в комментариях описывал. Weblogin.org не рассматривал, но судя по списку фич — это еще тот монстор.
JoSSO, OpenSSO, OAuth, SAML — реально работают. OAuth ничуть не сложнее описанной схемы.
и где это работает?
есть живые примеры, поддерживаемые распространенными серверами модули или это только планы на будущее?
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории