X   Сообщение сайта
(Сообщение закроется через 3 секунды)



 

Здравствуйте, гость (

| Вход | Регистрация )

2 страниц V   1 2 >
Открыть тему
Тема закрыта
> Мультисайт
Den1xxx
Den1xxx
Topic Starter сообщение 24.7.2013, 9:07; Ответить: Den1xxx
Сообщение #1


Здравствуйте.

Задача.
На сайте 1 есть N пользователей.
На сайте 2 нет никаких пользователей.
Как, с какими технологиями можно сделать транспорт, чтобы на сайте 2 работала регистрация пользователей с сайта 1?
То есть заходим на сайт 2, и если мы на сайте 1 зарегистрированы, то видим «Добро пожаловать, Den1xxx»
Как передать данные сессии между разными доменами, в фоне?

Склоняюсь к чему-то вроде curl
Но пока не доходит как:)

Интересует мнение людей, которым уже приходилось решать подобные задачи.
0
Вернуться в начало страницы
 
Ответить с цитированием данного сообщения
Arks
Arks
сообщение 24.7.2013, 10:02; Ответить: Arks
Сообщение #2


(Den1xxx @ 24.7.2013, 12:07) *
Как передать данные сессии между разными доменами

Доменами? что-то не понял. Серверами? 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://
http://
сообщение 24.7.2013, 12:24; Ответить: http://
Сообщение #3


А перенос таблицы с пользователями не реален? Зачем геморой с сессиями, понять не могу.
Вернуться в начало страницы
 
Ответить с цитированием данного сообщения
Den1xxx
Den1xxx
Topic Starter сообщение 24.7.2013, 12:24; Ответить: Den1xxx
Сообщение #4


(Arks @ 24.7.2013, 13:02) *
Но не через сайт1 т.к. у нас сайт2 разумеется, а через сайт2 на который будет ломиться сайт1 впоследствии.
Но простейший вариант по-моему это редирект сделать.
сайт2 => сайт1
пип-пип-пип авторизация...
сайт1 => сайт2
profit...

И как отслеживать на сайте2 что например этот пользователь не просто авторизован, а имеет такие-то права?
Склоняюсь к мысли что оба сайта должны сделать авторизацию через единый сервис (коннектиться к одной БД).
Серверы разные, если что. Иначе задача была бы проста.

(Mr.CodE @ 24.7.2013, 15:24) *
А перенос таблицы с пользователями не реален?

Неправильный подход, т.к. после переноса таблицы будут разные пользователи региться на разных сайтах.
Синхронизировать как-то придется.
Вернуться в начало страницы
 
Ответить с цитированием данного сообщения
A1ex_hb
A1ex_hb
сообщение 24.7.2013, 12:54; Ответить: A1ex_hb
Сообщение #5


Можно сделать для сайтов одну базу данных, потом подредактировать код сайта 1, чтоб куки были видны для сайта 2.
Если авторизация работает через сессию, придется переделывать алгоритм или создавать api.
Вернуться в начало страницы
 
Ответить с цитированием данного сообщения
Arks
Arks
сообщение 26.7.2013, 2:01; Ответить: Arks
Сообщение #6


(A1ex_hb @ 24.7.2013, 15:54) *
потом подредактировать код сайта 1, чтоб куки были видны для сайта 2.

Просвети нас, что где подредактировать чтобы куки с html.by были доступны для arks-cool-hacker.by

Den1xxx, куки сайты должны устанавливать очевидно самостоятельно если не прибегать к кросс-доменной авторизации на клиенте с преферансом и домохозяйками.
Сессия предполагает что все что должно быть расшарено доступно всем бэкендам, если речь идет о правах - они должны быть также в этой расшаренной сессии.
Общая БД - как-то не тянет на кроссдоменную авторизацию. Смысл кроссдоменной авторизации в том что есть некий cross-домен на котором происходит авторизация, а все прочие домены за счет сервисов получают с него информацию. Простейший вариант с редиректом не катит - ну ладно, придумай свой велосипед с клиентской кросс-доменной авторизацией. На самом дее это несложно если отойти от базовых понятий "сессий" с их SESSIONID и пользоваться token'ами которые уже могу вести на сессию.
Вернуться в начало страницы
 
Ответить с цитированием данного сообщения
Den1xxx
Den1xxx
Topic Starter сообщение 26.7.2013, 3:45; Ответить: Den1xxx
Сообщение #7


(Arks @ 26.7.2013, 05:01) *
Общая БД - как-то не тянет на кроссдоменную авторизацию. Смысл кроссдоменной авторизации в том что есть некий cross-домен на котором происходит авторизация, а все прочие домены за счет сервисов получают с него информацию.

Ну я склоняюсь к следующей структуре.
Оба сайта имеют свою БД одинаковой структуры. Движки одинаковы. Но у сайта2 при обращении к таблице users происходит обращение к БД сайта1.
Т.о. всё вроде должно быть просто и прозрачно?
Логины, пароли и др. инфа будут совпадать, но куки будут устанавливаться не синхронно на обоих сайтах, ну и фиг с ним.
Интересно можно ли сделать синхронный вход при такой структуре.
Вернуться в начало страницы
 
Ответить с цитированием данного сообщения
ZhukV
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
Arks
сообщение 28.7.2013, 1:12; Ответить: Arks
Сообщение #9


(ZhukV @ 28.7.2013, 03:44) *
на котором потом насильно устанавливаем куку на совсем отдельный домен.

Просвети нас, глупых, как же мне с сайта arks-cool-hazker.org установить пользователю куку на его ssid в домене mail.yandex.ru без кросс-доменных клиентских скриптов?
Вернуться в начало страницы
 
Ответить с цитированием данного сообщения
alexdrob
alexdrob
сообщение 28.7.2013, 1:37; Ответить: alexdrob
Сообщение #10


Домен основной разный?
Вернуться в начало страницы
 
Ответить с цитированием данного сообщения
2 страниц V   1 2 >
Открыть тему
Тема закрыта
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0


 



RSS Текстовая версия Сейчас: 29.3.2024, 13:51
Дизайн