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

Question

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

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

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

2. Файлы cookie

3. Методы формирования (Get и Post)

4. Состояние просмотра (ASP.NET только я предполагаю)

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

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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

Answer 4

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

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

Answer 5

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

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

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

Твое здоровье, Роб.

Answer 6

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

Answer 7

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

Answer 8

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

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