Является ли веб-сессия «плохим дизайном»? Почему?

13

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

Он снова ответил мне, что даже в MS они могут легко ответить мне, что это плохой дизайн. И что он может показать мне несколько документов, демонстрирующих это.

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

abx78
источник
2
Протокол HTTP изначально разрабатывался как «не имеющий состояния», чтобы все транзакции были единичными и основывались на предоставленной информации. Сессии - это способ обойти это в некоторых случаях. Однако на практике для многих современных веб-сайтов я не могу придумать простой способ избежать сессий; может быть, я недостаточно креативен.
Katana314
@ Katana314 Хранение базы данных с файлами cookie. Вы можете использовать сеансы для самой базовой информации, такой как идентификация пользователя, но во многих реализациях сеансов (особенно в Django, которые мы неоднократно упоминали) есть недостатки, которые могут создавать условия гонки с большим количеством переходных данных, когда несколько запросов от одного пользователя отправляются сразу (как при вызовах AJAX)
Izkata
2
Хранение базы данных с файлами cookie - это всего лишь вопрос размещения вашей сессии в базе данных.
Алан Шутко

Ответы:

11

Я не думаю, что он имел в виду «плохой дизайн» так много, как «плохая практика». Вообще говоря, веб-приложение должно быть как можно без состояний, насколько это возможно. Даже если, например, вам может потребоваться информация о пользователе, чтобы авторизовать просмотр страницы, эта информация может быть сохранена на клиентском компьютере в форме файла cookie, и сервер просто проверяет информацию о пользователе каждый раз.

Это было бы идеально, но вы не всегда можете рассчитывать на то, что клиент сможет сохранить куки. Кроме того, это включает проверку пользователя в режиме без сохранения состояния, что потенциально включает запрос информации из базы данных для простого запроса страницы. Часто бывает проще сохранить такую ​​информацию в сеансе.

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

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

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

Нил
источник
1
but you can't always count on the client being able to save cookiesтогда AFAIK, вы не можете рассчитывать на сессии, либо. Разве куки не используются для определения того, какой сеанс принадлежит какому-либо пользователю, или существуют другие методы, и это просто наиболее распространенный способ?
Изката
Информация о сеансе обычно сохраняется на сервере для каждого соединения сервер / клиент, и это стало популярной тенденцией для крупных веб-сайтов, которые не могут полагаться на пользователей, имеющих включенные файлы cookie. Существуют опции (и / или библиотеки js), которые заставляют сохранять указанную информацию на клиентском ПК (который в последнее время становится очень популярным), но без HTML 5 файлы cookie - единственный способ добиться этого. Насколько мне известно, нет других способов сделать это.
Нил
8

Я думаю, что вы путаете две разные темы: 1) сессии и 2) модель страницы веб-форм asp.net

Веб-сессия необходима для аутентификации пользователя. В идеале сеанс должен использоваться только для этой цели. Вы не должны хранить пользовательские данные в сеансе (будь то на сервере, в файле cookie или как это делает asp.net/webforms: на самой странице). Никто не должен говорить, что веб-сессия плохая, а наоборот, хранение пользовательских данныхна сессии это плохая практика. Причины не сохранения пользовательских данных на сервере включают те же причины, чтобы избежать глобальных переменных. Хранение пользовательских данных в файлах cookie или на странице может привести к проблемам с безопасностью. Использование модели страницы asp.net также не соответствует природе Интернета. Вы можете сделать поиск, чтобы узнать больше о том, почему веб-формы плохой дизайн. Сеансы, с другой стороны, являются необходимой частью веб-приложений.

кодировщик
источник
«Сеансы, с другой стороны, являются необходимой частью веб-приложений». Нет.
masterxilo
6

Контроль и сохранение состояния сеанса на странице, по сути, взломать. Случай с MS - необходим, поскольку они хотели иметь возможность предоставить среду разработки, в которой вы могли бы разрабатывать страницы так, как вы можете в средах winform.

MS сами перешли к архитектуре MVC (последняя версия - MVC 4), которая является скорее возвратом к тому, каким должен быть протокол - без сохранения состояния.

Есть ситуации, когда сохранение состояния все еще удобно, но следует понимать, что это скорее исключение, чем правило.

Робби Ди
источник