Параметры хранения данных сеанса ASP, поступающие из PHP

Question

Я запустил ASP несколько месяцев назад, имея несколько лет опыта работы с PHP.

В PHP я использовал комбинацию куки-сессий PHP, куки-файлов и хранения идентификатора сессии в базе данных.

Когда человек входит в систему, идентификатор сессии записывается в файл cookie и сохраняется в столбце в базе данных.Если человек выходит из системы, файл cookie удаляется, если он забывает, это нормально, поскольку файл cookie живет только 72 часа.

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

Если файл cookie отсутствует, пользователь должен войти в систему.Старое значение для идентификатора сеанса, хранящееся в базе данных, просто обновляется.

Теперь, с ASP, кажется, есть больше вариантов.Из этой статьи: http://msdn.microsoft.com/en-us/library/ms178581.aspx

* Application state, which stores variables that can be accessed by all users of an ASP.NET application.

* Profile properties, which persists user values in a data store without expiring them.

* ASP.NET caching, which stores values in memory that is available to all ASP.NET applications.

* View state, which persists values in a page.

* Cookies.

* The query string and fields on an HTML form that are available from an HTTP request.

Я, вероятно, пока что буду придерживаться своей системы баз данных Session + cookie +, но что из этих других вещей, упомянутых здесь?Они кажутся мне загадочными.Возможна ли дальнейшая комбинация, чтобы сделать вещи еще более безопасными, или это было бы просто излишним?

Моя главная проблема в том, что возможно, система Session + Cookie + Database, которую я использую, может иметь недостаток.

Answer 1

Мы используем DNN (ASP на основе CMS) и разрабатываем модули. Мы много используем ViewState для хранения мелочей, таких как идентификаторы строк. Для просмотра состояния не требуется, чтобы в браузере были включены файлы cookie, но для больших объектов, таких как наборы данных, чтение, запись и передача могут стать тяжелыми. Поэтому мы сохраняем идентификатор строки и запрашиваем таблицу, когда происходит обратная передача.

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

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

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

Answer 2

Использование Session (в памяти или через базу данных) и Cookies для обработки и сохранения аутентификации и пользовательских данных обычно является стандартным подходом на веб-сайте ASP.NET.

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

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