Какой ваш любимый подход к совместному использованию файлов cookie?

Ответ 1

Мой подход обозначает один домен как "центральный" домен, а другие - как "спутниковые".

Когда кто-то нажимает ссылку "войти" (или представляет постоянный файл cookie для входа), форма входа в конечном итоге отправляет свои данные на URL-адрес, который находится в центральном домене, вместе со скрытым элементом формы, указывающим, в каком домене он пришел от (просто для удобства, поэтому пользователь перенаправляется обратно).

Затем эта страница в центральном домене переходит к настройке сеансового файла cookie (если логин прошел успешно) и перенаправляет обратно в любой домен, в который пользователь вошел, со специально созданным токеном в URL-адресе, который является уникальным для этого сеанса.

Затем страница на спутниковом URL проверяет этот токен, чтобы узнать, соответствует ли он токен, который был сгенерирован для сеанса, и если это так, он перенаправляет себя без токена и устанавливает локальный файл cookie. Теперь, когда в спутниковой области есть файл cookie сеанса. Эта переадресация очищает токен от URL-адреса, так что маловероятно, что пользователь или любой искатель будет записывать URL-адрес, содержащий этот токен (хотя, если это так, это не имеет значения, токен может быть одноразовым токеном).

Теперь пользователь имеет cookie сеанса как в центральном домене, так и в спутниковой области. Но что, если они посещают другой спутник? Как правило, они будут отображаться на спутнике как не прошедшие проверку.

Тем не менее, во всем приложении, когда пользователь находится в действительном сеансе, все ссылки на страницы на других спутниковых доменах имеют к ним присоединенные или с. Я оставляю эту "строку запроса" равной "проверке с центральным сервером, потому что мы считаем, что у этого пользователя есть сеанс". То есть, ни один токен или идентификатор сеанса не отображаются на любой HTML-странице, а только буквы, которые не могут идентифицировать кого-либо.

URL-адрес, получающий такой тег запроса 's', будет, если еще не существует действительного сеанса, перенаправляет на центральный домен, говоря: "Можете ли вы сказать мне, кто это?" помещая что-то в строку запроса.

Когда пользователь приходит на центральный сервер, если они аутентифицированы, центральный сервер просто получит их cookie сеанса. Затем он отправит пользователя обратно на спутник с другим одноразовым токеном, который спутник будет рассматривать так же, как спутник после входа в систему (см. Выше). Т.е., теперь спутник настроит cookie сеанса в этом домене и перенаправит на себя, чтобы удалить токен из строки запроса.

Мое решение работает без поддержки script или iframe. Для этого требуется, чтобы '? S' добавлялось к любым междоменным URL-адресам, где у пользователя еще нет cookie с этим URL-адресом. Я подумал о том, как обойти это: когда пользователь впервые войдет в систему, настройте цепочку перенаправления вокруг каждого отдельного домена, установив cookie сеанса на каждом из них. Единственная причина, по которой я не реализовал этого, заключается в том, что было бы сложно, потому что вам нужно было иметь установленный порядок, в котором эти переадресации произойдут и когда остановиться, и не позволит вам расширять пределы до 15 доменов или так (слишком много больше, и вы становитесь опасно близкими к "пределу перенаправления" многих браузеров и прокси).

Ответ 2

Это хорошее решение, если у вас есть полный контроль над всеми доменами. В моей ситуации у меня есть только клиентский (javascript/html) элемент управления на одном и полный контроль над другим, поэтому мне нужно использовать метод iframe/p3p, который отстой: (.

Ответ 3

Пример в этой статье кажется мне подозрительным, потому что вы в основном перенаправляете URL-адрес, который, в свою очередь, передает переменные обратно в ваш домен в querystring.

В этом примере это означает, что злоумышленник может просто перейти к http://slave.com/return.asp?Return=blah&UID=123" и войти на него на slave.com как пользователь 123.

Мне что-то не хватает или хорошо известно, что этот метод небезопасен и его не следует использовать, ну, например, такие примеры, как этот пример (передача идентификатора пользователя, предположительно, чтобы сделать один переносной идентификатор).

Ответ 4

@thomasrutter

Вы можете избежать необходимости управлять всеми исходящими ссылками на спутниках (путем добавления "s" к querystring), сделав ajax-вызов, чтобы проверить "центральный" домен для состояния auth при загрузке страницы. Вы можете избежать избыточных вызовов (при последующих загрузках страниц), выполнив только один сеанс.

Возможно, было бы лучше сделать запрос проверки подлинности на сервере до загрузки страницы, чтобы (а) у вас был более эффективный доступ к сеансу, и (б) вы узнаете на странице рендеринг, независимо от того, является ли пользователь (и отображать содержимое соответственно).

Ответ 5

Мы используем цепочку файлов cookie, но это не очень хорошее решение, так как оно ломается, когда один из доменов не работает для пользователя (из-за фильтрации/брандмауэров и т.д.). Новые методы (в том числе и ваши) ломаются только тогда, когда "главный" сервер, который передает файлы cookie/управляет входами, ломается.

Обратите внимание, что ваш return.asp можно злоупотреблять для перенаправления на любой сайт (например, this).

Ответ 6

Хорошо, я нашел решение, вы можете создать тэг script, который загружает src домена, который вы хотите установить/получить файлы cookie...... только сафари, похоже, не может удалять файлы cookie SET, но Ie6 и FF работают нормально... все же, если вы только хотите ПОЛУЧИТЬ файлы cookie, это очень хороший подход.

Ответ 7

Вы также должны проверять информацию активного сеанса до доменов b, c, d,... таким образом, вы можете войти только в том случае, если пользователь уже зарегистрировался в домене a.

Ответ 8

Что вы делаете в домене, получающем переменные, которые вы проверяете адрес реферера, так что вы можете подтвердить, что ссылка была из вашего собственного домена, а не кто-то, просто набрав ссылку в адресной строке. Этот подход работает хорошо.