2010-11-01 1 views
1

Я разрабатываю веб-приложение, которое подается от domain.ext. Это веб-приложение использует сеансы на основе файлов cookie и предоставляет пользователям возможность размещать веб-страницы, содержащие пользовательский JavaScript, на субдомене, например. sub1.domain.ext, sub2.domain.ext. Субдомены не используют сеансы с поддержкой файлов cookie.Можно ли изолировать файлы cookie domain.ext, sub1.domain.ext и sub2.domain.ext друг от друга?

Учитывая эту установку, можно обеспечить следующие ?:

  1. пользователей в sub1.domain.ext не умеет читать или писать кук для domain.ext (т.е. domain.ext сессия не может быть украдена или захвачен JavaScript, встроенный в страницу на странице sub1.domain.ext).
  2. JavaScript, встроенный в страницу на sub1.domain.ext, не может читать или писать файлы cookie на sub2.domain.ext и наоборот.

Я проверил несколько вещей, например, представляется возможным взаимодействовать с печеньем domain.ext от sub1.domain.ext, запустив document.domain = 'domain.ext' внутри окна sub1.domain.ext в. Есть ли способ предотвратить это, например, указав какую-либо политику при настройке домена из domain.ext?

+2

вы можете принудительно выполнить свой 'domain.ext' для перенаправления на' www.domain.ext'. Это должно защитить файлы cookie, созданные там, поскольку они рассматриваются как другой поддомен .. (* untested *) –

+0

Спасибо, Габи. Я думаю, что это то, что мне придется делать, хотя мне нравится нормализовать все мои URL-адреса для варианта, отличного от www (я думаю, что это уродливо, но это только мое мнение). –

+1

Я предпочитаю не-www тоже. Но для этого случая вы не можете избежать этого. –

ответ

3

Вы не можете указать, что файл cookie должен быть действителен только для example.com, установив параметр domain. Если вы установили domain=example.com, он будет действителен для *.example.com.

Установка печенья на example.comбез параметр domain устанавливает куки для только example.com в большинстве браузеров. Но не IE.

Итак, если вы когда-либо захотите иметь субдомены с отдельными контекстами файлов cookie, вы должны обслуживать свой сайт от www.example.comтолько. Как сказала Габи, вы, естественно, можете поддерживать доступ через example.com, перенаправив 301 версию www.

+0

Спасибо, bobince. Я думал, что мы можем обслуживать сайт с открытым доступом (cookie/session-less) на domain.ext, с www.domain.ext 301-ing до domain.ext. Затем мы могли бы разместить фактическое приложение на том, что-то вроде manage.domain.ext или panel.domain.ext. –

+0

Да, если 'domain.ext' никогда не устанавливает файлы cookie, оголенный домен в порядке. Одна вещь, на которую нужно обратить внимание: хотя 'sub1.domain.ext' не может * читать * файлы cookie из' sub2.domain.ext', он может * установить * cookie на 'domain.ext', который будет считаться by 'sub2.domain.ext', если' sub2' еще не установил более конкретный файл cookie. – bobince

Смежные вопросы