Наилучший вариант для управления сеансами в Java
Base64 является действительно правильным ответом, но CDATA не, это в основном говорит: "это могло быть чем-либо", однако это должно не быть просто чем-либо, это должны быть закодированные двоичные данные Base64. XML-схема определяет Основа 64 двоичных файла как примитивный тип данных , который можно использовать в xsd.
6 ответов
Все веб-платформы Java поддерживают файлы cookie или идентификаторы сеансов в кодировке URL. Они автоматически выберут правильный подход, поэтому вам ничего не нужно будет делать. Просто запросите объект сеанса из вашего контейнера, и он обработает детали.
[РЕДАКТИРОВАТЬ] Есть два варианта: файлы cookie и специальный URL-адрес. Есть проблемы с обоими подходами. Например, если вы закодируете сеанс в URL-адресе, люди могут попытаться передать сеанс (например, поместив URL-адрес в сообщение электронной почты). Если вы хотите понять это, прочтите пару статей о безопасности и создании серверов приложений. В противном случае: ваш сервер приложений Java сделает за вас правильные вещи. Не думай об этом.
Файл cookie просто хранит идентификатор сеанса, этот идентификатор бесполезен по истечении срока сеанса.
Спецификация сервлета определяет API для доступа / настройки данных сеанса в стандартном приложении J2EE. Также он определяет, что данные сеанса хранятся на стороне сервера и ничего не передается клиенту, кроме идентификатора сеанса. Существует 2 механизма передачи идентификатора сеанса:
1) URL-адрес запроса, например, jessionid = ....
2) cookie
Механизм определяется автоматически в зависимости от возможностей клиента.
РЕДАКТИРОВАТЬ . Нет лучшего варианта, есть спецификация сервлета, которая определяет путь.
Http - это протокол без отслеживания состояния, клиентский только по запросу.
Чтобы реализовать через него диалог с отслеживанием состояния, веб-серверу Java EE необходимо скрыть некоторую информацию (которая является идентификатором сеанса) в клиентском сторона и механизм, который он может использовать, должны соответствовать спецификации HTTP и HTML.
Есть три способа достижения этой цели:
- Перезапись URL : Сервер добавит дополнительный параметр в конец ссылки URL.
- ] Скрытый параметр в форме : сервер добавит дополнительный параметр в каждую форму в HTML.
- cookie : сервер попросит браузер поддерживать cookie.
В основном современный веб-сервер будет иметь " фильтр ", чтобы выбрать, какой способ использовать автоматически.
Поэтому, если Сервер обнаружил, что браузер уже отключил поддержку файлов cookie, он переключится на другие способы.
2 важных вопроса:
Какую веб-технологию вы используете? JSF, Struts, SpringMVC или просто сервлеты / JSP.
Сервлеты / JSP уже предоставляют вам необходимую поддержку сеанса.
Пример JSP:Здравствуйте, <% = session.getAttribute ("theName")%>Я действительно не думаю, что вам есть что беспокоиться о файлах cookie, поскольку данные безопасно хранятся на сервере и обрабатываются cookie выполняется автоматически.
Ваше приложение установлено на одном сервере?
Если ДА, то у вас нет проблем, используйте параметр сеанса сервлета.
Если НЕТ, то вам нужно найти другой способ сделать это. Например, используя липкий сеанс, или, может быть, проанализировать весь объект сеанса в запросах / ответах как поле. Этот вариант действительно требует от вас принятия мер безопасности.
The session management (client identification, cookie handling, saving session scoped data and so on) is basically already done by the appserver itself. You don't need to worry about it at all. You can just set/get Java objects in the session by HttpSession#setAttribute() and #getAttribute(). Only thing what you really need to take care of is the URL rewriting for the case that the client doesn't support cookies. It will then append a jsessionid identifier to the URL. In the JSP you can use the JSTL's c:url for this. In the Servlet you can use HttpServletResponse#encodeURL() for this. This way the server can identify the client by reading the new request URL.
Your new question shall probably be "But how are cookies related to this? How does the server do it all?". Well, the answer is this: if the server receives a request from a client and the server side code (your code) is trying to get the HttpSession by HttpServletRequest#getSession() while there's no one created yet (first request in a fresh session), the server will create a new one itself. The server will generate a long, unique and hard-to-guess ID (the one which you can get by HttpSession#getId()) and set this ID as a value of the cookie with the name jsessionid. Under the hood the server uses HttpServletResponse#addCookie() for this. Finally the server will store all sessions in some kind of Map with the session ID as key and the HttpSession as value.
According to the HTTP cookie spec the client is required to send the same cookies back in the headers of the subsequent request. Under the hood the server will search for the jsessionid cookie by HttpServletRequest#getCookies() and determine its value. This way the server is able to obtain the associated HttpSession and give it back by every call on HttpServletRequest#getSession().
To the point: the only thing which is stored in the client side is the session ID (in flavor of a cookie) and the HttpSession object (including all of its attributes) is stored in the server side (in Java's memory). You don't need to worry about session management youself and you also don't need to worry about the security.