Раньше я сильно полагался на переменные сеанса, но недавно обнаружил, что многие из них не нужны, вместо этого использовались такие вещи, как параметры строки запроса.
Мой коллега отказывается использовать переменные сеанса. Является ли это реалистичной целью и следует ли избегать переменных сеанса по каким-либо практическим причинам? Можно ли полностью избежать переменных сеанса (кроме файлов cookie сеанса, чтобы разрешить вход в систему), и приведет ли это к лучшему дизайну?
Вот некоторые причины, по которым мой коллега не использует их:
- Нетипизированная природа переменных сеанса
- Тайм-ауты сеанса, приводящие к потере состояния
- Глобальная область действия переменных сеанса
- Серверы балансировки нагрузки теряют сеансы (.Net специфичны?)
- Перезапуск пулов / серверов приложений
- Они не нужны
web-development
design
Tjaart
источник
источник
using things like query string parameters instead- В этом случае всегда всегда используйте параметры строки запроса, если это возможно. Использование сессии для этого типа параметра хрупко и может привести к странным ошибкам, когда у пользователей открыто несколько вкладок.Ответы:
Если в вашем приложении есть переменная сеанса, задайте себе вопрос:
Если ответ «текущее значение», переменные сеанса могут быть полезны. В качестве примера можно привести корзину покупок: вы не ожидаете, что что-то будет удалено из корзины покупок, когда вы вернетесь к истории. Это всегда в своем текущем состоянии.
Если ответ «предыдущее значение», вы не должны использовать переменные сеанса. Плохое использование, которое я видел, включает передачу параметра между страницами. Если я нажимаю кнопку «Назад», чтобы вернуться на страницу, страница не обязательно получает правильный параметр. Кроме того, если я открою две вкладки, как будет вести себя мой сайт?
Правильное поведение кнопки «Назад» ни в коем случае не является обязательным, но помогает вам рассматривать веб-сайт как приложение без сохранения состояния. В общем, я считаю, что подходящие варианты использования переменных сеанса немногочисленны.
источник
Протокол HTTP не имеет состояния. Сеансы - это способ сохранить состояние клиента в HTTP-запросах. Вы можете сделать это с помощью встроенной в сеанс обработки платформы или сделать это самостоятельно с параметрами строки запроса. В любом случае некоторая концепция сеанса необходима для многих задач.
Ваш коллега, вероятно, не любит конкретную реализацию или не использует сессии по назначению. Если вам нужно сохранить информацию о конкретном клиентском соединении через HTTP-запросы, вам нужна некоторая форма сохранения сеанса.
Следующие вопросы зависят от реализации:
Например, я чаще всего работаю в PHP и храню информацию о сеансе в реляционной базе данных. Так что мои переменные сеанса набраны. Балансировка нагрузки и перезапуск сервера не вызывают проблем сессий.
Этот более интересный:
Сессии чаще всего сохраняются с помощью файлов cookie. Они могут быть удалены клиентом в любое время. Но они также могут быть сохранены с помощью параметра строки запроса и, следовательно, никогда не превышают время ожидания на клиенте. Время ожидания сервера зависит от вас. Так что даже эта проблема зависит от конкретной реализации.
Давайте не будем отбрасывать всю концепцию сессий только потому, что нам не нравится конкретная реализация. Любая хорошая платформа веб-приложений будет способствовать правильному использованию сеансов для сохранения пользовательских логинов или сохранения чего-либо другого, специфичного для текущего посещения пользователя. Запись базы данных пользователя может (и должна) использоваться для хранения специфических для них вещей при входе в систему. Однако анонимные посетители могут иметь временную информацию, которую также стоит сохранить в своем сеансе, такую как короткий список последних посещенных страниц или предпочтение скрыть уведомление, которое они уже видели. Обычно для хранения сеанса подходит только небольшая временная информация.
источник
Другие высказали много хороших замечаний (которые я не буду повторять), но есть один аспект техники вашего приятеля, который еще не обсуждался: безопасность .
Невозможно узнать, какие именно уязвимости вы открываете, не глядя на код, но вот несколько вещей, которые я могу придумать, не в голову.
Все это может произойти, когда вы используете сеансы, но они могут стать намного проще, если ваш собеседник не знает, что он делает.
источник
Переменные сессии в некоторой степени похожи на старые глобальные переменные Basic. Пользователь обязан следить за ними, что в них, их сфере применения и как они используются; как в старых версиях бейсика. При этом зачем кому-то полностью отказываться от использования механизма, который, очевидно, предназначен для того, чтобы стать неотъемлемой и очень важной частью модели программирования (ASP, MVC и т. Д.)?
Единственная плохая вещь, с которой я столкнулся при использовании переменных Session, - это то, что на вас ложится бремя, чтобы отслеживать их, убедиться, что они заполнены соответствующими данными и утилизировать их.
Разве это не то, что мы делаем, когда программируем?
источник
Раньше я думал, как ваш коллега, из-за какого-то плохого опыта, у меня были проблемы с отладкой, связанные с переменными сеанса, которые были просто некомпетентностью с моей стороны. Да, вы можете обойтись в некоторой степени без переменных сеанса, используя строки запроса, скрытые поля в формах и другие вещи. Однако это очень быстро становится громоздким, если в вашем приложении есть что-то, выходящее за рамки самого простого логического потока для определения состояния. Существует также риск для безопасности, показывающий внутреннюю работу вашего приложения через строки запросов и скрытые поля, любое из которых может служить вектором атаки.
При работе с переменными сеанса вам просто нужно отслеживать, когда они установлены и не установлены, так как это определит логический поток приложения. Это похоже на управление памятью на языке вроде C.
Обратите внимание, что это только из моего опыта работы с PHP в относительно небольшом проекте без фреймворков, на других платформах все может быть по-другому, но я думаю, что общий принцип все еще применяется.
источник
Как уже говорилось ранее, HTTP - это Stateless, а Session Variable нарушает это. Разработка HTTP без сохранения состояния помогает кэшированию ресурсов. Для ресурсов, которые являются общедоступными.
Можно создать сайт без переменной сеанса, но это сложнее. Самым сложным (IMHO) является причудливый вход / выход из системы, схемы аутентификации HTTP не предоставляют инструментов, необходимых для аутентификации через HTML-форму (вы можете взломать что-нибудь с помощью javascript - XHR для https: // untel: passowrd@mydomain.com ) и Еще сложнее выйти из системы и быть совместимым с различными браузерами. было некоторое обсуждение списков рассылки w3 по этому поводу, но если я правильно помню, идея была отброшена.
В остальном вы должны быть в состоянии жить без переменных Session. У вас будет какое-то состояние в базе данных, файлах или где угодно, но использование переменных сеанса должно быть редким.
Если у вашего пользователя есть корзина покупок, это переменная сессия, только если предполагается, что пользователь сможет просматривать два компьютера / браузера без совместного использования корзины.
источник