Как я могу кодировать вызов jquery ajax () (например, xmlhttprequest) для сохранения идентификатора сеанса (например, отправить cookie «jsessionID», уже находящийся в файлах cookie браузера)
Наш контекст:
- Два веб-приложения на основе Java
- Механизм единого входа регистрирует пользователя в обоих приложениях (т.е. имеет сеанс 101 с приложением A и сеанс 202 с приложением B)
- Приложение "A" использует javascript (jquery) для выполнения вызовов покоя для Приложения B
- Приложение B реализовало API отдыха в Java-джерси (fwiw)
- Все GET и "ОЧКИ старой школы" из приложения A в B подключаются к одному сеансу # 202 в "сеансе B"
- XmlHttpRequests (например, вызовы jquery 'ajax ()') не повторно используют сеанс # 202. Каждый XmlHttpRequest получает новый сеанс
Почему новые сессии?
Причина: XmlHttpRequest не передает куки в приложение B. Контейнер сервлета устанавливает jsessionid в куки. Сервер не получает jsessionid
Напротив, вызовы JSONP (которые динамически генерируют ) do , передают куки.
Вопросы
- Какой самый простой способ получить вызовы ajax xmlhttprequest для передачи идентификатора сеанса (cookie) в целевое приложение?
- Какие-нибудь хорошие ссылки на ajax, cookie, xmlhttprequest и REST?
- Кто-нибудь может порекомендовать прочитать о дизайне REST API и аутентификации?
Веб-сеансы, состояние и аутентификация
Я знаю, что REST должен быть без сохранения состояния, и повторное использование веб-сессий кажется несколько хрупким (то есть в отличие от использования OAuth и токенов аутентификации, как это делает netflix)
Это первая итерация, и мы были близки к тому, чтобы все "заработало". Это работало нормально с JSONP, но сообщения XmlHttpRequest не удалось.
заранее спасибо
Обновление:
Действительно, наивный вопрос.
Оказывается, что межсайтовая публикация через xmlhttprequest / ajax имеет присущие проблемы безопасности и обходные пути. Например, Firefox не будет передавать куки с 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