Авторизация на 2-х доменах

Iframe мом такое делал.
Года 1,5 назад здесь такую же тему создавал.
Не сказать чтобы совсем без тормозов работало, но работает.

Lisio, сейчас через куки каким образом происходит идентификация? Что хранится в куках для идентификации пользователя?

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

В общем из всего описанного стало ясно, что наиболее оптимальный вариант - при нажатии на ссылку другого языка сделать следующее:
1. Через аякс вызвать скрипт, который генерирует запись в БД с уникальным идентификатором (по типу md5), IP и авторизационными данными. На выходе - идентификатор.
2. Через js перейти на специальную страницу нового домена с параметром из п.1 и прописать в кукисы параметры пользователя из базы, удалив из базы эту запись и все, у которых срок давности больше минуты.
3. Редирект на главную страницу нового домена.

То, что Вы не приняли во внимание мое решение (100% работающее, ибо shared sessions является стандартным решением таких задач), означает, что Вы вообще не хотите использовать механизм сессий. Возможно, у Вас такая постановка задачи использовать лишь куки... Правильно ли я понял?

Ваше решение имеет несколько недостатков:
— Вы теряете всех пользователей, у которых отключены Cookies.
— Вы теряете всех пользователей, у которых отключен JS.
— Для генерации идентификатора Вы используете IP, тут тоже нужно учесть, что пользователь может сидеть на DHCP, и его IP адрес при следующем реквесте может быть уже другим.
— Вы очень сильно усложняете задачу, пишите много дополнительного нестандартного (тот самый костыль) кода, в том числе на клиенте, без которого можно обойтись.
— Как Вы правильно заметили, это очень непроизводительное решение. Лишний AJAX запрос (нужна еще проверка, вдруг запрос не пройдет корректно), генерация ключа, работа с БД, очистка проекспарившихся данных, и т.д. (нужно еще проверить, как Ваше решение будет себя вести, если пользователь будет часто менять язык туда-сюда, и прыгать с домена на домен).

По сути, Вы придумали свой собственный механизм сессий. Который давно уже реализован в PHP, уже лет 10 как, причем очень просто реализован, и очень надежно работает.

Ну ладно, если постановка задачи использовать только куки, и Вам нельзя или не хотите использовать PHP сессии (кстати, точно ли нельзя или не хотите? хотя бы лишь для этого случая создавать разовые сессии для переброса между доменами, что будет лишь несколько строк PHP кода и никакого яваскрипта?), немного позже подумаю решение, лишенное вышеуказанных недостатков (кроме первого, когда у пользователя отключены куки).
Но перед этим пожалуйста ответьте на вопрос, который frig в предыдущем посте задал. Если, конечно, хотите от меня мой вариант решения получить...

tvv, ваше предложение с сессией в самом деле интересно, как-то не вчитался сразу.

У всех этих вариантов все равно остается серьезный недостаток. Если человек прошел авторизацию на одном сайте, а потом зашел на второй не по ссылке - авторизация не проканает. Т.е. обязательно надо проходить по ссылке с одного сайта на другой, в любом другом случае (ссылка в избраном, переход из поисковика) вариант не прокатывает. С централизованной идентификацией будет работать и в этих случаях.

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

У всех этих вариантов все равно остается серьезный недостаток. Если человек прошел авторизацию на одном сайте, а потом зашел на второй не по ссылке - авторизация не проканает.

Ну почему же, не вижу проблемы.
Если поддерживать такую возможность, чтобы можно было заходить не по ссылке, то достаточно после успешной авторизации на одном из сайтов разово делать вызов некоего ресурса на втором сайте, который выставит те же куки (или тот же SESSIONID) для другого домена.

Пример:

1. Залогинились на сайте 1.
2. Показывается страница сайта 1, мол, welcome, вы залогинились.
3. При этом эта welcome страница разово включает в себя некий HTML код, который обращается к сайту 2. Например с картинкой: <img src="http://domain2.com/show_flag.php?SESSIONID=XXX">. XXX — это ID короткоживущей сессии, созданной на том сайте, где залогинились. Или iframe, если картинки выключены пользователем, и поддерживаются iframes. Или JS, если все вышеприведенное не поддерживается, но поддерживается JS, и т.д., способов много, например через CSS и т.д.
4. После этого с сайта 2 подгрузится фейковая картинка, например прозрачный png 1x1 или флаг страны (или другое, если мы выбрали не картинку, а другой ресурс), и установит нужные куки уже на второй домен.
5. Если клиент поддерживает JS, хорошо бы проверять, загрузилась ли картинка (ресурс). Если не загрузилась — повторить N раз. Если fail, то в другой раз повторим при следующей загрузке страницы на этом домене.

Конечно, после того, как куки установлены, эту картинку (или фрейм и т.д.) уже грузить не нужно, или же, если это, скажем, флаг страны, напрямую грузить саму картинку, не вызывая PHP.

Можно и без сессий обойтись, сделав велосипедик с куками. Но не суть, результат все равно будет — залогинились на сайте на одном домене, куки получили на всех задействованных доменах. Теперь можно переходить на другие сайты на других доменах как угодно, хоть линками, хоть вручную набирая в адресной строке браузера, хоть из букмарков.

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

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

По сути, Вы придумали свой собственный механизм сессий. Который давно уже реализован в PHP, уже лет 10 как, причем очень просто реализован, и очень надежно работает.

