Web: авторизация в двух доменах.

OpenID

Так всё равно юзеру придётся на обоих доменах авторизоваться. Это ничем не лучше обычной авторизации. База-то пользователей (и сервер вообще) - одна.

ajax ?

Как вариант — хранить сессию в URL-е и по Referrer-у вытаскивать.

Хотя, имхо, кривая структура. Домены как раз предназначены для полностью независимых сайтов. Почему не сделать просто /site1/ и /site2/

>ajax ?

Он на JavaScript. JavaScript не имеет доступа к данным чужих доменов ни на чтение, ни на запись.

>Как вариант — хранить сессию в URL-е и по Referrer-у вытаскивать.

Мысль. Надо обдумать с точки зрения безопасности.

>Почему не сделать просто /site1/ и /site2/

Исторически и идеологически так сложилось :)

...

На самом деле доменов даже три. А может и больше будет, если придумаю оптимальную систему авторизации (могут ещё пара сайтов присоединиться в систему).

Спасибо за наводку. Кажется придумал. Хоть и без сессий.

При логине делаем временный ключ и дёргаем с ним в iframe все вторичные хосты. Они по этому ключу проводят авторизацию в своих доменах. Ключ потом грохается.

Точно также решается и вопрос разлогинивания сразу со всех хостов.

Всё прозрачно для юзера и без извратов на стороне сервера.

iframe - зло.

>Через JavaScript к данным чужих доменов доступа нет

На самом деле не совсем так. А вообще посмотри на тему client-side mashup. Вкратце есть варианты: тег <script>, махинации с iframe (в dojo есть реализация вроде как), server-side.

мне кажется, если существует одна база юзеров и данных на двух совершенно независимых доменах, то что-то с этим идеологически не так. можно ведь было сделать хотя-бы "forum.localhost.com" и "blog.localhost.com", прописав домен в сессии == ".localhost.com". чем обусловлено полное разделение?

>чем обусловлено полное разделение?

Я уже говорил, вопрос исторический. Авиационная тусовка, скажем, испокон веку сидит на forums.airbase.ru, игроки Lineage2 - на la2.balancer.ru, разработчики L2Fortress - на la2.wrk.ru. Заставлять их всех переезжать на другой адрес - негуманно :) А если, скажем, ещё присоединится testpilot.ru?

Как вариант:

Делаем какой-то домен типа auth.balancer.ru

При первом заходе в домен, когда куков не найдено, редиректим на auth.balancer.ru

Он, в свою очередь, генерит временный SID, сохраняет в базу, и редиректит обратно, добавляя его GET-параметром.

Соответственно целевой домен получает этот SID, ищет по нему в базе соответствующего юзера, вешает клиенту куки (session_start()) и сносит временный SID из базы.

хм, да просто прикручиваешь какие-нить SSID и USER_NAME и хранишь в бд SSID и время последнего действия, чистишь его каждый 30 минут(бездействие) ... USER_NAME для того, что бы проверить тот ли это пользователь .. SSID хэш - ip, имени, пароля ....

>хм, да просто прикручиваешь какие-нить SSID

Э... Пачкать URL параметрами не хочется. Другого способа передать SID одного домена в другой нет. Так что, ИМХО, реален только вариант с iframe. Его и буду делать.

кукисы ... но вот скрытые ифреймы для добавления кукисов все равно пригодятся ...

Дополнительные параметры в урле нужны только один раз в момент первого входа на домен за сессию.

>Дополнительные параметры в урле нужны только один раз в момент первого входа на домен за сессию.

Не прокатит. Статическая страница, на которую юзер может попасть первым делом, залогинившись предварительно на другом домене, ничего к URL подставлять не сможет.

Т.е. должна работать такая схема:

1. Юзер логинится на первом домене.

2. Он открывает статическую страницу на втором, где уже должен быть залогинен.

...

Кроме варианта с IFrame на первом домене, который (iframe) и будет дёргать нужную страницу второго, ничего не прокатывает в этом случае.

А посмотрите как у гугла сделано. там ведь тоже одна форма авторизации на все домены.

>1. Юзер логинится на первом домене.

>2. Он открывает статическую страницу на втором, где уже должен быть залогинен.

> Кроме варианта с IFrame на первом домене, который (iframe) и будет дёргать нужную страницу второго, ничего не прокатывает в этом случае.


1. Юзер логинится на первом домене. Скажем aaa.ru

2. Он открывает статическую страницу на втором, где уже должен быть залогинен. Скажем bbb.ru

3. Скрипт, отдающий страницу (пусть и статическую - а что делать, логику всё равно придется писать), обнаруживает что данная сессия не авторизована для доступа к ресурсу, а в реферрере - адрес хоста aaa.ru, с которого пришёл юзер и возвращает редирект на некий well-known ресурс, представленный на любом ссылающемся хосте, скажем http://aaa.ru/remote_login.php?url_requested=http://bbb.ru/page_x.html

4. http://aaa.ru/remote_login.php процессит результат и возвращает имя юзера, как-то им подписанное, посредством опять же редиректа на
http://bbb.ru/login_from_remote_and_redirect.php?url_requested=http://bbb.ru/...

5. login_from_remote_and_redirect.php на bbb.ru проверяет signature, авторизует сессию для пользователя v_pupkin и снова редиректит на изначально запрошенный ресурс http://bbb.ru/page_x.html


В принципе, можно сделать и в форме апачевского модуля.