Как я код вызова JQuery Ajax() (например, XMLHttpRequest), чтобы сохранить идентификатор сеанса (например, отправить печенье «JSessionID» уже в куки браузера)Повторное использование JSessionID на Ajax XMLHttpRequest с помощью JQuery
Наш контекст:
- Два Java на основе веб-приложений
- SSO механизм регистрирует пользователя в обоих приложениях (т.е. имеет сеанс 101 с приложением и сессии 202 с применением B)
- A РИМЕНЕНИЕ «A» использует JavaScript (JQuery), чтобы остальные звонки в приложении B
- Применение B реализован API остального в Java джерси (FWIW)
- Все ПОЛУЧИТЬ-х и «старую школу формы ПОСТОВ» из приложения А к В подключении на тот же сеанс № 202 в «сеансе B»
- XmlHttpRequests (например, Вызов jQuery 'ajax()') повторно не использует сеанс # 202. Каждый XmlHttpRequest получает новую сессию
Почему новые сессии?
Причина: XmlHttpRequest не передает куки-файлы в приложение B. Набор сервлетов устанавливает jsessionid в файл cookie. Сервер не получает JSESSIONID
В отличие от этого, JSONP вызовы (которые динамически генерировать < сценарий SRC = "HTTP: //server/b/page.x" >) сделать передать печенье.
Вопросы
- Что это самый простой способ получить Ajax XMLHttpRequest вызовов передать идентификатор сессии (куки) в целевом приложении?
- Любые хорошие ссылки на ajax, cookie, xmlhttprequest и REST?
- Может ли кто-нибудь рекомендовать читать дизайн и аутентификацию REST API?
веб-сессии, государственные и аутентификации
Я знаю, что REST должен быть лицом без гражданства, а также повторное использование веба-сессий кажется несколько хрупкими (то есть в отличие от использования OAuth аутентификации и маркеров, как это делает netflix)
Это первая итерация, и мы были близки к тому, чтобы все было «запущено». Это отлично работает с JSONP, но сообщения XmlHttpRequest не удались.
заранее спасибо
Update:
Наивный вопрос действительно.
Оказалось, что межсайтовая проводка через xmlhttprequest/ajax имеет неотъемлемые проблемы безопасности и обходные пути. Например, Firefox не будет передавать файлы cookie с помощью XmlHttpRequest, если вы не добавите специальные заголовки.Затем Firefox выполнит «предполетную проверку» (т. Е. Вызов http OPTIONS) на сервер, чтобы увидеть «это нормально?». Ваш сервер должен ответить на вызов «OPTIONS», говоря «да, все в порядке», прежде чем firefox выполнит ваше «сообщение с куки».
IE и Firefox решают эту проблему по-разному (например, javascript circa 1998). Я не знаю, что делает IE, но, прожив до 1998 года, мы не хотим действительно идти по этой дороге, если это вообще возможно.
Мы закодировали обходное решение.
Ни одна из нашей команды не знала об этом, когда мы начали кодирование. (Т.е. "JSONP работал большой в прототипе, все остальное должно также")
Ссылки: Как Mozilla решает эту проблему (HTTP заголовки и предполетной проверки) https://developer.mozilla.org/En/HTTP_access_control
Cross Origin Совместное использование ресурсов: http://en.wikipedia.org/wiki/Cross-Origin_Resource_Sharing
Можете ли вы описать обходное решение, которое вы упомянули? – jmend
Мы передали токен аутентификации sso в качестве параметра запроса и изменили серверную сторону, чтобы проверить этот параметр. Он пахнул немного хакерским, но был последовательным и понятным. Мы не * пытались передать jsessionId tomcat как параметр, который не сработает. – user331465
Спасибо, это имеет смысл. – jmend