Каков Ваш любимый перекрестный доменный подход совместного использования cookie?
В Java все находится в форме класса.
Если вы хотите использовать любой объект, тогда у вас есть две фазы:
- Объявить
- Инициализация
Пример:
- Объявление:
Object a; - Инициализация:
a=new Object();
То же самое для концепции массива
- Объявление:
Item i[]=new Item[5]; - Инициализация:
i[0]=new Item();
Если вы не дают секцию инициализации, тогда возникает NullpointerException.
5 ответов
Мой подход определяет один домен как 'центральный' домен и любых других как 'спутниковые' домены.
, Когда кто-то нажимает на ссылку 'sign in' (или представляет персистентный cookie входа в систему), знак в форме в конечном счете отправляет свои данные в URL, который находится на центральном домене, наряду со скрытым элементом формы, говорящим, из какого домена это прибыло (только для удобства, таким образом, пользователь перенаправляется назад впоследствии).
Эта страница в центральном домене тогда продолжает устанавливать сеансовые куки (если вход в систему подходил), и перенаправление назад к любому домену, пользователь вошел в систему от со специально сгенерированным маркером в URL, который уникален для той сессии.
страница в спутниковом URL тогда проверяет, что маркер, чтобы видеть, соответствует ли это действительно маркеру, который был сгенерирован для сессии, и если так, она перенаправляет к себе без маркера и устанавливает локальный cookie. Теперь, когда спутниковый домен имеет сеансовые куки также. Это перенаправление очищает маркер от URL, так, чтобы было маловероятно, что пользователь или любой поисковый робот запишут URL, содержащий тот маркер (хотя, если они сделали, это не должно иметь значения, маркер может быть маркером единственного использования).
Теперь, у пользователя есть сеансовые куки и в центральном домене и в спутниковом домене. Но что, если они посещают другой спутник? Ну, обычно, они появились бы к спутнику, как не аутентифицируется.
Однако всюду по моему приложению, каждый раз, когда пользователь находится на допустимой сессии, все ссылки на страницы на других спутниковых доменах имеют a? s или & s добавленный им. Я резервирую эту' строку запроса для значения, "сверяются с центральным сервером, потому что мы считаем, что у этого пользователя есть сессия". Таким образом, никакой идентификатор маркера или сессии показывают на любой странице HTML, только буква', которая не может определить кого-то.
URL А, получающий такой' тег запроса, если еще нет никакой допустимой сессии, сделает перенаправление к центральному высказыванию домена, "можно ли сказать мне, который это?" путем помещения чего-то в строку запроса.
, Когда пользователь прибывает в центральный сервер, если они аутентифицируются, там центральный сервер просто получит их сеансовые куки. Это тогда передаст пользователя обратно спутнику с другим единственным маркером использования, который будет рассматривать спутник, как спутник был бы после входа в систему (см. выше). Т.е., спутник теперь настроит сеансовые куки на том домене и перенаправит к себе для удаления маркера из строки запроса.
Мое решение работает без сценария или поддержки iframe. Это действительно требует'? s', которые будут добавлены к любым междоменным URL, где у пользователя еще не может быть cookie в том URL. Я действительно думал о способе обойти это: когда пользователь сначала войдет в систему, настройте цепочку перенаправлений вокруг каждого домена, установив сеансовые куки в каждом. Единственная причина я не реализовал это, состоит в том, что это было бы сложно, в котором необходимо будет быть в состоянии иметь порядок набора, что эти перенаправления произошли бы в и когда остановиться и будут препятствовать тому, чтобы Вы расширились вне приблизительно 15 доменов (еще много, и Вы становитесь опасно близко к 'пределу перенаправления' многих браузеров и прокси).
Это - хорошее решение, если у Вас есть полный контроль над всем бэкендом доменов. В моей ситуации у меня только есть клиент (javascript/html) управление на одном и полный контроль над другим, поэтому я должен использовать iframe/p3p метод, который сосет: (.
Мы используем объединение в цепочку cookie, но это не хорошее решение, так как это повреждается, когда один из доменов не работает на пользователя (из-за фильтрации / брандмауэры и т.д.). Более новые методы (включая Ваш) только повреждаются, когда "основной" сервер, который раздает cookie / управляет повреждениями логинов.
Примечание, которое Вашим return.asp можно злоупотребить для перенаправления на любой сайт (см. это , например).
Хорошо я, кажется, нашел решение, можно создать тег script, который загружает src домена, на котором Вы хотите установить/получить cookie..., только сафари до сих пор, кажется, не в состоянии УСТАНОВИТЬ cookie, но Ie6 и FF хорошо работают... все еще, если Вы только хотите ПОЛУЧИТЬ cookie, это - очень хороший подход.
Пример из этой статьи кажется мне подозрительным, потому что вы в основном перенаправляете на URL-адрес, который, в свою очередь, передает переменные обратно в ваш домен в строке запроса.
В этом примере это означало бы, что злоумышленник может просто перейти на http://slave.com/return.asp?Return=blah&UID=123 "и войти в систему на slave.com как пользователь 123.
Я что-то упускаю, или хорошо известно, что этот метод небезопасен и не должен использоваться для, ну,