Как определить посетителя сайта, когда куки отключены и перезапись URL запрещена?

Question

В веб-приложении Java Java-сервлет создает уникальный jsessionid, который передается в виде файла cookie клиентскому браузеру для отслеживания последующих запросов клиента после первого. Но когда куки отключены и перезапись URL не разрешена из-за политики безопасности, я понимаю, что сервлет Java будет создавать новый объект сеанса для каждого запроса от одного и того же клиента. Это правильно? И означает ли это большую потерю серверной памяти (чрезмерное выделение памяти для каждого объекта сеанса, который никогда не будет использоваться снова, и чрезмерная сборка мусора)?

Одним из решений является использование в таком сценарии использования IP-адреса клиента и строки агента пользователя для однозначной идентификации пользователя и сохранения в базе данных. Это правильное решение?

Вышеуказанный сценарий довольно распространен в случае ботов поисковых систем, которые обычно делают тысячи частых запросов при посещении сайта.

Есть ли еще какие-нибудь мысли по созданию правильного решения этой проблемы для веб-приложения на основе Java?

Answer 1

Да, в этой ситуации сеансы будут создаваться каждый раз.Они стоят памяти и, в конечном итоге, их необходимо будет собрать с помощью GC.

Если вам не нужно отслеживать пользователей, вы всегда можете отключить создание сеансов.В JSP это немного сложно, поскольку страница обычно всегда создает сеанс.Однако есть директива, чтобы отключить это.

Однако вы можете написать оболочку запроса фильтра и сервлета, которая препятствует созданию сеансов.

В JSF есть очень печальная ошибка в большинствеиспользовала реализацию Mojorra 2.04, которая делает это более или менее невозможным, но, к счастью, Mojarra 2.1.0 исправила это.

В случае, если вам действительно нужно отслеживать пользователей, можно использовать форму снятия отпечатков пальцев.Это всегда приблизительно, и я не думаю, что вы должны использовать это для входа в систему.Пользовательский агент IP + - это форма снятия отпечатков пальцев, но из-за того, что прокси-серверы и крупные организации устанавливают один и тот же браузер для всех своих рабочих станций, это весьма ненадежно .Это нормально для статистики использования, но совершенно не подходит для входа в систему.

Альтернативы используют HTTPS / SSL, так как этот протокол имеет встроенный вид "идентификатора сеанса" или использует DOM или Flash-хранилище, что не всекто отключает куки, также отключает.