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

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

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

  • Строка запроса

  • Cookies

  • Способы формы (Get and Post)

  • Viewstate (только для ASP.NET)

  • Сессия (веб-сервер InProc)

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

  • Сессия (База данных)

  • Локальное сохранение (Google Gears) (спасибо Стив Мойер) и др.

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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

Ответ 2

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

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

Ответ 3

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

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

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

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

Ответ 4

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

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

Ответ 5

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

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

Хотел бы я знать, что до того, как я начал...

Приветствия, Роб.

Ответ 6

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

Ответ 7

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

Ответ 8

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

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