Сеансы между доменами - общие перекрестные домены в корзине покупок


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

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

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

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

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

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

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

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

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

Author: Jaroslav Moravec, 2010-06-02

11 answers

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

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

Пример:

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

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

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

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

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

 9
Author: favo, 2010-06-08 20:59:31

Об этом постоянно спрашивают.

Есть поиск единого входа.

Вам нужно передать идентификатор сеанса в URL-адресе (или отправить СООБЩЕНИЕ) через домены, затем:

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;
}

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

C.

 4
Author: symcbean, 2010-06-02 09:14:17

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

Предположим, что наш клиент авторизован для 1-го домена. Переходя ко второму, мы должны:

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

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

 3
Author: Your Common Sense, 2010-06-12 10:34:05

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

 1
Author: Deniz Acay, 2010-06-08 21:21:35

ЕДИНЫЙ вход.

У Carta есть iframe, который 1) проверяет, является ли пользователь "активным" (имеет сеанс) 2) создает сеанс anon У CartB есть iframe, который выполняет 1) или 2)

Iframe загружается из домена единого входа (любого домена, который у вас может быть)

Решение единого входа: создайте свой или используйте другие - например, simplesamlphp или что-то в этом роде...

И не должно быть необходимости передавать сеансы/параметры с URI...

 0
Author: f13o, 2010-06-02 22:51:13

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

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

 0
Author: Tgr, 2010-06-07 21:11:36

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

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

 0
Author: Jan Kuboschek, 2010-06-08 21:07:30

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

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

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

Но этот способ был бы в лучшем случае банальным.

 0
Author: Echo, 2010-06-08 21:16:51

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
Author: Wrikken, 2010-06-09 18:32:36

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

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

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

 0
Author: Sean Kinsey, 2010-06-12 08:21:42

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

  • Сайт 1 имеет Iframe сайта 2
  • Сайт 2 имеет Iframe сайта 1

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

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

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

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

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

Вариант 3: Завиток

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

Вариант 4: Сторонние файлы cookie

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

 0
Author: Aaron Harun, 2010-06-13 18:07:19