Каков наилучший способ защиты пользовательских данных (еще не отправленных) от тайм-аута сеанса?

Я занимаюсь разработкой и поддержкой небольших веб-приложений для интрасети (JSP и Resin).

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

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

Что такое лучшие практики?


Приложение Наши пользователи делают несколько видов отчетов с помощью веб-приложения, и все содержимое каждого отчета хранится в JavaBean-хранилище, хранящемся в сеансе.

Как полагают некоторые, Ajax или iframe должны быстро исправить ситуацию.

Теперь я знаю, что лучше не злоупотреблять сессией с тяжелыми объектами, но я не уверен, как лучше всего изменить текущий беспорядок. Некоторые люди предлагали сделать веб-приложение без состояний . Любые предложения по рефакторингу приветствуются.

31.10.2008 00:45:24
9 ОТВЕТОВ

Мне только недавно нужно было искать решения этой проблемы.

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

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

2
31.10.2008 00:55:53
Если они все еще не работают под управлением Windows 95, я уверен, что их браузеры будут поддерживать AJAX.
ine 31.10.2008 00:58:11
@amdfan какая-то компания обязывает отключить javascrit в своей политике (что хорошо для безопасности)
Frederic Morin 31.10.2008 01:21:06

Вы можете время от времени хранить данные в файле cookie, использовать Gears в качестве временного хранилища (если данные сложны или требуют хранения более 4 КБ) или отправлять временные данные на сервер каждую n секунду, используя AJAX.

0
31.10.2008 00:57:05

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

7
31.10.2008 01:20:25
Почему это ужасно? Он будет поддерживать подключение всех пользователей, у которых все еще открыто окно браузера (т. Е. Есть вероятность, что они вернутся и захотят продолжить), при этом довольно быстро удаляются все действительно неиспользованные сеансы
Keeg 31.10.2008 07:22:09
@trustyteen: время ожидания сеанса по определенной причине, поэтому идеальное решение - написать приложение с нуля, чтобы корректно обрабатывать время ожидания сеанса (то есть без огромных форм). В качестве быстрого исправления метод AJAX-ping делает страницу менее безопасной. Увеличение таймаута сеанса сделает все страницы меньше.
MusiGenesis 31.10.2008 15:43:38
FWIW, я бы не использовал свое собственное предложение здесь. Если пользователи веб-приложения обычно теряют работу из-за тайм-аута сеанса, приложение просто необходимо переписать.
MusiGenesis 31.10.2008 15:48:24

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

Примером может быть что-то подобное в вашей форме:

<input type="hidden" name="user" value="bob" />
<input type="hidden" name="currentRecordId" value="2345" />
<input type="hidden" name="otherStuff" value="whocares" />

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

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

4
31.10.2008 01:22:33
Есть бесчисленные преимущества, нет необходимости в репликации сеансов между серверами, поэтому балансировка нагрузки становится проще простого (клиент не должен быть привязан к какому-либо экземпляру сервера). Большие объемные веб-приложения должны быть без сохранения состояния. Рефакторинг не так прост, если ваше приложение уже пронизано зависимостью от сеанса.
Lee Kowalkowski 31.10.2008 08:50:03
@ Jere.Jones и @Lee Kowalkowski. Можете ли вы предоставить ссылки для изучения веб-приложений без сохранения состояния?
ulm 31.10.2008 10:22:36
У меня нет ссылок. Сожалею. Это просто идея, которую я использую. Я даже не был уверен, что это был «настоящий» шаблон. :)
Jere.Jones 31.10.2008 15:31:21
@ulm: Ну, с архитектурной точки зрения было бы полезно, если бы одной из целей веб-приложения было RESTful ( en.wikipedia.org/wiki/REST ). По моему опыту я не был бы доволен этим как запоздалой мыслью для законченного заявления. Поскольку ваши URI потребовали бы много обдуманного.
Lee Kowalkowski 31.10.2008 21:24:18
@Lee Kowalkowski: Спасибо за информацию. Как вы указали, кажется сложной задачей переписать приложение без REST и сделать его RESTful. @ Jere.Jones: Спасибо, что ответили. Было бы интересно прочитать, если бы вы могли опубликовать свои идеи.
ulm 1.11.2008 04:00:50

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

Что вам нужно сделать, это добавить скрытый iframe где-нибудь на странице. Пусть iframe указывает на простой HTML-документ, обслуживаемый сервером приложений, в котором есть метатег для обновления каждые 29 минут (для сеанса, срок действия которого истекает через 30 минут). Таким образом, до тех пор, пока у человека открыта ваша веб-страница, его сеанс не истечет. Однако, когда они уходят с вашего сайта, он истекает как обычно. Вы получаете неограниченную продолжительность сеанса без недостатков сеансов, которые выходят из-под контроля.

Я успешно развернул это решение в корпоративной среде на прежнем месте работы. Веб-приложение заменило старое приложение с зеленым экраном, и для них было неприемлемо идти на обед и, к примеру, истек срок действия приложения.

Дайте мне знать, если вам нужно больше примеров.

2
31.10.2008 01:41:07
хотя сеанс все еще будет действительным, даже если на клиенте не будет файла cookie. кто-то еще может захватить их сессию.
Shawn 31.10.2008 03:51:01
Спасибо за предложение. Я думаю, что я попытаюсь добавить скрытый iframe для форм ввода отчета. (Просмотр отчета не стоит беспокоиться.)
ulm 31.10.2008 10:27:16

Я бы порекомендовал изучить альтернативу без состояния (то, что не зависит от атрибутов сеанса) тому, что вы делаете.

Возможно, мы сможем помочь больше, если будем знать, на что именно вы рассчитываете.

1
31.10.2008 02:03:52

Ммм ..

А как насчет отображения пользователю запроса о том, что сеанс скоро истечет - сохраните данные (скажем, за 5 минут), чтобы они могли сохранить данные. Таким образом, они знают, что им нужно сохранить, и в случае, если сеанс действительно нужно было истечь, это будет сделано позже, если они не ответят.

Это альтернатива в случае, когда вы хотите избежать непрерывного пинга на сервер с использованием AJAX.

0
31.10.2008 08:32:14
Спасибо за предложение. Я уже внедрил окно предупреждения о превышении времени ожидания, но наши пользователи часто прерываются во время создания отчета, поэтому всплывающее предупреждение, когда пользователи отсутствуют, не очень полезно.
ulm 31.10.2008 10:18:44

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

Это мое золотое правило разработки веб-приложений: не используйте сессию.

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

0
31.10.2008 09:05:08
Привет, у вас есть какие-либо признанные источники, поддерживающие ваше "золотое правило"? Я нахожу это интересной темой, чтобы углубиться в.
JacobE 31.10.2008 09:28:42

Я бы вызвал «после проверки Ajax, что сессия истекла» всплывающей формы в модальном окне, что пользователь должен войти снова. Это всплывающее наложение будет поверх текущей страницы / формы. Таким образом, данные не будут потеряны.

PN Обновите маркер сеанса, если у вас есть один ... в скрытом поле.

0
9.11.2015 10:54:08