Ответ 1
Отказ от ответственности:
Как указано ранее @feroze, установка домена cookie на localhost не будет так хорошо работать для вас. Я предполагаю, что вы пишете помощника, который позволяет туннелировать HTTP-запросы в чужие домены. Обратите внимание, что это не самая лучшая практика и во многих случаях не требуется (т.е. jQuery имеет много классной кросс-доменной поддержки, встроенной, также см. Новую спецификация CORS). Но иногда вы можете это делать (т.е. Внешний ресурс - только XML и находится на сервере, который не поддерживает CORS).
Фоновая информация о доменах cookie и о том, как они работают:
Если вы еще не взглянули на HTTP Cookie: Домен и путь в Википедии - почти все, что вам нужно знать, находится там.
При оценке файла cookie домен и путь учитываются и клиентом ( "местным" реквестером) и веб-сервером ( "иностранным" ответчиком). Когда клиент запрашивает ресурс, клиент должен отправлять только файлы cookie, если эти файлы cookie соответствуют домену (или более общий родительский домен) и Path (или более общий родительский путь ) запрашиваемого URI.
Веб-браузеры обрабатывают это правильно. Если у веб-браузера есть файл cookie для домена "localhost" и вы запрашиваете "google.com", например, эти файлы cookie для домена "localhost" не будут отправляться в запрос на "google.com". - На самом деле, большинство современных браузеров не просто не отправят их, они полностью игнорируют их в заголовках ответов Set-Cookie, которые они получают (они называются сторонними куки файлами, что позволяет принимать сторонние файлы cookie в вашем веб-браузер - это серьезная проблема конфиденциальности/безопасности - не делайте этого!).
Он работает и в другом направлении - даже если маловероятно, что клиент может включить сторонний файл cookie в запрос, если он это делает, он должен игнорировать его (и даже некоторые файлы cookie для правильного доменов/путей, чтобы предотвратить печально известную проблему супер-cookie (т.е. веб-сервер, на котором размещен сайт example.com, должен игнорировать файлы cookie, принадлежащие его родительскому домену:.com ", потому что".com "- это" публичный суффикс ")).
Что вы должны делать [если вам нужно]:
Курс действий, рекомендуемый для вас, - это когда вы читаете в своих cookie-клиентах (я не парень MVC, но в обычном ASP.NET это будет в Request.Cookies), проведите через них (убедитесь, что отфильтровывать свой собственный сайт законными кукисами, особенно SessionId и т.д., или использовать Путь должным образом, чтобы они никогда не отправлялись на эту страницу в первую очередь), а затем добавлять их по одному в коллекцию cookie исходящего запроса, переписывая домен чтобы быть "www.whatever.com" (в вашем примере - если вы делаете это динамически, загрузите URL-адрес в новый объект Uri() и используйте свойство .Host), а затем установите путь в "/", - Это создаст заголовок "Cookie" для исходящего запроса на внешний веб-сервер.
Когда этот запрос возвращается на ваш сервер, вам необходимо проверить его входящий ответ на новые файлы cookie - эти куки могут быть переупакованы и отправлены обратно вашему клиенту в том же типе цикла, что и в предыдущем абзаце, за исключением того, что вы захотите переписать Host для Request.Url.Host - и вам нужно будет установить путь обратно к "/", если только путь к вашей странице passthru не является статичным (я предполагаю, что это не так вы используете MVC), тогда вы хотите, например, установить его в Request.Url.AbsolutePath.
Счастливое кодирование!
EDIT: Кроме того, вы захотите установить тег X-Forwarded-For исходящего запроса, чтобы веб-сайт, на который вы звоните, не думает, что ваш веб-сервер один клиент, который спамал дерьмо из них.