Одна сессия на несколько доменов

Можно ли сделать такое?
К примеру есть два сайта на разных доменах, но, предположим, на одном хостинге.
Возможно ли как-то "синхронизировать" сессии? Например, логинимся на одном, переходим на второй, оказываемся там уже залогинены. Выходим на втором, и на первом тоже автоматов оказываемся незалогинены ? Надеюсь понятно объяснил.. Сессии можем хранить как в БД так и в файлах..

Реализуемо ли это? Может что-то надо ковырнуть в httpd.conf или php.ini ?

Не мучится и юзать кукисы плюс общую БД.

Хмм. общая БД... да, забыл сказать что БД для этих сайтов как раз общая.
А кукисы разве действительны не только для того домена , с которого были поставлены ?

Политика безопасности не позволит устанавливать куки для другого домена от имени первого.

Вариант -- писать в БД ID сессии, user-agent, ip-адрес юзера и проверять при заходе на "второй" домен. Но это не очень безопасно.

Тогда давайте еще раз уточним насколько все таки разные это сайты? если это субдомены одного домена - это вообще не проблема.
Если же совсем разные - надо будет "выпендриваться" - красивого решения нет
Цитата ("ossadchy"):

Вариант -- писать в БД ID сессии, user-agent, ip-адрес юзера и проверять при заходе на "второй" домен. Но это не очень безопасно.

Да это вообще дыра.

Сайты такие.. Хостинг один, база одна, домены разные, код разный (и дизайн сответственно). Домены обычные - второго уровня.

В такой ситуации возникает вопрос: а зачем это надо? ибо все действия по решению этой задачи пробьют большую дыру в безопасности вашей системы.

Сделать один сайт основным, второй его субдоменом и переход со второго доменного имени через алиас :?:

Цитата ("raznomir"):

Сделать один сайт основным, второй его субдоменом и переход со второго доменного имени через алиас :?:

и что? куки потеряются...

Да вот и спрашиваю что да как.. Предполагал, что на крайняк, может тонкой настройкой сервера это решается..

Суть в том что ID сессии(как правило в куках) хранится на стороне КЛИЕНТА. Так что сервер тут ничего не решает.

Ни один браузер не будет отдавать сайту Б куки сайта А.

Мы такое решали редиректом на скрипт глобальной авторизации, он ловит куку на своем домене, авторизует и редиректит юзера обратно.
Соответственно, куки ставит тоже только GlobalAuth.
Т.к. база одна - проблем больше никаких.

Цитата:

и что? куки потеряются...

Есть "умный" алиас, когда куки не теряются... я как-то нашел чела, что продавал такое решение по $5
Цитата:

Ни один браузер не будет отдавать сайту Б куки сайта А.

В случае субдоменов - браузер и не покидает сайта А, хотя пользователю можно "светить", что угодно.
Цитата:

Мы такое решали редиректом на скрипт глобальной авторизации

По сути это тоже дыра - ибо проанализировать запрос и "подменить" вообще-то не сильно сложно.

Цитата ("raznomir"):

Цитата:

и что? куки потеряются...

Есть "умный" алиас, когда куки не теряются... я как-то нашел чела, что продавал такое решение по $5
Цитата:

Ни один браузер не будет отдавать сайту Б куки сайта А.

В случае субдоменов - браузер и не покидает сайта А, хотя пользователю можно "светить", что угодно.

1. не знал, интересно
2. ну речь-то о доменах, насколько понимаю.

Цитата ("Demiurh"):

Мы такое решали редиректом на скрипт глобальной авторизации, он ловит куку на своем домене, авторизует и редиректит юзера обратно.
Соответственно, куки ставит тоже только GlobalAuth.
Т.к. база одна - проблем больше никаких.

ну вроде более-менее нормальное решение... единственно что лишний редир при заходе на сайт

Решение 1:
После авторизации на сайте А, выдаём страничку с невидимыми iframe-ми. Содержимое каждого фрейма - с других доменов, где требуется авторизация. Т.е. каждый фрейм запрашивает скрипт, который ставит свои авторизационные куки (можно просто ид. сессии) от имени своего домена. Так как страница запрошена с одного домена, а содержимое фреймов пытается ставить куки со своих доменов, то чтобы такое было возможно, при отдаче "главной страницы" надо послать P3P-заголовок:
P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"

Решение 2:
После авторизации пользователя на сайте А, пользователь редиректится на сайт Б с параметрами, содержащими ид.сессии и url возврата (или ид. url-а возврата). Авторизационный скрипт, видя, что есть такие параметры, ставит нужные куки и редиректит пользователя обратно, или дальше по цепочке доменов.
Это решение не годиться, если в цепочке есть и http и https - соединения: в этом случае IE6 выдаёт алерт с предупреждением о перенаправлении на небезопасное соединение.

Оба решения испробованы, всё работает.

Не проще использовать OpenID ?

Цитата ("RUSYA"):

Не проще использовать OpenID ?

Человек логиниться со своим OpenID на сайте А, поддерживающем эту технологию, ходит по нему.
Потом он заходит на сайт В, также поддерживающий OpenId... Думаете он оказывается залогиненным на нём? Нет!
Он может и там залогиниться со своим OpenID, но требуется то не это!