мы решаем проблему с помощью eshop (php, mysql). Клиент хочет иметь один и тот же eshop на двух доменах с общей корзиной покупок. В магазине клиент может совершать покупки без учетной записи пользователя (не может быть зарегистрирован). И есть проблема, как сделать общий домен перекрестной корзины покупок.
Данные из корзины хранятся в сеансах, которые мы также храним в базе данных. Но мы не можем решить проблему переноса данных по доменам. Идентификация нелегального пользователя не является дырочным ( исследование ).
Клиент переходит к доменуОн и добавляет некоторые вещи в корзину. Затем он отправляется в domainTwo (по ссылке, набрав адрес домена, однако) и добавляет некоторые другие вещи в корзину. В телеге у него есть вещи из обоих доменов (после обновления страницы).
У вас есть идея, как решить эту проблему?
Если вы меня не понимаете, задайте мне вопрос. Если вы думаете, что наличие eshop на двух доменах с общей корзиной – плохая идея, не говорите мне, мы это знаем.
Спасибо за каждый ответ.
Вы можете использовать третий домен, чтобы идентифицировать своих клиентов по всем доменам.
Используйте, например, файл PHP на http://thirdDomain.com/session.php, который включен на все страницы в обоих магазинах.
Образец:
<script type="text/javascript" src="http://thirdDomain.com/session.php"></script> После того, как ваш клиент переключит домены, вы можете идентифицировать его как одного и того же клиента, используя третий домен.
Вы можете назначить идентификатор сеанса в обоих магазинах идентификатору сеанса в третьем домене, чтобы получить доступ к тележке в обоих магазинах. Вам нужно только проинформировать третий домен о своих сессиях магазина (например, добавить их как параметр).
В зависимости от того, насколько вы гибки с вашим кодом и шаблонами, вы даже можете использовать вывод из третьего домена для определения идентификатора сеанса в своих магазинах. Таким образом, вы можете использовать один и тот же идентификатор сеанса для всех доменов. Но обычно назначение идентификатора сеанса должно быть более безопасным способом.
Используя версию javascript, вы также можете выводить скрипты, которые могут добавлять идентификатор сеанса ко всем исходящим ссылкам и формам в другой домен на текущей странице html. Это может быть интересно, если вы можете идентифицировать своего клиента как заблокированного куки. Вы также можете использовать javascript для информирования родительского документа о существующем сеансе.
Это постоянно спрашивается.
Ищите SSO.
Вам необходимо передать идентификатор сеанса в URL (или vai 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; }
Это также означает, что вам нужно добавить '? Pass_id ='. urlencode (session_id ()) на любой URL-адрес, указывающий на другой домен.
C.
Схема довольно проста и широко используется. Например, Google предлагает множество услуг. У вас есть целая картина, отслеживая HTTP-обмен между вашим браузером и различными службами google, чтобы получить эту идею.
Предположим, что наш клиент авторизовался для 1-го домена. Подойдя ко второму, мы должны:
Остается только вопрос о том, как запросить 1-й домен. Это может быть изображение или запрос JS или переадресация всей страницы. Определенный выбор зависит от вас.
Я думаю, вы можете использовать Flash LSO. Обычно LSO хранятся в своих изолированных песочницах, но если разрешены два объекта домена, они могут связываться, как указано в разделе «Передача видео» в http://download.macromedia.com/pub/flash/whitepapers/security. pdf . Для получения общей информации о LSO: http://www.adobe.com/products/flashplayer/articles/lso/
SSO.
CartA имеет iframe, что 1) проверяет, является ли пользователь «активным» (имеет сеанс) 2) создает сеанс анонимного сеанса CartB имеет iframe, который делает 1) или 2)
загрузка iframe из домена SSO (любой домен, который у вас есть)
Решение SSO: создайте свои или используйте другие – например simplesamlphp или что-то еще …
И не должно быть необходимости проходить сеансы / params с URI …
Вы можете хранить данные в других местах, кроме файлов cookie (например, Flash-файлы cookie, localStorage ), но все они используют одну и ту же политику происхождения, которая является стандартной моделью безопасности Интернета: данные, хранящиеся в домене, могут быть доступны только этому домену и его поддоменам. Стандартным обходным решением является встраивание iframe из чужого домена в страницу. Этот iframe будет иметь доступ к файлам cookie иностранного домена, и его URL будет контролироваться локальным доменом, который позволяет общаться.
Простое решение на основе этого состоит в том, чтобы иметь таблицу (domainA sessionid, domainB sessionid). Когда новый пользователь приходит в domainA, (new sessionid, NULL) добавляется в таблицу; страница, показанная ему, содержит невидимый iframe с источником = http://domainB/mergeSessions.php?sessionA=1234 . mergeSessions.php затем получит sessionA в качестве параметра URL и sessionB в качестве файла cookie и соответствующим образом обновит таблицу ссылок сеанса.
Вы можете попытаться идентифицировать своих посетителей по IP, типу браузера, версии браузера, ОС, разрешению экрана и всем остальным, что вы придумали. То, что вы храните в общей базе данных, когда кто-то обращается к любому сайту.
Если в течение небольшого временного окна скажите <5 минут, запросы от этого IP-адреса с этими параметрами приходят, вы можете разумно предположить, что это тот же пользователь. Опять же, убедитесь, что вы используете все, что вы можете найти, чтобы найти этого пользователя и никоим образом не основывать на этом что-либо, или вы подвергнетеся угону.
Что-то вроде этого, не уверен, насколько это было бы хорошо.
Пользователь переходит в store1. Если у пользователя нет cookie сеанса, переадресовывайте его на специальную страницу на store2, запрашивая идентификатор сеанса и отправляя url на store1 для возврата. На специальной странице просматривается файл cookie сеанса и перенаправляется обратно на исходный url на store1 с идентификатором сеанса (например, ответ @symcbean). Затем в store1 cookie сеанса получает установленный (или созданный новый), и больше не происходит перенаправления. И тогда то же, но oposite, если пользователь находится на store2 без cookie сеанса.
Но если у пользователя нет разрешенных файлов cookie, я вижу бесконечный цикл. Не уверен, что можно будет каким-то образом обнаружить и остановить.
Но этот путь в лучшем случае был бы взломан.
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 и застревают снова и снова.
easyXDM – это структура, которая позволяет пользователю легко обойти политику одинакового происхождения. Его встроенная функция RPC очень проста в использовании, и вы должны работать без сбоев.
Для вашего случая выберите один из доменов как домен «checkout» (A) – это домен, который сохранит сеанс. В том же домене вы создаете небольшой файл с конечной точкой easyXDM, который отвечает за хранение / извлечение данных, отправленных из другого домена (B).
Теперь, в домене B, вы включаете easyXDM, а при хранении / извлечении данных из корзины вы вместо этого обращаетесь к RPC-методам.
Вариант 1 Используйте iframes:
Когда пользователь выбирает элемент с сайта один, установите значение iframe для динамической строки, то есть domain2.com/iframe.php?itemid=someitem.
Пусть domain2 захватит информацию $ _GET с PHP из iframe и обновит файл cookie пользователя.
Сделайте то же самое в другом направлении.
Вариант 2: Javascript включает
Вы можете сделать что-то подобное с кросс-сайтами, содержащими JS-файлы, созданные PHP, чтобы «вытащить» содержимое cookie пользователя на другой сайт.
Вариант 3: завиток
Просто отправьте данные из одного домена в другой, так что у обоих есть копия. Это наименее безопасный метод, поскольку нет гарантии, что IP-адрес или другие идентифицирующие данные не могут быть дублированы. Хотя, у вас может быть какая-то «проблема» или фраза, чтобы убедиться, что это тот же человек. Возможно, установив адрес электронной почты?
Вариант 4: сторонние файлы cookie
Я думаю, что это уже упоминалось, но вы можете установить файлы cookie из третьего домена, поэтому оба сайта функционально точно такие же, а не «переключение» между ними.