Какой ваш любимый междоменный обмен файлами cookie?

Question

Я вижу, что трюк iframe / p3p - самый популярный в мире, но мне лично он не нравится, потому что javascript + скрытые поля + frame действительно делают его похожим на хакерскую работу. Я также сталкивался с подходом «ведущий-ведомый» с использованием веб-службы для связи (http://www.15seconds.com/issue/971108.htm)), и он кажется лучше, поскольку он прозрачен для пользователя и устойчив к различным браузерам.

Есть ли лучшие подходы, и каковы плюсы и минусы каждого?

Answer 1

Мой подход определяет один домен как «центральный» домен, а любые другие - как «спутниковые» домены.

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

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

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

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

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

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

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

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

Answer 2

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

Answer 3

@ thomasrutter

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

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

Answer 4

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

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

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

Answer 5

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

Answer 6

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

Answer 7

Хорошо. Кажется, я нашел решение, вы можете создать скрипт-тег, который загружает src домена, на который вы хотите установить / получить куки ... только сафари пока не может устанавливать куки, но Ie6 и FF работают нормально ... все же, если вы хотите только получить куки, это очень хороший подход.

Answer 8

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

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