Есть ли способ изменить HTTP-запрос (добавить файл cookie, параметр HTTP-запроса или что-то еще), чтобы можно было сохранить сеанс HTTP, когда пользователь переходит к совершенно другому сайт, расположенный в другом домене?HTTP-сессия между несколькими сайтами
Вам нужно будет передать данные сеанса здесь между двумя разными серверами, чтобы он мог сделать что-то хорошее; это невозможно, если у вас нет доступа к обоим доменам/серверам и не создайте что-то серверное для реализации этого. Даже тогда он будет применяться только к определенным серверам, которым вы управляете.
Невозможно получить данные сеанса с сервера, на котором у вас нет контроля.
Вопрос был НЕ о стороне сервера, на стороне сервера, с которой я могу справиться. Вопрос о стороне клиента – Demiurg
Моя ошибка. См. Следующую статью: http://stackoverflow.com/questions/511541/sharing-session-across-domain. Во втором комментарии дается объяснение единого входа. Тем не менее, это все еще серверная сторона; Я, честно говоря, не думаю, что вы можете делать клиентскую сторону, так как в любом случае взаимодействие с фактическими данными сеанса происходит на сервере. А.К.А. ваше решение может быть чисто серверным в первую очередь. – sichinumi
Если у вас есть разные домены, вы можете работать с субдоменами, так как foo.bar.com и toto.bar.com могут совместно использовать файлы cookie, если домен cookie является .bar.com.
Если вы не можете работать с субдоменами, вы можете попытаться получить рабочую конфигурацию домена или поддомена, используя прокси на 1-м домене. Наличие прокси-сервера toto.bar.com прокси-сервера toto.com может помочь вам поделиться файлами cookie сеанса .bar.com. Если вы это сделаете, будьте осторожны, чтобы не создавать открытый прокси. Это значит, что ваш первый сервер получит 100% трафика.
Тогда, если ни одно из предыдущих не подходит, вам понадобится решение SSO, а третье лицо будет передавать данные аутентификации. Но SSO существует только для обмена идентификационной частью, а не с данными сеанса.
Перед решением SSO существует простое решение с тем же идентификационным/аутентификационным бэкэндом (скажем, openLDAP). Но это позволит вам иметь унифицированный пароль, а не передавать связанный/отключенный статус (это задание SSO).
Если вы можете обрабатывать совместное использование данных сеанса на стороне сервера, вам придется обрабатывать синхронизацию двух разных сеансов на двух сайтах, связанных с теми же людьми. Эта ассоциация с уникальным идентификатором - это то, что дает вам SSO. Это сложная вещь.
Теперь действительно важный вопрос: Какие вещи вы хотите разделить между 2-мя сайтами? Если это предпочтение пользователя, например, цветовая тема или что-то подобное, вы можете подумать о вызове CROS или JSONP, давая вам некоторую настройку пользователя, gs в среде js вашего приложения, вы даже можете сделать некоторые ajax-запросы, чтобы сохранить эти настройки в каждом приложение, это способ совместного использования общих данных между двумя приложениями, но не использовать его для секретных данных.
Это просто передача идентификатора сеанса вместе с запросом? – Gumbo
Это также называется «single sign on» – powtac
@powtac: сеансы предназначены не только для хранения данных аутентификации, и ничего не сказано о какой-либо аутентификации. – Gumbo