Повторное использование jsessionId в ajax xmlhttprequest с использованием jquery
Как я могу закодировать вызов jquery ajax () (например, xmlhttprequest) для сохранения идентификатора сеанса (например, отправить cookie 'jsessionID' уже в файлах cookie браузера)
Наш контекст:
- Два веб-приложения на основе Java.
- Механизм SSO регистрирует пользователя в обоих приложениях (т. Е. Имеет сеанс 101 с приложением A и сеанс 202 с приложением B)
- Приложение «A» использует javascript (jquery) для выполнения вызовов отдыха для Приложение B
- Приложение B реализовало rest API в Java jersey (fwiw)
- Все GET и «POSTS старой школы» из приложения A в B подключаются к одному и тому же сеансу № 202 на «сеансе B»
- XmlHttpRequests (например, вызовы jquery 'ajax ()') не используют повторно сеанс №202. Каждый XmlHttpRequest получает новый сеанс
Почему новые сеансы?
Причина: XmlHttpRequest не передает файлы cookie в приложение B. Контейнер сервлета устанавливает jsessionid в cookie. Сервер не получает jsessionid
Напротив, вызовы JSONP (которые динамически генерируют
Вопросы
- Какой самый простой способ получить вызовы ajax xmlhttprequest для передачи идентификатора сеанса (файлов cookie) в целевое приложение?
- Есть ли хорошие ссылки на ajax, cookie, xmlhttprequest и REST?
- Может ли кто-нибудь рекомендуете прочитать о разработке и аутентификации REST API?
Веб-сеансы, состояние и аутентификация
Я знаю, что REST должен быть без сохранения состояния, а повторное использование веб-сеансов кажется несколько хрупким (т. е. в отличие от использования OAuth и токенов аутентификации , как и netflix)
Это первая итерация, и мы были близки к тому, чтобы все «заработало». Это нормально работало с JSONP, но сообщения XmlHttpRequest не выполнялись.
заранее спасибо
Обновление:
Действительно наивный вопрос.
Оказалось, что размещение сообщений между сайтами через xmlhttprequest / ajax имеет внутренние проблемы с безопасностью и обходные пути. Например, Firefox не будет передавать файлы cookie с помощью XmlHttpRequest, если вы не добавите специальные заголовки. Затем Firefox выполнит «предполетную проверку» (т. Е. Вызов http OPTIONS) на сервер, чтобы увидеть «это нормально?». Ваш сервер должен ответить на вызов «OPTIONS», сказав «да, все в порядке», прежде чем Firefox выполнит ваше «сообщение с файлами cookie».
IE и Firefox решают эту проблему по-разному (то есть немного похоже на javascript примерно 1998 года). Я не понимаю, что делает IE, но, пережив 1998 год, мы не хотим идти по этому пути, если это вообще возможно.
Мы закодировали обходной путь.
Никто из нашей команды не знал об этом, когда мы начинали кодировать. (т.е.«jsonp отлично работал в прототипе; все остальное тоже должно»)
Ссылки: Как Mozilla решает эту проблему (HTTP-заголовки и предпечатная проверка) https://developer.mozilla.org/En/HTTP_access_control
Совместное использование ресурсов между источниками: http://en.wikipedia.org/wiki/Cross-Origin_Resource_Sharing