Какой ваш любимый междоменный подход к обмену файлами cookie?
https://stackoverflow.com/questions/263010
-
06-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Я вижу, что трюк с iframe / p3p является самым популярным, но лично мне он не нравится, потому что javascript + скрытые поля + рамка действительно делают его похожим на халтуру.Я также столкнулся с подходом master-slave, использующим веб-сервис для обмена данными (http://www.15seconds.com/issue/971108.htm) и это кажется лучше, потому что оно прозрачно для пользователя и надежно работает с различными браузерами.
Есть ли какие-то лучшие подходы и каковы плюсы и минусы каждого из них?
Решение
Мой подход определяет один домен как «центральный» домен, а любые другие - как «сателлитные» домены.
Когда кто-то щелкает ссылку «войти» (или представляет постоянный файл cookie для входа), форма входа в конечном итоге отправляет свои данные на URL-адрес в центральном домене вместе со скрытым элементом формы, сообщающим, к какому домену он пришел. от (просто для удобства, поэтому пользователь перенаправляется обратно потом.)
Затем эта страница в центральном домене переходит к установке файла cookie сеанса (если вход в систему прошел успешно) и перенаправляет обратно в любой домен, с которого вошел пользователь, со специально сгенерированным токеном в URL, который является уникальным для этого сеанса.
Страница по сателлитному URL-адресу затем проверяет этот токен, чтобы определить, соответствует ли он токену, созданному для сеанса, и, если это так, перенаправляется на себя без токена и устанавливает локальный файл cookie. Теперь у этого спутникового домена также есть сессионный cookie. Это перенаправление очищает токен от URL, поэтому маловероятно, что пользователь или любой сканер запишет URL, содержащий этот токен (хотя, если они это сделали, это не должно иметь значения, токен может быть токеном одноразового использования).
Теперь у пользователя есть файл cookie сеанса как в центральном домене, так и в спутниковом домене. Но что, если они посетят другой спутник? Ну, как правило, они будут выглядеть на спутнике как не прошедшие проверку подлинности.
Однако во всем моем приложении, когда пользователь находится в допустимом сеансе, ко всем ссылкам на страницы в других сателлитных доменах добавляются буквы или символы. Я зарезервировал эту строку запроса, чтобы обозначить "проверить с центральным сервером, потому что мы считаем, что у этого пользователя есть сеанс". То есть на любой HTML-странице не отображается ни токен, ни идентификатор сеанса, только буква "s", которая не может идентифицировать кого-либо.
URL-адрес, получающий такой тег запроса 's', будет, если еще нет действительного сеанса, перенаправить на центральный домен, говоря: "Вы можете сказать мне, кто это?" поместив что-то в строку запроса.
Когда пользователь прибывает на центральный сервер, если он проходит аутентификацию, центральный сервер просто получает свой сеансовый cookie. Затем он отправит пользователя обратно на спутник с другим одноразовым токеном, который спутник будет обрабатывать так же, как спутник после входа в систему (см. Выше). То есть теперь спутник будет устанавливать cookie-файл сеанса в этом домене и перенаправлять на себя, чтобы удалить токен из строки запроса.
Мое решение работает без сценария или поддержки iframe. Требуется добавить «?» К любым междоменным URL-адресам, если у пользователя еще нет cookie-файла по этому URL-адресу. Я подумал о том, как обойти это: когда пользователь впервые входит в систему, настраивает цепочку перенаправлений вокруг каждого отдельного домена, устанавливая cookie-файл сеанса для каждого из них. Единственная причина, по которой я не реализовал это, заключается в том, что это будет сложно, потому что вам нужно будет иметь установленный порядок, в котором будут происходить эти перенаправления, и когда останавливаться, и это будет препятствовать расширению за пределы 15 доменов или около того. (их слишком много, и вы становитесь опасно близкими к «пределу перенаправления» многих браузеров и прокси-серверов).
Другие советы
Это хорошее решение, если у вас есть полный контроль над всеми доменами. В моей ситуации у меня есть только клиентское (javascript / html) управление на одном и полное управление на другом, поэтому мне нужно использовать метод iframe / p3p, который отстой: (.
Пример в этой статье кажется мне подозрительным, потому что вы в основном перенаправляете на URL, который, в свою очередь, передает переменные обратно в ваш домен в строке запроса.
В этом примере это будет означать, что злоумышленник может просто перейти на http: //slave.com/return.asp?Return=blah&UID=123 & Quot; и войдите на slave.com как пользователь 123.
Я что-то упустил или общеизвестно, что этот метод небезопасен и не должен использоваться для чего-то вроде этого примера (передача идентификатора пользователя, предположительно, чтобы сделать его переносимым).
@thomasrutter
Вы могли бы избежать необходимости управлять всеми исходящими ссылками на спутниках (путем добавления "s" к строке запроса), выполнив вызов ajax для проверки статуса авторизации "центрального" домена при загрузке страницы.Вы могли бы избежать избыточных вызовов (при последующих загрузках страницы), выполняя только один за сеанс.
Возможно, было бы лучше сделать запрос проверки подлинности на стороне сервера перед загрузкой страницы, чтобы (а) у вас был более эффективный доступ к сеансу и (б) при рендеринге страницы вы знали, авторизован пользователь или нет (и отображали содержимое соответствующим образом).
Мы используем цепочку файлов cookie, но это не очень хорошее решение, поскольку оно ломается, когда один из доменов не работает для пользователя (из-за фильтрации / брандмауэров и т. д.). Новые методы (в том числе и ваши) ломаются только тогда, когда «мастер» сервер, который раздает файлы cookie / управляет перерывами входа.
Обратите внимание, что ваш return.asp может быть использован для перенаправления на любой сайт (см. это например).
Хорошо, кажется, я нашел решение, вы можете создать скрипт-тег, который загружает src домена, на который вы хотите установить / получить куки ... только сафари пока что не может устанавливать куки, но То есть 6 и FF работают нормально ... все же, если вы хотите только получать куки, это очень хороший подход.
Вы также должны проверять информацию об активном сеансе по доменам b, c, d, ... таким образом, вы можете войти в систему только в том случае, если пользователь уже вошел в домен a.
То, что вы делаете, находится в домене, получающем переменные, вы также проверяете адрес реферала, чтобы вы могли подтвердить, что ссылка была с вашего собственного домена, а не кто-то просто вводил ссылку в адресную строку. Этот подход работает хорошо.
