Пересеките доменный доступ cookie (или сессия)
Следующие вместе строки объединяются компилятором C.
#define DOMAIN "example.com"
#define SUBDOMAIN "test." DOMAIN
const char *asCString = SUBDOMAIN;
NSString *asNSString = @SUBDOMAIN;
7 ответов
Существует несколько способов совместного использования данных сеанса или файлов cookie между доменами. Самый простой - поделиться им на стороне сервера через общее хранилище данных. Но вы бы не задавали этот вопрос, если бы это было так просто.
Другой способ сделать это не менее прост. Домен one.com содержит некоторые данные сеанса, например, name = aleem и id = 123 , и хочет передать их на two.com ]. Он будет выполнять следующие действия:
- Выполнить вызов
two.com/api/?name=aleem&id=123 - Когда
two.comполучает данные через параметры запроса, он создает куки с данными. Этот файл cookie будет храниться в доменеtwo.com. two.comбудет перенаправлен обратно наREFERER, который в данном случае будетодин. com
Это упрощенный сценарий. Домен two.com должен иметь возможность доверять one.com , и не только это, но и знать, что запрос подлинный, а не просто созданный пользователем, поэтому вам нужно использовать открытые / закрытые ключи для смягчения этого.
Сеансы Inproc не могут оставаться действительными, однако вы можете запрограммировать свое веб-приложение, чтобы разрешить использование файлов cookie в нескольких поддоменах. Вам нужно будет установить домен равным:
Response.Cookies("CookieName").Domain = ".mydomain.com"
По умолчанию все файлы cookie для сайта хранятся вместе на клиенте, и все файлы cookie отправляются на сервер с любым запросом к этому сайту. Другими словами, каждая страница сайта получает все файлы cookie для этого сайта. Однако вы можете установить область действия файлов cookie двумя способами:
- Ограничить область действия файлов cookie папкой на сервере, что позволяет ограничить область действия файлов cookie приложением на сайте.
- Установить область действия доменом, который позволяет указать, какие поддомены в домене могут получить доступ к cookie.
Подробнее можно узнать здесь .
Вы можете установить файл cookie для определенного домена.
В php метод setCookie () содержит параметр, в котором вы можете указать домен верхнего уровня, поэтому файл cookie действителен для всех поддоменов. Судя по вашим тегам, я вижу, что вы работаете в asp.net. Возможно, это также существует для asp ...
после небольшого поиска asp:
попробуйте это:
Response.Cookies("CookieName").Domain = ".mydomain.com"
или прочтите это
Если у вас есть возможность настроить общий поддомен, вы можете сделать это:
В html-файлы вашего поддомена включите файл javascript вверху, например:
<script src="http: //common.domain.com/check.asp"></script>
В check.asp, найдите свой файл cookie logged_in и, если он отсутствует, покажите страницу, скажем, http://common.domain.com/login.asp , используя что-то вроде
<%
if (cookie_not_found){
%>
location.href = "http: //common.domain.com/login.asp";
<%
}
%>
После того, как человек отправит имя пользователя и пароль , отправьте его обратно в тот же файл login.asp и установите файл cookie сеанса (который будет установлен в домене common.domain.com), а затем перенаправьте его на http://subdomain1.domain.com .
Теперь произойдет вызов встроенного «common.domain.com/check.asp», и файлы cookie для common.domain.com будут отправлены браузером вместе с запросом. Таким образом, вы будете знать, действительна ли ваша сессия, даже если вы находитесь в subdomain1.domain.com.
Комментарии о cookie, устанавливаемом для домена, чтобы позволить субдоменам получать этот cookie, дают вам эту сторону, но чего не хватает, так это согласованности сеанса.
Я думаю, что это очень похоже на проблема поддержания состояния между серверами в ферме, и решение, вероятно, состоит в том, чтобы обеспечить согласованность вашего хранилища сеансов на обоих сайтах (если они не являются серверами с одного и того же «веб-сайта» в IIS). Вы можете переместить хранилище сеанса в SQL Server ( КАК: настроить SQL Server для хранения состояния сеанса ASP.NET ), что, вероятно, будет служить этой цели, поскольку каждый сайт будет запрашивать одно и то же хранилище при поиске данных сеанса. связанных с файлом cookie, с которым они были представлены.
Надеюсь, вы на правильном пути.
Вот работающее решение:
http://anantgarg.com/2010/02/18/cross-domain-cookies-in-safari/