сравнение способов поддержания состояния

Question

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

Вот те, о которых я могу думать прямо сейчас:

1. Строка запроса

2. Печенье

3. Методы форм (получение и публикация)

4. Viewstate (только ASP.NET, я думаю)

5. Сеанс (веб-сервер InProc)

6. Сессия (Выделенный веб-сервер)

7. Сеанс (база данных)

8. Местное постоянство (Google Gears) (спасибо Стиву Мойеру) и т.д.

Я знаю, что у каждого метода есть свои преимущества и недостатки, такие как небезопасные файлы cookie и QueryString, имеющие ограничение по длине и выглядящие просто уродливо! ;)

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

Я хотел бы знать, какой метод (ы) вы обычно используете и порекомендует или, что более интересно, какой из этих методов вы бы хотели избежать в определенных сценариях и почему?

Answer 1

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

• Состояние строки запроса полезно только для самых основных задач - например, для поддержания позиции пользователя в мастере, возможно, или предоставления пути для перенаправления пользователя после выполнения им определенной задачи (например, для входа в систему). ). В противном случае состояние строки запроса ужасно небезопасно, трудно реализуемо, и для того, чтобы сделать его справедливым, его необходимо привязать к некоторому конечному автомату на стороне сервера с помощью ключа, чтобы связать клиента с поддерживаемым состоянием сервера для этого клиента.
• Состояние файла cookie более или менее одинаково - оно просто красивее, чем состояние строки запроса. Но он по-прежнему полностью поддерживается на стороне клиента, если только данные в cookie не являются ключом для привязки клиента к какому-либо конечному автомату на стороне сервера.
• Состояние метода формы снова аналогично - это полезно для сокрытия полей, которые связывают данную форму с каким-то битом данных на бэкэнде (например, «этот пользователь редактирует запись # 512, поэтому форма будет содержать скрытый ввод» со значением 512 "). Для многих это бесполезно, и опять же, это просто еще одна реализация той же идеи, лежащей в основе строки запроса и состояния cookie.
• Состояние сеанса (любой из описанных вами способов) прекрасно, так как они бесконечно расширяемы и могут обрабатывать все, что может обработать выбранный вами язык программирования. Первое предостережение заключается в том, что в руке клиента должен быть ключ, чтобы связать этого клиента с его состоянием, хранящимся на сервере; именно здесь большинство веб-платформ предоставляют клиенту ключ на основе cookie или на основе строки запроса. (Почти каждый современный использует куки-файлы, но использует строки запроса, если куки-файлы не включены.) Второе предостережение заключается в том, что вам нужно добавить некоторые из них в то, как вы сохраняете свое состояние ... вы положите его в база данных? Ваш веб-фреймворк обрабатывает это полностью для вас? Опять же, большинство современных веб-фреймворков берут на себя эту работу, и для реализации собственного конечного автомата мне нужна очень веская причина ... в противном случае я могу создать дыры в безопасности и поломка функциональности, которая со временем хэшируется в любой из зрелых платформ.

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

Answer 2

Безопасность также является проблемой; значения в строке запроса или полях формы могут быть тривиально изменены пользователем. Аутентификация пользователя должна быть сохранена либо в зашифрованном виде, либо в файле cookie с очевидным вмешательством, либо в сеансе на стороне сервера. Отслеживание значений, передаваемых в форме, когда пользователь завершает процесс, например, регистрацию на сайте, что, вероятно, может храниться в скрытых полях формы.

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

Answer 3

С ростом использования Web 2.0 я думаю, что в вашем списке отсутствуют два важных метода:

8 AJAX-приложения - поскольку страница не перезагружается и отсутствует переход от страницы к странице, состояние не является проблемой (но для сохранения пользовательских данных необходимо использовать асинхронные вызовы XML).

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

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

Answer 4

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

Answer 5

Будьте внимательны, в каком состоянии вы храните клиентскую часть (строки запроса, поля формы, файлы cookie). Все, что связано с безопасностью, не должно храниться на стороне клиента, за исключением, может быть, идентификатора сеанса, если он достаточно скрыт и трудно угадывается. Слишком много веб-сайтов имеют такие настройки, как «authenticated = true» и хранят их в файле cookie, строке запроса или скрытом поле формы. Для пользователя тривиально обойти что-то подобное. Помните, что ЛЮБОЙ ввод от клиента мог быть подделан и ему нельзя доверять.

Answer 6

Избегайте использования InProc, если вы планируете разместить свой сайт на дешевом хостинге, таком как webhost4life. Я усвоил трудный путь, что, поскольку их системы перегружены, они часто перерабатывают приложения очень , что приводит к потере сеанса. Очень надоедливый.

Они предлагают использовать StateServer, что хорошо, за исключением того, что вы должны сериализовать / десериализовать запись сеанса обратно. Я люблю объекты, и мое веб-приложение полно их. Меня беспокоит производительность при переходе на StateServer. Мне нужно провести рефакторинг, чтобы поместить в сеанс только то, что мне действительно нужно.

Жаль, что я не знал бы это прежде, чем я начал ...

Ура, Роб.

Answer 7

Лично, поскольку почти вся моя веб-разработка на PHP, я использую обработчики сессий PHP.

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

Answer 8

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

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