Кросс-доменные сессии - общие корзины покупок кросс-доменов - PullRequest
13 голосов
/ 02 июня 2010

мы решаем проблему с eshop (php, mysql). Клиент хочет иметь один и тот же интернет-магазин на двух доменах с общей корзиной покупок. В магазине покупатель может делать покупки без учетной записи пользователя (не может войти в систему). И есть проблема, как сделать общую корзину покупок междоменной.

Данные из корзины хранятся в сессиях, которые мы также сохраняем в базе данных. Но мы не можем решить проблему переноса данных по доменам. Выявление незарегистрированного пользователя не защищено от дыр ( исследование ).

Пример, как это должно работать

Клиент заходит на domainOne и добавляет некоторые вещи в корзину. Затем он переходит к domainTwo (по ссылке, однако, вводя адрес домена) и добавляет в корзину еще кое-что. В корзине у него есть вещи с обоих доменов (после обновления страницы).

У вас есть идеи, как решить эту проблему?

Что не сработало:

  • перенаправление невозможно из-за требований клиента
  • файлы cookie связаны с доменом
  • set_cookie с другим доменом не работает
  • самый простой способ - переносить только идентификатор сеанса (сохраненный в файлах cookie), но мы не знаем, как полностью защитить идентифицированных незарегистрированных пользователей.
  • есть ли другое место, где данные могут храниться на стороне клиента, кроме файлов cookie? (вероятно нет)
  • мы не можем использовать отправку sessionid по параметрам в URL (если пользователь щелкает ссылку на другой домен) или разрешение реферера заголовка, поскольку мы не знаем, как пользователь может получить доступ к другому домену.

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

Спасибо за каждый ответ.

Ответы [ 11 ]

9 голосов
/ 09 июня 2010

Вы можете использовать третий домен для идентификации своих клиентов по всем доменам.

Используйте, например, файл PHP на http://thirdDomain.com/session.php, который включен на все страницы обоих магазинов.

Пример:

<script type="text/javascript" src="http://thirdDomain.com/session.php"></script>

После того, как ваш клиент поменял домены, вы можете идентифицировать его как того же клиента, используя третий домен.

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

В зависимости от того, насколько вы гибки с вашим кодом и шаблонами, вы даже можете использовать выходные данные из третьего домена для определения идентификатора сеанса в ваших магазинах. Таким образом, вы можете использовать один и тот же идентификатор сессии во всех доменах. Но обычно назначение идентификатора сеанса должно быть более безопасным способом.

Используя версию javascript, вы также можете выводить сценарии, которые могут добавлять идентификатор сеанса ко всем исходящим ссылкам и формам в другой домен на текущей html-странице. Это может быть интересно, если вы можете идентифицировать своего клиента как заблокировавшего файлы cookie. Вы также можете использовать JavaScript для информирования родительского документа о существующем сеансе.

4 голосов
/ 02 июня 2010

Это продолжает спрашиваться.

Ищите SSO.

Вам нужно передать идентификатор сеанса в URL (или через POST) через домены, затем:

1) проверка того, что сеанс еще не существует в целевом домене

2) повторное связывание сеанса с использованием отправленного идентификатора сеанса

например,

if ((!$_COOKIE[session_name()]) && $_GET['passed_id']) {
    if (check_session_exists($_GET['passed_id'])) { 
        session_id($_GET['passed_id']);
    }
}
session_start();
...
function check_session_exists($id)
{
   $path=session_save_path() . $id;
   if (file_exists($path) && (time()-filemtime($path)<session_cache_expire())) {
      return true;
   }
   return false;
}

Этотакже означает, что вам нужно добавить '? прошло_ид ='.urlencode (session_id ()) для любого URL, указывающего на другой домен.

C.

3 голосов
/ 12 июня 2010

Схема довольно проста и широко используется. К гуглу это многочисленные сервисы например. Чтобы получить представление, у вас есть целая картинка, отслеживая HTTP-обмен между вашим браузером и различными службами Google.

Предположим, у нас есть клиент, авторизованный для первого домена. Добравшись до второго, мы должны:

  1. начать сеанс и сохранить в нем некоторый токен.
  2. попросить браузер как-то запросить 1-й домен и отправить этот токен.
  3. 1-й домен распознает нашего клиента и установит соединение в общей базе данных между этим токеном и идентификатором пользователя.
  4. При повторном запросе второго домена он будет авторизован для уже запущенного сеанса.

Остается только один вопрос: как запросить первый домен? Это может быть картинка, JS-запрос или перенаправление всей страницы. Определенный выбор за вами.

1 голос
/ 09 июня 2010

Я думаю, вы можете использовать Flash LSO. Обычно LSO хранятся в своих доменных песочницах, но если позволяют два объекта домена, они могут обмениваться данными, как указано в разделе «Связь между фильмами» в http://download.macromedia.com/pub/flash/whitepapers/security.pdf. Для общей информации о LSO: http://www.adobe.com/products/flashplayer/articles/lso/

0 голосов
/ 13 июня 2010

Вариант 1 Использование Ифреймов:

  • На сайте 1 есть Ифраме сайта 2
  • На сайте 2 есть Ифраме сайта 1

Когда пользователь выбирает элемент на сайте один, присвойте значение iframe динамической строке, т.е. domain2.com/iframe.php?itemid=someitem.

Пусть domain2 захватит информацию $ _GET с помощью PHPиз iframe и обновите cookie пользователя.

Сделайте то же самое в другом направлении.

Вариант 2: Javascript включает в себя

Вы можете сделать что-нибудьаналогично с межсайтовыми JS-файлами, сгенерированными PHP для «вытягивания» содержимого cookie пользователя на другой сайт.

