Помощник
|
Мультисайт |
Den1xxx
|
Сообщение
#1
|
||
|
|
||
|
|||
Arks |
24.7.2013, 10:02;
Ответить: Arks
Сообщение
#2
|
|
Как передать данные сессии между разными доменами Доменами? что-то не понял. Серверами? Memcached, Redis и т.п. Что такое транспорт я тоже не понял, обычно делают либо односторонний адаптер который позволяет Сайт2 обратиться к API Сайт1 и пройти аутидентификацию, либо двухсторонний адаптер - т.е. выносят авторизацию/регистрацию и т.п. в отдельный сервис. Ну а так curl+разделяемые сессии вполне подойдут. Если сервер 1 то можно их хоть в дефолтных файлах хранить разницы 0, если серверы разные то в файлах не выйдет. Как конкретно - curl ломится на адрес логина сайт1 с данными введенными пользователем на сайт2. Если ответ положителен - то по полученному в ответе SSID читается сессия в которой уже по идее лежат все данные пользователя сформированные авторизацией сайт1 + разумеется дальше передается клиенту в исходном виде, чтобы он считался авторизованным на сайт1. Но не через сайт1 т.к. у нас сайт2 разумеется, а через сайт2 на который будет ломиться сайт1 впоследствии. Но простейший вариант по-моему это редирект сделать. сайт2 => сайт1 пип-пип-пип авторизация... сайт1 => сайт2 profit... Можно авторизацию проходить в IFRAME, можно через всякие чудо-штуки типа кросдоменных запросов, можно дождаться принятия RFC про XDC(cross-domain-cookies) :) В общем цели и задачи у всех разные поэтому способы тоже. |
|
|
http:// |
24.7.2013, 12:24;
Ответить: http://
Сообщение
#3
|
|
А перенос таблицы с пользователями не реален? Зачем геморой с сессиями, понять не могу.
|
|
|
Den1xxx
|
Сообщение
#4
|
|
Но не через сайт1 т.к. у нас сайт2 разумеется, а через сайт2 на который будет ломиться сайт1 впоследствии. Но простейший вариант по-моему это редирект сделать. сайт2 => сайт1 пип-пип-пип авторизация... сайт1 => сайт2 profit... И как отслеживать на сайте2 что например этот пользователь не просто авторизован, а имеет такие-то права? Склоняюсь к мысли что оба сайта должны сделать авторизацию через единый сервис (коннектиться к одной БД). Серверы разные, если что. Иначе задача была бы проста. А перенос таблицы с пользователями не реален? Неправильный подход, т.к. после переноса таблицы будут разные пользователи региться на разных сайтах. Синхронизировать как-то придется. |
|
|
A1ex_hb |
24.7.2013, 12:54;
Ответить: A1ex_hb
Сообщение
#5
|
|
Можно сделать для сайтов одну базу данных, потом подредактировать код сайта 1, чтоб куки были видны для сайта 2.
Если авторизация работает через сессию, придется переделывать алгоритм или создавать api. |
|
|
Arks |
26.7.2013, 2:01;
Ответить: Arks
Сообщение
#6
|
|
потом подредактировать код сайта 1, чтоб куки были видны для сайта 2. Просвети нас, что где подредактировать чтобы куки с html.by были доступны для arks-cool-hacker.by Den1xxx, куки сайты должны устанавливать очевидно самостоятельно если не прибегать к кросс-доменной авторизации на клиенте с преферансом и домохозяйками. Сессия предполагает что все что должно быть расшарено доступно всем бэкендам, если речь идет о правах - они должны быть также в этой расшаренной сессии. Общая БД - как-то не тянет на кроссдоменную авторизацию. Смысл кроссдоменной авторизации в том что есть некий cross-домен на котором происходит авторизация, а все прочие домены за счет сервисов получают с него информацию. Простейший вариант с редиректом не катит - ну ладно, придумай свой велосипед с клиентской кросс-доменной авторизацией. На самом дее это несложно если отойти от базовых понятий "сессий" с их SESSIONID и пользоваться token'ами которые уже могу вести на сессию. |
|
|
Den1xxx
|
Сообщение
#7
|
|
Общая БД - как-то не тянет на кроссдоменную авторизацию. Смысл кроссдоменной авторизации в том что есть некий cross-домен на котором происходит авторизация, а все прочие домены за счет сервисов получают с него информацию. Ну я склоняюсь к следующей структуре. Оба сайта имеют свою БД одинаковой структуры. Движки одинаковы. Но у сайта2 при обращении к таблице users происходит обращение к БД сайта1. Т.о. всё вроде должно быть просто и прозрачно? Логины, пароли и др. инфа будут совпадать, но куки будут устанавливаться не синхронно на обоих сайтах, ну и фиг с ним. Интересно можно ли сделать синхронный вход при такой структуре. |
|
|
ZhukV |
28.7.2013, 0:44;
Ответить: ZhukV
Сообщение
#8
|
|
Е народ, стоп, посмотрите как гугли работает :)
Делается совсем просто: Вариант №1: (Более простой, но и функций на нем мало будет). 1. Делаем домен для аутенфикации. К примеру: security.domain.com там же и рега и т.д. 2. Когда пользователю нужна аутенфикация, направляем на домен аутенфикации, на котором потом насильно устанавливаем куку на совсем отдельный домен. А если кто-то подзабыл, что можно и домен указывать на куке, то вот, мануальчик: http://php.net/manual/ru/function.setcookie.php О варианте - REST API, cURL, вообще забудьте, угробите только систему полностью, и не важно, в каких сетях будут сервера. Вариант №2. Более правильный, очень сильно функционален, но сложный. На отдельном сервере создаеться система для хранения пользователей, инфы о них и т.д. Не важно, на чем оно будет работать, БД, Монго, Редис.... Под все это клепается библиотека, которая связывается с этим сервером и достает всю инфу, после чего эта библия подключаеться на все сервера. Во время написание библии необходимо полностью контролировать скорость соединения с другим сервером. Желательно использовать сокетные соединения в самой системе, а не на уровне ПХП. |
|
|
Arks |
28.7.2013, 1:12;
Ответить: Arks
Сообщение
#9
|
|
|
|
|
alexdrob |
28.7.2013, 1:37;
Ответить: alexdrob
Сообщение
#10
|
|
Домен основной разный?
|
|
|
|
Текстовая версия | Сейчас: 29.3.2024, 13:51 |