Как я могу делать сессии URL очень длинный, я не могу добавить JSESSIONID = 389729387392.Какое решение для этого?

Question

Я получил ответ: если я отключил куки, то с помощью URL ReDirect я могу передать JSESSIONID, но мой URL уже очень длинный, так как я использую метод GET, у него есть ограничение. Тогда как я должен использовать свои сеансы. Я хочу, чтобы мое приложение было очень требовательным к безопасности. Это один из вопросов, заданных моему другу в интервью GOOGLE.

Answer 1

Помимо использования однобуквенных имен параметров (например, ?a=value1&b=value2&c=value3 или использования RESTFul-подобных URL-адресов (т. Е. Просто pathinfo, без параметров запроса, например, /value1/value2/value3, который доступен по HttpServletRequest#getPathInfo() в сервлете) вместо ?name1=value1&name2=value2&name3=value3 вы также можете рассмотреть возможность кодирования строки запроса Gzip и Base64, чтобы она стала короче. И JavaScript, и Java способны (де) сжимать и (d) е (n) кодировать ее .В конце концов вы можете отформатировать строку запроса в JSON перед сжатием / кодированием, в случае массивов / коллекций / карт она будет короче.

Тем не менее, вы уверены, что URL-адреса запроса часто бывают слишком недружелюбными (при условии, что это более 255 символов)? Зачем вам нужно передавать эту много информацию? Они должны поддерживать состояние клиента? Если это так, вы не должны использовать URL для этого, но экземпляр HttpSession на стороне сервера, который уже связан с куском jsessionid. Используйте HttpSession#setAttribute() для хранения некоторой информации в сеансе и используйте HttpSession#getAttribute() для ее получения.

Answer 2

Насколько я понимаю, ваша главная проблема с JSESSIONID в URL - это общая длина.

Возможно, вам стоит поближе взглянуть на то, почему длина URL-адресов слишком велика. Поскольку у вас уже есть сеанс, не исключено, что вы можете переместить некоторые параметры GET в сеанс. Существует также множество различных способов создания более коротких URL-адресов для страниц (например, mod_rewrite).

Что касается безопасности, JSESSIONID так же уязвим с HTTP GET, как и HTTP POST. Кодирование base64 HTTP POST не является мерой безопасности вообще. Лучший способ получить немного больше безопасности - это зашифровать транспортный канал через TLS / SSL, фактически включив HTTPS. Это гарантирует, что подслушивающий (или человек в середине атаки) не будет иметь доступа к простому тексту.

Answer 3

Если URL слишком длинный, вам нужно хранить эти данные в другом месте. Большинство сайтов помещают идентификатор сессии в файл cookie.

Answer 4

Если вы хотите, чтобы ваше приложение требовало высокой безопасности, почему вы используете GET. Используйте POST. Это также уменьшит длину URL.

Таким образом, согласно протоколу HTTP, максимальная длина URL-адреса не ограничена. Большую часть времени это браузер, который устанавливает ограничение максимальной длины. Попробуйте разные браузеры

Вы должны выдвинуть вышеперечисленные пункты интервьюеру. Они могут быть более заинтересованы в вашей способности оценить систему в целом и выявить какие-либо фундаментальные недостатки.