14. Управление состоянием
Управление состоянием в приложениях ASP.NET 2.0, куки, ViewState, query string (строка запроса), Session ID и режим cookieless
По умолчанию при работе с ASP.NET информация состояния, как в любом Web-приложении, не сохраняется. Это значит, например, что, если не принять специальных мер, то информация о том, что ввел/выбрал пользователь на одной странице при переходе на другую будет потеряна. Однако часто в реальных приложениях нам надо сохранять информацию сеанса (например, под каким именем пользователь зарегистрировался, что он выбрал на начальной странице и т.п.) в ходе всего сеанса.
В ASP.NET поддерживается два типа управления информацией о состоянии: серверный тип и клиентский тип. Серверный тип обеспечивает максимальную защищенность, но при этом расходует дополнительные ресурсы сервера. Клиентский тип менее ресурсоемок с точки зрения серверных ресурсов, однако его защищенность намного ниже.
При использовании серверного типа в вашем распоряжении:
· application state (информация приложения, общая для всех пользователей, например, информация о количестве посетителей Web-сайта);
· session state (информация конкретного пользователя, доступная только в его сеансе. Например, информация о выбранной им цветовой схеме);
· database state server — если информации состояния много, ее можно сохранять в базе (на SQL Server или другой). Этот способ можно использовать вместе с session state или c ookies.
· объект Cache — еще одна возможность работать с информацией состояния на уровне приложения.
При использовании клиентского типа вам доступны:
· куки — маленькие текстовые файлы, которые создаются на компьютере пользователя для хранения информации состояния;
· свойство ViewState — встроенная структура, которая обеспечивает хранение значений при повторном обращении к странице. Физически представляет собой скрытое поле в странице;
· query strings — информация состояния постепенно накапливается в строке запроса и передается при запросе каждой новой страницы, например:
В этом курсе из клиентских технологий будут рассмотрены только куки.
Работа с application state обеспечивается классом HttpApplicationState , который автоматически создается для каждого активного приложения ASP.NET. Сам по себе этот объект — всего лишь коллекция пар имя ключа/значение. У него множество свойств и методов, которые почему-то не подсказываются (можно получить информацию только через документацию). Фактически это — глобальная структура хранения, которая доступна со всех страниц W eb -приложения. В эту структуру можно добавлять значения ключ/значение ан уровне всего приложения, а затем извлекать их. Обычно используется для хранения данных, общих для всех сеансов, которые меняются не часто.
Информация session state хранится при помощи объекта HttpSessionState. Этот объект автоматически создается для каждого активного сеанса Web-приложения. По существу это — такой же набор ключей/значений, однако по сравнению с HttpApplicationState для этого объекта предусмотрено множество специфических свойств, при помощи которых можно получить информацию о сеансе или настроить его свойства. При желании информацию HttpSessionState можно сохранять в базе данных или на state server .
Набор комбинаций ключ/сеанс, который используется в этих объектах, называется hashtable (структура, очень похожая на словарь).
Каждый активный сеанс Web-приложения идентифицируется и отслеживается по уникальному 120-битному Session >e less Session ID ) и по нему и идентифицируется сеанс пользователя.
Серверная работа с состоянием требует обязательной передачи Session ID при помощи куки на клиентском компьютере. Для долговременного хранения информации сеанса (например, данных. которые пользователь ввел при регистрации) удобнее всего эту информацию сохранять на источнике.
В большинстве Web-приложений для работы с состоянием используются куки. Куки — это небольшой набор данных, который хранится или в текстовом файле на клиентском компьютере, или просто в оперативной памяти там же. Куки используются для хранения информации о конкршетном клиенте, сеансе или приложении. При обращении клиента на Web -сервер броузер посылает информацию куки вместе с запросом. Для каждого куки определяется домен, к которому этот куки предназначен. Для одного домена может быть использовано одновременно несколько куки.
Куки бывают двух видов:
· временные — живут только до закрытия окна броузера;
· постоянные — сохраняются на жестком диске компьютера и могут жить месяцами и годами (как им назначено). Internet Explorer сохраняет их в виде файлов с именами username @ domainname . txt .
Пользователь всегда может почистить куки на своем компьютере, так что такую возможность следует иметь в виду.
Куки — не очень безопасное решение (особенно по сравнению с применением HttpSessionState). пользователь легко может изменить значения куки на своем компьютере.
В каждом куки может храниться не более 4 Кбайт информации.
Теперь — о работе с файлом global.asax, который используется для обработки событий уровня приложений. Он автоматически создается на уровне Web-приложения и в нем присутствуют заранее готовые событийные процедуры на различные события в работе приложения (Application_Start, Session_Start, Application_BeginRequest, Session_End и т.п.)
Для того, чтобы использовать общую информацию на страницах Web-приложения, используются переменные уровня приложения и сеанса.
Переменные уровня приложения и сеанса инициализируются в событийных процедурах типа Start в global.asax. Для хранения информации уровня приложения используется объект Application, а уровня сеанса — Session. Хранение, как уже говорилось, производится в парах ключ/значение, и может выглядеть так (для сеанса):
Sub Session_Start(ByVal Sender As Object, _
ByVal e As EventArgs)
и так ( для приложения ):
Sub Application_Start(ByVal Sender As Object, _
ByVal e As EventArgs)
В ходе работы Web-приложения вы без проблем можете менять значения переменных уровня сеанса и приложения, например так:
Если с приложением может работать несколько пользователей, лучше обезопасить себя от проблем при одновременном изменении одних и тех же данных:
Считать записанную информацию можно также без всяких проблем:
HTTP — это протокол без сохранения состояния, поэтому Web-сервер не может определить, что сейчас происходит на компьютере пользователя: то ли пользователь читает Web-страницу, то ли уже давно закрыл окно броузера и занят своими делами. Поэтому обычно после какого-то времени отсутствия активности пользователя его сеанс закрывается по тайм-ауту.
В ASP.NET по умолчанию такой тайм-аут составляет 20 минут. Если пользователей может быть много, то для сохранения серверных ресурсов это время сокращают, если пользователям нужно заполнять сложные формы — время можно и увеличить.
Настройка тайм-аута для сеанса производится в файле web.config. Соответствующая часть выглядит так:
После того, как все сеансы пользователей завершены, Web-приложение немедленно выгружается из памяти и срабатывает событие Application_End.
По умолчанию информация состояния всех сеансов хранится in process — то есть в памяти, которая относится к процессу данного Web-приложения. Главная проблема при этом — в большом расходе памяти на сервере, если с ним одновременно работает большое количество пользователей. Поэтому в ASP.NET есть возможность хранить информацию состояния сеансов out of process :
1) в базе данных SQL S erver;
2) на специальном State Server (это может быть компьютер под управлением Windows 2000 Server и выше). В этом случае информация сеансов пользователей просто складывается в его оперативную память.
Главное преимущество таких решений — масштабируемость и возможность использования Web farms.
Как сохранять информацию состояний сеансов out of process ;
1) настроить SQL Server или state server.
Для настройки SQL Server достаточно прогнать при помощи OSQL специальный скрипт:
Этот скрипт создает базу данных ASPState со всем, что необходимо.
Для настройки State Server достатчоно на нем запустить службу ASP . NET .
2) объяснить Web-приложению, где оно должно хранить информацию состояния сеансов. Это делается через тот же файл web . config :
sessionState mode =» SQLServer «
Если используется State Server , нужно вместо имени SQL Server просто указать имя компьютера, на котором работает служба ASP.NET.
Теперь — про куки и Session ID.
Куки как часть заголовка протокола HTTP передаются на сервер с каждым клиентским запросом (или обратно с ответом сервера). Они позволяют хранить информацию не только на уровне текущего сеанса, но и между сеансами.
Куки создаются при помощи свойства Cookies объекта R esponse и класса Request. Свойство Cookies представляет коллекцию Cookies (экземпляр класса HttpCookieCollection ).
Создать новый куки с именем MyCookie можно так:
Dim objCookie As New HttpCookie(«myCookie»)
Dim now As DateTime = DateTime.Now
Добавить пары ключ/значение можно так:
Назначить время жизни Cookie — так:
Если время жизни куки не указано, то это будет временный куки и он будет жить только пока открыто окно броузера у клиента.
Чтобы этот куки со всеми настроенными параметрами был передан на компьютер пользователя, его надо добавить к объекту Response:
Если мы таким образом создали куки с именем пользователя и передали его в броузер пользователю, то выглядеть соответствующая часть заголовка HTTP будет так:
Set-Cookie: Username=John+Chen; path=/; domain=microsoft.com;
Expires=Tuesday, 01-Feb-05 00.00.01 GMT
Атрибут Domain генерируется автоматически броузером пользователя. Куки будет передаваться только на тот Web-сайт, который совпадает с указанным доменом.
При обращении на сайт microsoft.com в заголовке HTTP-запроса клиента будет стоять
Cookie: Username: John+Chen
Сами куки хранятся в каталоге \Documents and Settings\Username\Cookies, а имя файла куки выглядит как Username@DomainName.txt.
Чтобы программно получить информацию о значении куки, нужно обратиться к коллекции Cookies объекта Request :
Dim objCookie As HttpCookie = Request.Cookies(«myCookie»)
А затем извлекать из него нужные значения:
lblTime.ForeColor = System.Drawing.Color.FromName _
lblTime.BackColor = System.Drawing.Color.FromName _
Есть возможность обойтись и без куки. Для каждого сеанса ASP.NET генерирует уникальный идентификатор — SessionID, который вполне можно использовать для идентификации сеанса. Его применение позволяет решить различные проблемы в ситуациях, когда работа с куки отключена в броузере пользователя. Сохранение состояния сеанса средствами SessionID называется cookieless session.
Включается работа с cookieless в файле web.config. В нем нужно найти раздел sessionState и поменять значение в нем на true (по умолчанию false).
После этого любой запрос к странице Web-приложения будет переделываться на что-то вида
Однако при этом нужно помнить:
· при использовании cookieless session в проекте нельзя использовать абсолютные ссылки — только относительные;
· в большинстве броузеров максимальная длина URL — 255 символов.
Уроки ASP-технологий
Объект Application
Теперь давайте рассмотрим объект Application. Он предназначен для хранения глобальных переменных ASP-приложения, то есть переменных, которые доступны каждому сеансу приложения. Эти переменные находятся в коллекции Contents, к которой обычно обращаются сокращенно. Например, запишем следующий код в файл default.asp.
Затем создадим файл test.asp и наберем такой код:
После этого исполним сценарий default.asp, а затем test.asp. Последний выведет строку test в окне браузера. Вообще, в какой бы сценарий приложения мы не вставили код test.asp, результат будет одним и тем же.
Объект Application предоставляет разработчикам два метода:
Они предназначены для блокирования и разблокирования, соответственно, всего приложения. Например, чтобы избежать ситуации, когда в переменную уровня приложения записываются одновременно два значения, можно применить следующий код:
Кроме коллекций и свойств у объекта Application есть два события: Application_OnEnd и Application_OnStart, которые мы рассмотрим чуть позже.
Объект Session
Этот объект предназначен для управления сеансами. Он имеет четыре свойства:
Первые два свойства — это таблица кодировки и идентификатор локали. Их мы рассматривать не будем, так как они практически не используются.
Свойство SessionID доступно в режиме «только для чтения» и возвращает уникальный идентификатор сеанса. Использование:
Свойство TimeOut отвечает за время, через которое движок ASP прервет сеанс и удалит всю связанную с ним информацию на сервере. Установка этого свойства не позволяет оставлять данные о конкретном пользователе на сервере после того, как он отключился. Принимает значения в минутах. Например:
Объект Session имеет один метод — Abandon, который позволяет принудительно прервать сеанс до истечения срока, указанного в свойстве TimeOut. Пример использования:
В объекте Session, как и в объекте Application, можно хранить данные. Для этого используются переменные уровня сессии. Например:
Кроме того, объект Session предоставляет разработчикам два события: Session_OnStart и Session_OnEnd, которые мы рассмотрим немного ниже.
Файл Global.asa
С чего начинается … нет, не Родина — web-приложение? Ответ такой: с файла Global.asa. Он является главным файлом приложения. В этом файле могут существовать только следующие элементы:
- Четыре события: Application_OnStart, Application_OnEnd, Session_OnStart, Session_OnEnd;
- Тэги
Атрибут RUNAT всегда принимает значение Server. Атрибут SCOPE определяет область видимости компоненты (Application или Session). ID — это идентификатор, с помощью которого в дальнейшем можно будет получить доступ к объекту. Далее вы указываете PROGID или CLASSID, которые нужны, чтобы идентифицировать компонент.
Например, вы хотите создать экземпляр компонента BrowserCapabilities (он рассматривался выше), который был бы доступен каждому сеансу приложения. Для этого в файле global.asa необходимо написать примерно следующий код:
После этого вы получаете доступ к свойствам и методам данного компонента из любого сценария вашего приложения простым обращением к переменной MyBrowser. Например:
Также экземпляры ActiveX-компонентов можно создавать с помощью подключения библиотеки типов данной компоненты. Делается это следующим образом:
Атрибут TYPE всегда принимает значение TypeLib. В атрибуте FILE необходимо указать путь к библиотеке типов вашего компонента. UUID — это уникальный идентификатор этой библиотеки. Указывать можно либо FILE, либо UUID. VERSION — это, естественно, версия компоненты :-). Атрибут LCID отвечает за идентификатор локали.
Например, у вас есть библиотека динамической компоновки MyLib.dll, а у нее есть библиотека типов MyLib.lib. Вы можете подключить ее в файле global.asa вот таким способом:
Затем в любом сценарии приложения можно использовать этот компонент следующим образом:
Asp управление сеансами
2530 просмотра
2 ответа
46 Репутация автора
Мои требования — у меня есть веб-интерфейс, который дает мне все данные из базы данных. У меня есть веб-сайт .net, который использует этот API для получения всех данных. Теперь я хочу, чтобы при входе в систему на моем веб-сайте я хотел управлять сеансом в «API».
Я знаю, сессия в веб-API не очень хороший подход, но все же мне нужно сделать это.
Я уже реализовал управление сессиями в веб-интерфейсе API (взято здесь ), и он работает нормально, если я отправляю все свои запросы от почтальона (т.е. я устанавливаю переменные в сеансе, вызывая 1 метод, и извлекаю эту переменную сеанса, вызывая 2 метод). Но когда я делаю то же самое с веб-сайта asp.net с помощью jQuery, я не получаю хранимую переменную сеанса (я заметил, что каждый раз для каждого запроса я получаю разные идентификаторы сессии).
код сохранения переменной в сеансе
код извлечения переменной, сохраненной в сеансе
Что мне нужно сделать, чтобы достичь своей цели .. Ваше мнение спасет мои дни .
Ответы (2)
плюса
111 Репутация автора
Пожалуйста, прочитайте это хранилище Web Api Session ранее.
Чтобы получить данные из сеанса, используйте javascript sessionStorage (вместо ajax).
Как использовать управление сеансами с Load Balancer в Asp.Net
December 2020
11.7k раз
У меня есть четыре различных серверов и балансировка нагрузки. Я хочу использовать контроль над искаженным. Я сделал что-то с ним так:
Я создал handler.ashx создать проверочное изображение. Этот обработчик используется на главной странице. Я держу пароль управления в сессии CAPTCHA, при создании элемента управления искаженным. Затем я сравнил пароль, введенный пользователем с паролем в сеансе. Она работает очень хорошо, но только на одном сервере.
Это не правильно работать с четырьмя серверами. Хотя пользователь вводит правильный пароль каждый раз, иногда совпадает с паролем сессии, а иногда не совпадают. Я думаю, что причина проблемы заключается в следующем:
А, В, С и D являются четыре сервера. Балансировщику маршруты нагрузки первого запроса на сервер. Который открывает главную страницу с сервера и создает пароль «123456». Это хранится в сессии на сервере. Затем пользователь вводит пароль и кнопка нажата. Теперь балансировки нагрузки маршрутов этот запрос на сервер B. Поскольку сессия в B Sever имеет нулевое значение, пароли не совпадают.
Asp управление сеансами
Обновлен: Ноябрь 2007
Новый экземпляр класса веб-страницы создается каждый раз при отправлении страницы на сервер. Обычно в традиционном веб-программировании все сведения, связанные со страницей, и элементы управления на странице теряются при каждом цикле обработки. Например, если пользователь ввел сведения в текстовое поле, то эти сведения будут потеряны в ходе цикла обработки от веб-обозревателя или клиентского устройства к серверу.
Чтобы преодолеть это ограничение, свойственное традиционному веб-программированию, в ASP.NET включено несколько параметров, которые помогают сохранить данные как на уровне страниц, так и на уровне приложения. Это следующие свойства:
Состояние элемента управления.
Состояние представления, состояние элемента управления, скрытые поля, объекты cookie и строки запросов включают хранение данных на стороне клиента различными способами. Однако состояние приложения, состояние сеанса и параметры профиля хранят данные в памяти на сервере. Каждый параметр имеет свои преимущества и недостатки, в зависимости от сценария.
В следующих разделах содержится описание параметров для управления состоянием, которые сохраняют сведения либо на странице, либо на клиентском компьютере. При выборе этих параметров между циклами обработки на сервере никакие сведения не сохраняются.
Состояние представления
Свойство ViewState предоставляет объект словаря данных для сохранения значений между несколькими запросами одной страницы. Этот метод используется по умолчанию, чтобы сохранить значения свойств страницы и элементов управления между циклами обработки.
При обработке страницы текущее состояние страницы и элементов управления будут хэшироваться в строку и сохраняться на странице как скрытое поле или как несколько скрытых полей, если объем данных, сохраненных в свойстве ViewState , превышает значение, указанное в свойстве MaxPageStateFieldLength . При отправке страницы обратно на сервер страница анализирует строку состояния представления при инициализации и восстанавливает сведения из свойств на странице.
В состоянии представления возможно также сохранение значений. Дополнительные сведения об использовании параметра «Состояние представления» см. в разделе Общие сведения о состоянии представления ASP.NET . Рекомендации по использованию состояния представления см. в разделе Рекомендации по управлению состоянием ASP.NET .
Состояние элемента управления
Иногда требуется хранить данные состояний элементов управления для их правильной работы. Например, если был написан пользовательский элемент управления, который имеет различные вкладки, отображающие разные сведения, то чтобы этот элемент управления работал так, как ожидается, он должен знать, какая вкладка выбрана между циклами. Для этого можно использовать свойство ViewState , но состояние представления может быть отключено разработчиками на уровне страницы, что станет критичным для этого элемента управления. Чтобы разрешить эту проблему, в структуре страницы ASP.NET предусмотрено средство, называемое состоянием элемента управления.
Свойство ControlState позволяет сохранять сведения, имеющие отношение к элементу управления, и не может быть отключено, как свойство ViewState .
Скрытые поля
ASP.NET позволяет сохранять сведения в элементе управления HiddenField , который отображается в виде стандартного скрытого поля HTML. Скрытое поле не отображается в обозревателе, однако его свойства можно задавать так же, как и свойства стандартных элементов управления. При отправке страницы на сервер содержимое скрытого поля отправляется в коллекцию форм HTTP, как и значения других элементов управления. Скрытое поле служит хранилищем всех специфичных для страницы сведений, которые необходимо сохранить непосредственно на странице.
Примечание о безопасности. | ||||||
---|---|---|---|---|---|---|
Примечание о безопасности. | |||||
---|---|---|---|---|---|
Примечание о безопасности. | ||||
---|---|---|---|---|
Примечание. | |||
---|---|---|---|
Примечание о безопасности. | ||
---|---|---|
Примечание. | |
---|---|
Примечание. |
---|
Примечание. |
---|