Авторизация на поддомене

#php #javascript #авторизация

                    
Видел как некоторые сайты используют поддоменную авторизацию. То есть, например,
на поддомене login.example.com вешают куки, а уже на    example.ru/* проверяют... не
понятно, при каждом действии нужно переадресовывать на login.example.com и проверять??
Если нет, то как это происходит? И почему разработчики прибегают к поддоменной авторизации?
    

Ответы

Ответ 1

Дело в том, что стандарт мета-данных кукисов позволяет выставить разрешение на домен
2-го уровня и его поддомены, причём на все сразу .site.com (эквивалент *.site.com),
а не на конкретный, т.е. нет возможности через запятую или как-то иначе указать список
всех доменов на которых требуется авторизоваться. Выхода два, делать редирект на каждый,
передавая идентификатор сессии, либо иметь единую точку авторизации - некий proxy-домен.
Т.е. всё сводится к тому, чтобы передать идентификатор сессии на все желаемые домены/поддомены.

Алгоритм прост. К примеру:


Заходим в первый раз на сайт site.com - кук нет
Происходит почти незаметный редирект на login.site.com и если куки нет, то генерируем
сессию и устанавливаем куку на login.site.com.
Перередирект на site.com с идентификатором сессии в параметре URL-а (site.com?sid=<хеш>).
Уставнавиливаем куку с данным идентификатором для site.com.
Чтобы избавиться от идентификатора сессии в параметре URL-а делаем рефреш (т.е. редирект
на site.com но уже без параметра). Данная манипуляция необходима исключительно для
безопасности, чтобы, к примеру, случайно не засветить идентификатор в referer, ибо
пользователь может после авторизации перейти по ссылке на какой-нибудь сторонний сайт.
Кука установлена. Как только кука или сессия протухнет/будет удалена, вновь всё это
повторится.


Далее, допустим мы зашли на foo.site.com - кук нет.


Происходит редирект на login.site.com - кука есть.
Перередирект на foo.site.com с идентификатором сессии
...


Таким образом, именно login.site.com хранит базовую куку с идентификатором сессии
(вернее, хранилищем выступает кеш вашего браузера) и раздаёт её через редирект доверенным
доменам/поддоменам.

Преимущество данного подхода в том, что можно создать единых хаб авторизации для
доменов 2-го уровня. К примеру, google.com и youtube.com


Ответ 2

Так делают чтобы разгрузить основной сервер от авторизаций, особенно если авторизация
сложная.
Перенос кук используйте.

php

session_set_cookie_params(0, '/', 'www.example.com');
session_start();


.htaccess

php_value session.cookie_domain .example.com


Например у моего товарища авторизация проходит через супер-пупер криптосамописный
хеш. и время доходит до полусекунды причем сильно грузит серв. поэтому для авторизации
стоит отдельный серв, которому не страшны такие проседания.