Вариант 3: Curl

Просто опубликоватьданные из одного домена в другой, поэтому оба имеют копию.Это наименее безопасный метод, поскольку нет гарантии, что IP-адрес или другие идентифицирующие данные не могут быть продублированы.Тем не менее, у вас может быть какой-то «вопрос» или парольная фраза, чтобы убедиться, что это один и тот же человек.Возможно, установив адрес электронной почты?

Вариант 4: сторонние куки

Я думаю, что этот уже упоминался, но вы можете установить куки из третьего доменаТаким образом, оба сайта функционально абсолютно одинаковы, а не переключаются между ними.

0 голосов
/ 12 июня 2010

easyXDM - это инфраструктура, которая позволяет пользователю легко работать с единой политикой происхождения. Его встроенная функция RPC очень проста в использовании, и вы должны начать работать в кратчайшие сроки.

В вашем случае выберите один из доменов, который будет доменом проверки (A) - это домен, в котором будет храниться сеанс. В этом же домене вы создаете небольшой файл с конечной точкой easyXDM, который отвечает за хранение / извлечение данных, отправленных из другого домена (B).

Теперь в домене B вы включаете easyXDM, а при хранении / извлечении данных из корзины вы получаете доступ к методам RPC.

0 голосов
/ 09 июня 2010

1) Очевидно, используйте одно и то же хранилище сеансов для обоих доменов (файлы, база данных, memcached, обычные подозреваемые.
2) Если после session_start () $ _SESSION пуст, создайте массив «все домены» в сеансе (сделайте это на каждом домене, независимо от того, какой это).

$_SESSION['all_domains'] = array(
    'domain1.com'  => true, //<= current domain the customer is on,
    'domain2.com'  => false, //other domain, no cookie for it yet.
    'domain2.com'  => false); //repeat for all domains needed

3) Создайте сценарий установки сеанса на всех доменах (назовем его 'sesset.php':

 <?php
     if(isset($_GET['sessid']){
          session_id($_GET['sessid']);
          session_start();
          //also, check here for the domains:
          if(!isset($_SESSION['all_domains'])){
              //set the array as before, flag this domain as true.
          } else {
              $_SESSION['all_domains'][$_SERVER['HTTP_HOST']] = true;
              //you might want to set a custom domainname instead of HTTP_HOST, so you won't get doubles from domain with & without www. and so on.
          }
     }
 ?>

4) На каждой мыслимой странице php HTML поместите это где-нибудь ближе к концу тела:

 <?php
     foreach($_SESSION['all_domains'] as $domain => $domainset){
         if(!$domainset){
             echo '<img src="http://'.$domain.'/sesset.php?sessid='.session_id().' width="1" height="1"/>';
         }
     }
 ?>

Не полностью защищен, но достанется почти всем пользователям. Конечно, можно сделать это с помощью каскада перенаправления вместо «скрытых изображений», но поисковые роботы (google и др.) Очень запутываются, особенно если они не помнят cookie и застряли, перенаправляя их снова и снова.

0 голосов
/ 09 июня 2010

Как насчет чего-то подобного, но не уверен, насколько хорошо это будет.

Пользователь заходит в магазин1. Если у пользователя нет cookie-файла сеанса, перенаправьте его на специальную страницу store2 с запросом идентификатора сеанса и отправкой URL-адреса store1 для возврата. Специальная страница просматривает куки-файл сессии и перенаправляет обратно на исходный URL-адрес store1 с идентификатором сессии (например, ответ @symcbean). Затем в store1 устанавливается сессионный cookie (или создается новый), и переадресация больше не происходит. И то же самое, но противоположное, если пользователь находится в store2 без сеансового cookie.

Но если у пользователя не включены куки, я вижу бесконечный цикл. Не уверен, что удастся как-то обнаружить и остановить.

Но этот путь был бы в лучшем случае хакерским.

0 голосов
/ 09 июня 2010

Вы можете попытаться идентифицировать своих посетителей по IP, типу браузера, версии браузера, ОС, разрешению экрана и любым другим параметрам. То, что вы храните в общей базе данных, когда кто-то получает доступ к любому из сайтов.

Если в течение небольшого временного окна, скажем, <5 минут, приходят запросы с этого IP с этими параметрами, вы можете <strong>разумно предположить, что это тот же пользователь. Опять же, убедитесь, что вы используете все, что можете найти, чтобы идентифицировать этого пользователя, и ни в коем случае не основывайте на этом что-нибудь безопасное, иначе вас могут похитить.

0 голосов
/ 08 июня 2010

Вы можете хранить данные в других местах, кроме файлов cookie (например, файлы cookie Flash, localStorage ), но все они используют одинаковую политику происхождения, которая является стандартной моделью безопасности в Интернете: данные, хранящиеся в домене, могут быть только доступ к этому домену и его поддоменам. Стандартный обходной путь - встроить в страницу iframe из чужого домена. Этот iframe будет иметь доступ к файлам cookie чужого домена, а его URL будет контролироваться локальным доменом, что позволяет осуществлять связь.

Простое решение, основанное на этом, состоит в том, чтобы иметь таблицу пар (domainA sessionid, domainB sessionid). Когда новый пользователь прибывает в домен A, (новый sessionid, NULL) добавляется в таблицу; показанная ему страница содержит невидимый iframe с source = http://domainB/mergeSessions.php?sessionA=1234. Затем mergeSessions.php получит sessionA в качестве параметра URL-адреса и sessionB в виде cookie-файла и соответствующим образом обновит таблицу ссылок сеанса.

...