Насколько мне известно, уже лет как 5 активно ведется борьба с наличием идентификатора сессии в любых запросах, будь то GET или POST, как из эстетических принципов, так и принципов повышения безопасности.

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

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

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

Мне кажется, что надо объединять Ваш способ с моим, т.е. делать практически все как Вы описали, но передавать номер сессии через базу, используя временный идентификатор, как я описал. Это немного увеличит нагрузку на систему при входе, но полностью исключает возможность воровства PHPSESSID по вине портала. Как Вам такой вариант?

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

Если поддерживать такую возможность, чтобы можно было заходить не по ссылке, то достаточно после успешной авторизации на одном из сайтов разово делать вызов некоего ресурса на втором сайте, который выставит те же куки (или тот же SESSIONID) для другого домена.

Этот способ уже тут был описан и предложен. На мой взгляд одного только его достаточно для авторизации. Просто таким образом проставляем куки для всех нужных доменов и всего делов.
Цитата ("Lisio"):

как из эстетических принципов, так и принципов повышения безопасности.

так в куках то он все равно висит - от POST оно отличается не сильно по безопасности. Точнее если куки не передаются по шифрованному каналу, то не отличается никак.

Lisio,
Цитата ("frig"):

сейчас через куки каким образом происходит идентификация? Что хранится в куках для идентификации пользователя?

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

так в куках то он все равно висит - от POST оно отличается не сильно по безопасности. Точнее если куки не передаются по шифрованному каналу, то не отличается никак.

Передача в виде кукисов все-таки надежнее, чем раскидываться им налево и направо.

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

сейчас через куки каким образом происходит идентификация? Что хранится в куках для идентификации пользователя?

В кукисах хранится ID пользователя, и хэш пароля.

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

Передача в виде кукисов все-таки надежнее, чем раскидываться им налево и направо.

Чем кукисы надежнее POST-а?

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

В кукисах хранится ID пользователя, и хэш пароля.

жестяк, однако :o

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

Насколько мне известно, уже лет как 5 активно ведется борьба с наличием идентификатора сессии в любых запросах, будь то GET или POST, как из эстетических принципов, так и принципов повышения безопасности.

И совершенно верно, все правильно что такая борьба ведется.
Но в Вашем же случае идентификатор сессии будет не в каждом GET или POST запросе, а только в одном, один раз.
После этого данная сессия может удаляться, ибо она была создана только для разовой операции передачи данных между доменами.
К сожалению, данный способ будет уже сложнее, если доменов (языков) будет не два, а больше.

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

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

Да, именно так, согласен. Так же как и в Вашем случае может не сработать вызов JS с идентификатором по той же причине (или при медленном соединении может идти запрос более минуты, и ваш идентификатор проэкспарится, но это общая проблема).

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

Мне кажется, что надо объединять Ваш способ с моим, т.е. делать практически все как Вы описали, но передавать номер сессии через базу, используя временный идентификатор, как я описал. Это немного увеличит нагрузку на систему при входе, но полностью исключает возможность воровства PHPSESSID по вине портала. Как Вам такой вариант?

Если мы используем короткоживущие сессии только лишь для кроссдоменной передачи кук, то родной SESSIONID (SID, SESSION_ID, PHPSESSID, etc.) ничем не отличается от Вашего идентификатора с точки зрения безопасности. Так как Ваш идентификатор будет полностью соответствовать идентификатору сессии, и кража Вашего идентификатора приведет к тому же результату, что и кража SESSIONID.
Если же Вы планируете использовать сессии и вдругих случаях, то есть если они будут долгоживущими, тогда Ваш способ с идентификатором приемлем.

В общем, тут имеем классическую дилему. Простые способы реализации небезопасны, а безопасные способы (если учитывать все нюансы, включая медленные соединения, возможность отсутствия поддержки кук, картинок и JS на клиенте, возможность кражи идентификаторов из URL например из логов, и т.д.), к сожалению, или сложны, или добавляют свои ограничения.

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

Frig
+отличная мысль

как Вы думаете что о сайте подумает яндекс??

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

как Вы думаете что о сайте подумает яндекс??

мы будем авторизировать яндекс? сомнения у меня есть на этот счет...

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

— Вы теряете всех пользователей, у которых отключены Cookies.
— Вы теряете всех пользователей, у которых отключен JS.

да и фиг с ними. менее 0.2%

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

мы будем авторизировать яндекс? сомнения у меня есть на этот счет...

а сайт слишком будет отличаться для зареганых от незареганных?

ArtPro, там будет отличаться переключение языка. Если переключение языка для неавторизированного пользователя, то это просто переход по ссылке. Если для авторизированного, то уже надо передать этого пользователя ухищрениями.

Пытался реализовать двумя, практически аналогичными между собой, способами: через iframe и через img. В обоих случаях стабильно работает в Firefox и Chrome, а в остальных браузерах не срабатывает. Подозреваю, что из-за внутренней безопасности самих браузеров. Какие варианты еще можно придумать?

Lisio, там заголовки надо проставлять для отмены этой безопасности. Там что-то типа "P3P: и тут много букв"
Если интересно, покопаюсь в архивах.

А этот вариант не подойдет: ссылка

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

Если интересно, покопаюсь в архивах.

Если не сложно...

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

А этот вариант не подойдет

Именно его я и реализовал, но он получился не кроссбраузерным.

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

Именно его я и реализовал, но он получился не кроссбраузерным.

А в каких не работает?

ссылка
ссылка

тестил на Опере, Хроме, ФФ и IE