Лучшие варианты использования сессий в веб-приложении Java

Question

Я всегда пытался избежать использования сессий. Я использовал Spring Security или другие способы входа пользователя в приложение, что, я полагаю, является основным вариантом использования Sessions.

Но каковы другие варианты использования? Не могли бы вы составить список этих самых важных? Как получилось, что я смог разработать даже сложные приложения без использования сессий?

Это потому, что я использую spring-mvc и использование Sessions практически не требуется, кроме входа в систему?

РЕДАКТИРОВАТЬ: Ребята, этот вопрос задавался для вариантов использования ... Большинство ответов объясняет, для чего сеансы. Если мы суммируем некоторые примеры использования, мы можем точно сказать, когда использовать базу данных или сеансы для поддержания состояния диалога ... Разве вы не помните какие-то конкретные сценарии, для которых вам нужны были сеансы? За прошедшие годы:)

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

Answer 1

Я думаю, что вы можете делать все что угодно, не сохраняя ничего на сессиях.

Обычно я использую сеансы, чтобы избежать необходимости передавать состояние между клиентом и сервером (в качестве примера используется id) и , когда я не хочу отправлять конфиденциальную информацию клиенту (даже в зашифрованном виде). форма), как это может быть проблема безопасности.

Другие способы избежать использования сеанса: * сохранить состояние в базе данных, например, корзины покупок, а не в сеансе, даже если корзина сбрасывается через некоторое время. * хранить состояние в куки, например для настройки пользователя

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

редактировать

Беседы (в моем понимании) - это нечто вроде волшебников, в которых вы заполняете несколько форм на разных страницах и в конце выполняете действие. например В процессе оформления заказа пользователь вводит свои данные, адрес доставки и данные кредитной карты на разных страницах, но вы хотите отправить заказ только в конце, без сохранения промежуточного состояния в вашей БД.

Под конфиденциальной информацией я имею в виду, представьте себе в предыдущем примере, как только пользователь отправил данные своей кредитной карты, вы не должны возвращать эту информацию в любом формате (даже зашифрованном) пользователю. Я знаю, что это немного параноидально, но это безопасность :).

Answer 2

Что ж, в одном смысле ваш вопрос глубокий (что особенного в сеансе стоит знать), а в другом смысле поверхностный (что я не могу сделать, если я их не использую, оказывается несколько странным вопросом)

В конце концов, Session - это просто (или может быть) ConcurrentHashMap (на самом деле это обычно не тот потокобезопасный) с ключом уникального идентификатора сеанса, передаваемого как cookie. Вы знаете, почему это полезно, но вам ответят за варианты использования

• кластеризация (так распределяется состояние по узлам)
• кэширование общего состояния пользователя и его объектов (в отличие от перезагрузки из базы данных каждый раз)
• встроенные методы для сессионных слушателей, чтобы наблюдать, когда у кого-то истекло время ожидания или атрибуты изменились. = используется многими утилитами локализации

Можете ли вы сделать все это с помощью базы данных или собственной реализации / фильтра hashmap? Конечно, нет ничего волшебного в сессиях. Они являются просто удобным стандартом для того, чтобы некоторые объекты следовали за вошедшим в систему пользователем и были привязаны к продолжительности использования этого приложения пользователем.

Почему вы используете сервлеты? Вы могли бы также реализовать свой собственный стандарт уровня сокетов? Ответом на это является использование стандартных API-интерфейсов / реализаций, обеспечивающих удобство, и другие библиотеки основаны на них.

Минусы

• вы заново изобретаете колесо и код, проверенный временем
• вы не сможете использовать множество встроенных средств для мониторинга / управления / кластеризации / локализации и т. Д.

Answer 3

В системе электронной коммерции, над которой я работаю, есть внутренняя система, которая хранит сохраненные адреса доставки и выставления счетов пользователями.Наше веб-приложение обращается к нему, делая вызовы веб-службы для получения этих адресов.Когда мы получаем адреса, мы сохраняем их в сеансе.Таким образом, нам нужно вызывать службу только один раз, когда пользователь сначала просматривает их адреса, а не каждый раз, когда мы обслуживаем страницу, которая нуждается в адресной информации.У нас есть время, чтобы жить по адресам, поэтому, если адреса меняются (например, если пользователь звонит в службу поддержки клиентов, чтобы изменить адрес), мы в конечном итоге подберем новые.

Это будетможно хранить адреса в нашей базе данных, а не в сеансе.Но почему бы нам?Это временная информация, которая уже постоянно хранится где-то еще.Сессия - идеальное место для этого.

Answer 4

Привет, вы можете взять пример корзины покупок, потому что, поскольку Http является протоколом без сохранения состояния, он не поддерживает статус пользователя, отправляющего запрос.

Например, Если один пользователь отправляет запрос на покупку камеры, например, через eBay, а через несколько минут другой пользователь отправляет запрос на покупку ноутбука.

Но так как http - это протокол без сохранения состояния, поэтому сервер не может разделить запрос, отправленный пользователями, и может случиться так, что счет ноутбука может быть передан первому пользователю.

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

Answer 5

Сеансы - это один из способов поддержания разговорного состояния для нескольких запросов (например, нескольких HTTP-запросов без сохранения состояния).

Существуют и другие способы реализации диалогового состояния, например, сохранение токена аутентификации или некоторого подходящего идентификатора разговора в качестве файла cookie и поддержание сохранения идентификатора диалога в состоянии сеанса. (По сути, дублирование действий сервера приложений при предоставлении сеансов.)

То, что вам не нужно использовать сеансы, означает, что вашему приложению либо не нужно диалоговое состояние, либо вы реализовали его по-другому. Например, возможно, ваше приложение использует токен аутентификации (скажем, cookie) и сохраняет все изменения состояния в базе данных. При такой договоренности нет необходимости в состоянии разговора.