Asp объект session


Содержание

Asp объект session

Веб-сервер автоматически создает объект Session для каждого пользователя, который обращается к asp-сценарию. С помощью объекта Session можно сохранять некоторую информацию в течение сеанса работы клиента. (О том, зачем это нужно, мы говорили, рассматривая использование ключиков Cookies). Работа с объектом Session основана на использовании cookies и невозможна, если браузер их не поддерживает. В отличие от cookies, сессия действует ограниченное время, по истечении которого объект Session уничтожается.

Каждая сессия занимает приблизительно 10 Кб памяти (сверх самих данных, сохраненных в объекте Session) и немного замедляет выполнение всех запросов.

Причины завершения сессии

Истечение времени, установленного как значение свойства Timeout (по умолчанию — 20 минут), если в течение этого времени от клиента не поступает запросов на обновление страницы или загрузку нового документа.

Чтобы снизить объем серверной памяти, занятой приложением, имеет смысл устанавливать реальные значения длительности жизни объекта Session. Например, если пользователь, по Вашему мнению, не задержится на сайте дольше 5 минут, установите:

&lt% Session.Timeout = 5 %&gt

Объект Session уничтожен из asp-сценария (методом Abandon()):

&lt % Session.Abandon(); %&gt

Сбой web-сервера или его остановка администратором.

В этом случае уничтожаются все сессии. Удаление (или запрет) cookies в браузере. Изменение файла Global.asa.

Идентификатор сессии

При первом обращении браузера к web-серверу (точнее, к одному из asp-сценариев) web-сервер создает уникальный, присущий только этому браузеру идентификатор сессии (SessionID); этот идентификатор и используется для того, чтобы web-сервер мог «узнать» этот браузер при последующих обращениях.

SessionID сохраняется браузером (как cookie) пока не произойдет одно из перечисленных выше событий, в результате которых объект Session будет уничтожен.

Идентификатор сессии является свойством объекта Session, обращение к нему выглядит, например, так:

Переменные объекта Session

Объект Session позволяет сохранять информацию с помощью скалярных переменных или объектов. Например, сохраним в документе first.asp имя и возраст клиента, а также его login:

В этом же документе разместим ссылку на другой документ данного приложения (назовем его second.asp)? где предусмотрим обращение к переменным сессии:

С помощью объекта Session можно, например, запомнить свойства браузера и в зависимости от них формировать тот или иной вариант web-страницы. При этом отпадает необходимость анализировать свойства браузера в каждом документе. Например, пользователям с низким разрешением экрана можно предложить текстовую версию страницы:

Задание 1. Создайте в одном директории два asp-файла, связанных взаимными гиперссылками. В каждом из этих файлов предусмотрите вывод значения идентификатора сессии.

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

Недостатки Session

Сессии имеют несколько недостатков, которые проявляются в следующих случаях:

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

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

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

ASP без объекта Session

ASP позволяет создавать asp-документы, не формирующие объекта Session. Для этого нужно использовать директиву:

&lt%@ EnableSessionState=False %&gt

Объект Application

Как отмечалось выше, сессии не охватывают все задействованные в веб-приложении серверы — созданный на сервере объект Session доступен только на нем. Это означает, что при использовании сессий на мультисерверном веб-сайте, обязательно должно происходить перенаправление запросов каждого пользователя на тот сервер, на котором существует сессия этого пользователя. Это называется «застреванием» пользователя на сервере (или «липкой» сессиейsticky session).

Частично эту проблему можно решить за счет использования объекта Application. В отличие от объекта Session, позволяющего «закреплять» данные за конкретным пользователем, объект Application позволяет создавать переменные, доступные одновременно всем пользователям web-приложения. Под приложением понимаются все .asp-файлы в виртуальной директории и всех ее поддиректориях.

Поскольку объект Application доступен (shared) более чем одному пользователю, в нем предусотрено два метода — Lock (заблокировать) и Unlock (разблокировать). Они используются, чтобы сразу несколько пользователей не могли изменить содержимое общедоступных переменных одновременно.

IT-ЗАМЕТКИ

Инструменты пользователя

Инструменты сайта

Содержание


Объект Session является экземпляром класса System.Web.SessionState.HttpSessionState.

Session позволяет хранить сведения уникальные для каждого пользователя, такие как права пользователя, его идентификатор, индивидуальные настройки (цвет текста в чате, например) и т.п. Использование свойства Session предельно просто:

Если на одну и ту же страницу может попадать как зарегистрированный пользователь так и незарегистрированный, то надо просто проверять свойство на равенство null:

Свойство Timeout принимает в виде целого числа количество минут, по истичение которых с момента последнего обращения пользователя сессия будет завершена.
По умолчанию Timeout=20. Т.е. через 20 минут после последнего обращения пользователя сессия будет закрыта. И если он обратится снова, то для него будет открыта новая сессиия.

Следующий пример выведет значение Timeout в HTML -страницу

Конфигурирование состояния сеанса

Сконфигурировать состояние сеанса можно с помощью элемента в файле web.config. Ниже показаны все доступные параметры настройки, которые можно применять:

Параметр настройки состояния сеанса Mode позволяет указать, какой поставщик состояния сеанса должен использоваться для хранения данных состояния сеанса между запросами.

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

InProc

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

StateServer

Выбрав режим StateServer, обязательно следует указать значение для параметра stateConnectionString. Эта строка сообщает TCP/IP-адрес компьютера, на котором запускается служба StateServer, и номер его порта (который определяется ASP .NET и который обычно изменять не нужно), что позволяет обслуживать службу StateServer на другом компьютере. Если не изменить значение этого параметра, использоваться будет локальный сервер (с адресом 127.0.0.1).

SQLServer

Установка значения для атрибута sqlConnectionString выполняется по схеме, подобной той, что применяется для получения доступа к данным ADO.NET. В целом это подразумевает указание источника данных (адреса сервера), имени пользователя и пароля, если только не используется интегрированная система безопасности SQL .

Вдобавок также должны быть установлены специальные хранимые процедуры и временные базы данных сеансов. Эти хранимые процедуры будут отвечать за сохранение и извлечение данных сеанса. В состав ASP .NET входит утилита командной строки, позволяющая выполнять эту задачу автоматически. Называется она aspnet_regsql.exe и находится в каталоге c:\Windows\Microsoft.NET\Framework\[Версия].

Custom

Выбор специального (Custom) режима требует указания используемого поставщика хранилища данных о состоянии сеанса с помощью атрибута customProvider. В атрибуте customProvider может быть задано как имя класса, являющегося частью веб-приложения и хранящегося в каталоге App_Code, так и имя класса, входящего в состав скомпилированной сборки и хранящегося в каталоге Bin или в глобальном кэше сборок (GAC).

К числу наиболее распространенных причин для применения специального поставщика хранилища данных о состоянии сеанса относится необходимость хранить информацию сеанса в базе данных, отличной от SQL Server, и потребность использовать какую-то существующую таблицу в базе данных, которая имеет определенную схему.

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

compressionEnabled (Сжатие)

Cookieless

Параметр Cookieless может быть установлен в любое из значений перечисления HttpCookieMode. С помощью атрибута cookieName можно указать имя, используемое для cookie-набора. Если оно не указано, для имени cookie-набора принимается значение по умолчанию, которое выглядит как ASP .NET_SessionId.

Значение Описание
UseCookies Cookie-наборы используются всегда, даже если браузер или устройство не поддерживает их или если они были отключены. Это значение устанавливается по умолчанию. Если устройство не поддерживает cookie-наборы, информация сеанса будет утрачиваться при последующих запросах, потому что каждый запрос будет получать новый идентификатор
UseUriCookie Cookie-наборы не используются никогда, независимо от возможностей браузера или устройства. Вместо этого идентификатор сеанса сохраняется в URL -адресе
UseDeviceProfile ASP .NET решает, какие сеансы использовать (с поддержкой cookie-наборов или без), анализируя содержимое объекта BrowserCapabilities. Недостаток такого подхода заключается в том, что этот объект указывает, что устройство должно поддерживать: он не учитывает того факта, что пользователь мог отключить cookie-наборы в браузере, который в принципе их поддерживает
AutoDetect ASP .NET пытается определить, поддерживает ли браузер cookie-наборы, пробуя установить и извлечь cookie-набор. Эта широко используемая технология позволяет точно определить, когда браузер поддерживает cookie-наборы, но это средство было отключено, указывая ASP .NET применять режим без поддержки cookie-наборов

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

Timeout

Еще одним важным параметром настройки состояния сеанса в файле web.config является Timeout. Он указывает количество минут, в течение которых ASP .NET будет находиться в режиме ожидания (не получая запрос), прежде чем завершит сеанс:

Этот параметр является одним из наиболее важных параметров состояния сеанса. Неправильно выбранное количество минут может значительно увеличить нагрузку на сервер и крайне негативно сказаться на производительности приложения. В идеале выбираемый промежуток времени должен быть достаточно коротким для того, чтобы сервер мог быстро восстанавливать бесценные ресурсы памяти после того, как клиент прекращает использовать приложение, но и достаточно длинным для того, чтобы клиент мог делать паузу и продолжать сеанс, не утратив его.

Значение параметра Timeout можно также изменять в коде. Например, если известно, что сеанс содержит чрезвычайно большое количество информации, время хранения сеанса лучше ограничить. Для этого можно отобразить пользователю соответствующее предупредительное сообщение и затем просто изменить значение свойства Timeout. Следующая строка кода ограничивает время тайм-аута до 10 минут:

> Ask Question

I am new to classic ASP and I need to code a web application in classic asp because the customer wants it to be in classic asp. :(

Anyways! here is my question:

When I have a object of a class called person:

On the next request , I try to read the session var like :

Any ideas about what is going would be of great help.

6 Answers 6

I can’t explain why your code doesn’t work looks fine to me.


The object is created in a script context which is subsequently torn down after the request is complete. Hence whilst the type name is available the object’s function is broken.

I can tell you its not a good idea to store objects in the Session even those not created in script.

Most objects used in ASP exist in a single thread. Once created only the thread that created the object may access the object. To cope with this once you have stored an object in the session ASP affiliates the session with the specific worker thread that created it the object.

When a subsequent request for that session arrives it must now be handled by its specific worker thread. If that thread happens to be busy working for some other request the sessions request is queued, even if there a plenty of other available worker threads.

The overall effect is to damaging the applications scalability where the work load can become unevenly distributed across the worker threads.

Состояние сеанса и приложения в ASP.NET Core Session and app state in ASP.NET Core

HTTP — это протокол без отслеживания состояния. HTTP is a stateless protocol. Без дополнительных действий HTTP-запросы являются независимыми сообщениями, которые не сохраняют значения пользователя или состояние приложения. Without taking additional steps, HTTP requests are independent messages that don’t retain user values or app state. В этой статье описывается несколько подходов для сохранения данных пользователя и состояния приложения между запросами. This article describes several approaches to preserve user data and app state between requests.

Управление состоянием State management

Состояние можно сохранить несколькими способами. State can be stored using several approaches. Эти способы обсуждается ниже в данном разделе. Each approach is described later in this topic.

Способ хранения данных Storage approach Механизм хранения Storage mechanism
Файлы «cookie» Cookies Файлы cookie HTTP (могут содержать данные, сохраненные с помощью кода приложения на стороне сервера) HTTP cookies (may include data stored using server-side app code)
Состояние сеанса Session state Файлы cookie HTTP и код приложения на стороне сервера HTTP cookies and server-side app code
TempData TempData Файлы cookie HTTP или состояние сеанса HTTP cookies or session state
Строки запросов Query strings Строки запросов HTTP HTTP query strings
Скрытые поля Hidden fields Поля формы HTTP HTTP form fields
HttpContext.Items HttpContext.Items Код приложения на стороне сервера Server-side app code
Кэш Cache Код приложения на стороне сервера Server-side app code
Введение зависимостей Dependency Injection Код приложения на стороне сервера Server-side app code

Файлы cookie хранят данные между запросами. Cookies store data across requests. Так как файлы cookie отправляются с каждым запросом, их размер нужно свести к минимуму. Because cookies are sent with every request, their size should be kept to a minimum. В идеальном случае файл cookie должен содержать лишь идентификатор, а сами данные хранятся в приложении. Ideally, only an identifier should be stored in a cookie with the data stored by the app. Большинство браузеров позволяют использовать файлы cookie размером до 4096 байт. Most browsers restrict cookie size to 4096 bytes. Для каждого домена доступно лишь ограниченное число файлов cookie. Only a limited number of cookies are available for each domain.

Так как файлы cookie могут быть незаконно изменены, их нужно проверять в приложении. Because cookies are subject to tampering, they must be validated by the app. Файлы cookie могут удаляться пользователем и имеют ограниченный срок хранения на клиентах. Cookies can be deleted by users and expire on clients. Тем не менее файлы cookie обычно являются самым надежным способом хранения данных на стороне клиента. However, cookies are generally the most durable form of data persistence on the client.

Файлы cookie часто используются для персонализации, когда содержимое настраивается под известного пользователя. Cookies are often used for personalization, where content is customized for a known user. В большинстве случаев пользователь проходит только идентификацию, а не проверку подлинности. The user is only identified and not authenticated in most cases. Файл cookie может хранить имя пользователя, имя учетной записи или уникальный идентификатор пользователя (например, GUID). The cookie can store the user’s name, account name, or unique user ID (such as a GUID). Затем можно использовать файл cookie для доступа к личным настройкам пользователя, таким как цвет фона на веб-сайте. You can then use the cookie to access the user’s personalized settings, such as their preferred website background color.

Помните об Общем регламенте по защите данных в ЕС (GDPR) при создании файлов cookie и решении вопросов с конфиденциальностью. Be mindful of the European Union General Data Protection Regulations (GDPR) when issuing cookies and dealing with privacy concerns. Дополнительные сведения см. в разделе Общий регламент по защите данных (GDPR), принятый в ЕС, в ASP.NET Core. For more information, see General Data Protection Regulation (GDPR) support in ASP.NET Core.

Состояние сеанса Session state

Состояние сеанса — это сценарий ASP.NET Core для хранения пользовательских данных, когда пользователь находится в веб-приложении. Session state is an ASP.NET Core scenario for storage of user data while the user browses a web app. Состояние сеанса использует хранилище, обслуживаемое приложением, для сохранения данных между запросами от клиента. Session state uses a store maintained by the app to persist data across requests from a client. Данные сеанса поддерживаются кэшем и считаются временными, — сайт должен работать и без данных сеанса. The session data is backed by a cache and considered ephemeral data—the site should continue to function without the session data. Критически важные данные приложения должны храниться в пользовательской базе данных и кэшироваться в сеансе только в качестве оптимизации производительности. Critical application data should be stored in the user database and cached in session only as a performance optimization.

Сеанс не поддерживается в приложениях SignalR, так как хаб SignalR может выполняться независимо от контекста HTTP. Session isn’t supported in SignalR apps because a SignalR Hub may execute independent of an HTTP context. Например, это может произойти, если хаб поддерживает длительный запрос на опрос открытым, когда время существования контекста HTTP для запроса уже истекло. For example, this can occur when a long polling request is held open by a hub beyond the lifetime of the request’s HTTP context.

ASP.NET Core сохраняет состояние сеанса, предоставляя клиенту файл cookie, содержащий идентификатор сеанса, который отправляется в приложение вместе с каждым запросом. ASP.NET Core maintains session state by providing a cookie to the client that contains a session ID, which is sent to the app with each request. Приложение использует этот идентификатор для получения данных сеанса. The app uses the session ID to fetch the session data.

Состояние сеанса реагирует на события следующим образом: Session state exhibits the following behaviors:

  • Так как файл cookie сеанса относится к конкретному браузеру, обеспечить общий доступ к сеансам из разных браузеров невозможно. Because the session cookie is specific to the browser, sessions aren’t shared across browsers.
  • Файлы cookie сеанса удаляются при завершении сеанса браузера. Session cookies are deleted when the browser session ends.
  • Если получен файл cookie для просроченного сеанса, создается сеанс, использующий этот же файл. If a cookie is received for an expired session, a new session is created that uses the same session cookie.
  • Пустые сеансы не сохраняются — в сеансе должно быть хотя бы одно значение, чтобы его можно быть сохранить между запросами. Empty sessions aren’t retained—the session must have at least one value set into it to persist the session across requests. Если сеанс не сохраняется, для каждого нового запроса создается новый идентификатор сеанса. When a session isn’t retained, a new session ID is generated for each new request.
  • Приложение хранит сеанс некоторое время после последнего запроса. The app retains a session for a limited time after the last request. Приложение устанавливает время ожидания сеанса или использует значение по умолчанию, равное 20 минутам. The app either sets the session timeout or uses the default value of 20 minutes. Состояние сеанса оптимально подходит для сохранения пользовательских данных, относящихся к определенному сеансу, которые не требуется хранить бессрочно для нескольких сеансов. Session state is ideal for storing user data that’s specific to a particular session but where the data doesn’t require permanent storage across sessions.
  • Данные сеанса удаляются при вызове реализации ISession.Clear или когда истекает срок действия сеанса. Session data is deleted either when the ISession.Clear implementation is called or when the session expires.
  • Не существует механизма по умолчанию, который бы информировал код приложения о том, что браузер клиента закрыт или файл cookie сеанса удален или просрочен на клиенте. There’s no default mechanism to inform app code that a client browser has been closed or when the session cookie is deleted or expired on the client.
  • Шаблоны ASP.NET Core MVC и Razor Pages поддерживают общий регламент по защите данных (GDPR). The ASP.NET Core MVC and Razor pages templates include support for General Data Protection Regulation (GDPR). Файлы cookie для состояния сеанса не помечаются как основные по умолчанию, поэтому состояние сеанса недоступно, если отслеживание разрешено посетителем сайта. Session state cookies aren’t marked essential by default, so session state isn’t functional unless tracking is permitted by the site visitor. Дополнительные сведения можно найти по адресу: Поддержка Общий регламент по защите данных (GDPR) в ASP.NET Core. For more information, see Поддержка Общий регламент по защите данных (GDPR) в ASP.NET Core.

Не храните конфиденциальные данные в состоянии сеанса. Don’t store sensitive data in session state. Пользователь может не закрывать браузер и очистить файл cookie сеанса. The user might not close the browser and clear the session cookie. Некоторые браузеры сохраняют файлы cookie сеанса в нескольких окнах браузера. Some browsers maintain valid session cookies across browser windows. Сеанс может быть не ограничен одним пользователем — следующий пользователь продолжит использовать приложение с тем же файлом cookie сеанса. A session might not be restricted to a single user—the next user might continue to browse the app with the same session cookie.

Поставщик кэша в памяти хранит данные сеанса в памяти сервера, содержащего приложение. The in-memory cache provider stores session data in the memory of the server where the app resides. В сценарии с фермой серверов: In a server farm scenario:

  • Используйте прикрепленные сеансы для привязки сеанса к конкретному экземпляру приложения на отдельном сервере. Use sticky sessions to tie each session to a specific app instance on an individual server. Служба приложений Azure использует маршрутизацию запросов приложений (ARR), чтобы прикрепленные сеансы создавались по умолчанию. Azure App Service uses Application Request Routing (ARR) to enforce sticky sessions by default. Однако прикрепленные сеансы могут негативно повлиять на масштабируемость и усложнить обновление веб-приложений. However, sticky sessions can affect scalability and complicate web app updates. Лучше использовать распределенные кэши SQL Server или Redis, для которых прикрепленные сеансы не требуются. A better approach is to use a Redis or SQL Server distributed cache, which doesn’t require sticky sessions. Дополнительные сведения можно найти по адресу: Распределенное кэширование в ASP.NET Core. For more information, see Распределенное кэширование в ASP.NET Core.
  • Файл cookie сеанса шифруется через IDataProtector. The session cookie is encrypted via IDataProtector. Необходимо правильно настроить защиту данных, чтобы читать файлы cookie сеанса на каждом компьютере. Data Protection must be properly configured to read session cookies on each machine. Дополнительные сведения см. статьях Защита данных в ASP.NET Core и Key storage providers in ASP.NET Core (Поставщики хранилища ключей в ASP.NET Core). For more information, see Защита данных в ASP.NET Core and Key storage providers.

Настройка состояния сеанса Configure session state

Пакет Microsoft.AspNetCore.Session, который входит в метапакет Microsoft.AspNetCore.App, предоставляет ПО промежуточного слоя для управления состоянием сеанса. The Microsoft.AspNetCore.Session package, which is included in the Microsoft.AspNetCore.App metapackage, provides middleware for managing session state. Чтобы включить сеанс ПО промежуточного слоя для сеансов, Startup должен содержать: To enable the session middleware, Startup must contain:

  • Любой из кэшей памяти IDistributedCache, Any of the IDistributedCache memory caches. при этом реализация IDistributedCache используется в качестве резервного хранилища для сеанса. The IDistributedCache implementation is used as a backing store for session. Дополнительные сведения можно найти по адресу: Распределенное кэширование в ASP.NET Core. For more information, see Распределенное кэширование в ASP.NET Core.
  • Вызов AddSession в ConfigureServices . A call to AddSession in ConfigureServices .
  • Вызов UseSession в Configure . A call to UseSession in Configure .

Следующий код показывает, как настроить поставщик сеансов в памяти с реализацией в памяти IDistributedCache по умолчанию: The following code shows how to set up the in-memory session provider with a default in-memory implementation of IDistributedCache :

Порядок ПО промежуточного слоя важен. The order of middleware is important. В предыдущем примере исключение InvalidOperationException возникает при вызове UseSession после UseMvc . In the preceding example, an InvalidOperationException exception occurs when UseSession is invoked after UseMvc . Дополнительные сведения см. в разделе Порядок расположения ПО промежуточного слоя. For more information, see Middleware Ordering.

После настройки состояния сеанса доступно свойство HttpContext.Session. HttpContext.Session is available after session state is configured.

Невозможно получить доступ к HttpContext.Session до вызова UseSession . HttpContext.Session can’t be accessed before UseSession has been called.

Невозможно создать новый сеанс с новым файлом cookie сеанса после того, как приложение начинает запись в поток ответа. A new session with a new session cookie can’t be created after the app has begun writing to the response stream. Исключение записывается в журнал веб-сервера и не отображается в браузере. The exception is recorded in the web server log and not displayed in the browser.

Асинхронная загрузка состояния сеанса Load session state asynchronously

Поставщик сеансов по умолчанию в ASP.NET Core загружает запись сеанса из резервного хранилища IDistributedCache в асинхронном режиме только при явном вызове метода ISession.LoadAsync перед методами TryGetValue, Set или Remove. The default session provider in ASP.NET Core loads session records from the underlying IDistributedCache backing store asynchronously only if the ISession.LoadAsync method is explicitly called before the TryGetValue, Set, or Remove methods. Если LoadAsync не вызывается первым, базовая запись сеанса загружается синхронно, что может негативно повлиять на производительность. If LoadAsync isn’t called first, the underlying session record is loaded synchronously, which can incur a performance penalty at scale.


Чтобы принудительно использовать этот режим в приложениях, используйте для реализаций DistributedSessionStore и DistributedSession оболочку из версий, которые выдают исключение, когда метод LoadAsync не вызывается перед TryGetValue , Set или Remove . To have apps enforce this pattern, wrap the DistributedSessionStore and DistributedSession implementations with versions that throw an exception if the LoadAsync method isn’t called before TryGetValue , Set , or Remove . Зарегистрируйте версии оболочки в контейнере служб. Register the wrapped versions in the services container.

Параметры сеанса Session options

Чтобы переопределить значения по умолчанию для сеанса, используйте SessionOptions. To override session defaults, use SessionOptions.

Параметр Option ОПИСАНИЕ Description
Файл cookie Cookie Определяет параметры, используемые для создания файлов cookie. Determines the settings used to create the cookie. Параметр Name по умолчанию имеет значение SessionDefaults.CookieName ( .AspNetCore.Session ). Name defaults to SessionDefaults.CookieName ( .AspNetCore.Session ). Параметр Path по умолчанию имеет значение SessionDefaults.CookiePath ( / ). Path defaults to SessionDefaults.CookiePath ( / ). Параметр SameSite по умолчанию имеет значение SameSiteMode.Lax ( 1 ). SameSite defaults to SameSiteMode.Lax ( 1 ). Параметр HttpOnly по умолчанию имеет значение true . HttpOnly defaults to true . Параметр IsEssential по умолчанию имеет значение false . IsEssential defaults to false .
IdleTimeout IdleTimeout IdleTimeout указывает, как долго сеанс может быть неактивным, прежде чем его содержимое отбрасывается. The IdleTimeout indicates how long the session can be idle before its contents are abandoned. Каждый доступ к сеансу сбрасывает время ожидания. Each session access resets the timeout. Этот параметр применяется только к содержимому сеанса, а не к файлу cookie. This setting only applies to the content of the session, not the cookie. Значение по умолчанию — 20 минут. The default is 20 minutes.
IOTimeout IOTimeout Максимальный период загрузки сеанса из хранилища или его сохранения обратно в хранилище. The maximum amount of time allowed to load a session from the store or to commit it back to the store. Этот параметр может применяться только к асинхронным операциям. This setting may only apply to asynchronous operations. Время ожидания можно отключить с помощью InfiniteTimeSpan. This timeout can be disabled using InfiniteTimeSpan. Значение по умолчанию — 1 минута. The default is 1 minute.

Сеанс использует файл cookie для отслеживания и идентификации запросов в одном браузере. Session uses a cookie to track and identify requests from a single browser. По умолчанию этот файл cookie называется .AspNetCore.Session и использует путь / . By default, this cookie is named .AspNetCore.Session , and it uses a path of / . Так как по умолчанию файл cookie не указывает домен, он остается недоступным для клиентского сценария на странице (так как HttpOnly по умолчанию имеет значение true ). Because the cookie default doesn’t specify a domain, it isn’t made available to the client-side script on the page (because HttpOnly defaults to true ).

Чтобы переопределить файл cookie по умолчанию для сеанса, используйте SessionOptions : To override cookie session defaults, use SessionOptions :

Приложение использует свойство IdleTimeout, чтобы определить, как долго сеанс может оставаться неактивным до сброса его содержимого в кэше сервера. The app uses the IdleTimeout property to determine how long a session can be idle before its contents in the server’s cache are abandoned. Это свойство не зависит от срока действия файла cookie. This property is independent of the cookie expiration. Каждый запрос, проходящий через ПО промежуточного слоя сеанса, сбрасывает это время ожидания. Each request that passes through the Session Middleware resets the timeout.

Состояние сеанса является неблокирующим. Session state is non-locking. Когда два запроса пытаются изменить содержимое сеанса, последний из них переопределяет первый. If two requests simultaneously attempt to modify the contents of a session, the last request overrides the first. Session реализован в виде согласованного сеанса, что означает, что все содержимое хранится вместе. Session is implemented as a coherent session, which means that all the contents are stored together. Когда два запроса пытаются изменить разные значения сеанса, последний запрос может переопределить изменения, внесенные первым. When two requests seek to modify different session values, the last request may override session changes made by the first.

Установка и получение значений сеанса Set and get Session values

Получить доступ к состоянию сеанса можно через класс Razor Pages PageModel или класс MVC Controller со свойством HttpContext.Session. Session state is accessed from a Razor Pages PageModel class or MVC Controller class with HttpContext.Session. Оно является реализацией ISession. This property is an ISession implementation.

Реализация ISession предоставляет несколько методов расширения для задания и извлечения значений типа integer и string. The ISession implementation provides several extension methods to set and retrieve integer and string values. Методы расширения находятся в пространстве имен Microsoft.AspNetCore.Http (добавьте оператор using Microsoft.AspNetCore.Http; , чтобы получить доступ к методам расширения), когда проект ссылается на пакет Microsoft.AspNetCore.Http.Extensions. The extension methods are in the Microsoft.AspNetCore.Http namespace (add a using Microsoft.AspNetCore.Http; statement to gain access to the extension methods) when the Microsoft.AspNetCore.Http.Extensions package is referenced by the project. Оба пакета входят в метапакет Microsoft.AspNetCore.App. Both packages are included in the Microsoft.AspNetCore.App metapackage.

Методы расширения ISession : ISession extension methods:

В следующем примере извлекается значение сеанса для ключа IndexModel.SessionKeyName ( _Name в примере приложения) на странице Razor Pages: The following example retrieves the session value for the IndexModel.SessionKeyName key ( _Name in the sample app) in a Razor Pages page:

В следующем примере показано, как задать, а затем получить значения integer и string: The following example shows how to set and get an integer and a string:

Все данные сеанса должны быть сериализованы, чтобы использовать сценарий-распределенного кэша даже при использовании кэша в памяти. All session data must be serialized to enable a distributed cache scenario, even when using the in-memory cache. Предоставляются минимальные сериализаторы строки и числа (см. методы и методы расширения ISession). Minimal string and number serializers are provided (see the methods and extension methods of ISession). Сложные типы должны быть сериализованы пользователем с помощью другого механизма, например JSON. Complex types must be serialized by the user using another mechanism, such as JSON.

Добавьте приведенные ниже методы расширения, чтобы задавать и получать сериализуемые объекты: Add the following extension methods to set and get serializable objects:

Следующий пример показывает, как задать и получить сериализуемый объект с помощью методов расширения: The following example shows how to set and get a serializable object with the extension methods:

TempData TempData

ASP.NET Core предоставляет TempData Razor Pages или TempData контроллера. ASP.NET Core exposes the Razor Pages TempData or Controller TempData. Это свойство хранит данные до тех пор, пока они не будут прочитаны в другом запросе. This property stores data until it’s read in another request. Для проверки данных без удаления можно использовать методы Keep(String) и Peek(String) в конце запроса. Keep(String) and Peek(string) methods can be used to examine the data without deletion at the end of the request. Keep() помечает все элементы в словаре для хранения. Keep() marks all items in the dictionary for retention. TempData особенно удобно использовать для перенаправления, когда данные требуются для нескольких запросов. TempData is particularly useful for redirection when data is required for more than a single request. TempData реализуется поставщиками TempData , например, с помощью файлов cookie или состояния сеанса. TempData is implemented by TempData providers using either cookies or session state.

Примеры TempData TempData samples

Рассмотрим следующую страницу, которая создает клиент: Consider the following page that creates a customer:

На следующей странице отображается TempData[«Message»] : The following page displays TempData[«Message»] :

В предыдущей разметке в конце запроса TempData[«Message»] не удаляется, так как используется Peek . In the preceding markup, at the end of the request, TempData[«Message»] is not deleted because Peek is used. На обновляемой странице отображается TempData[«Message»] . Refreshing the page displays TempData[«Message»] .

Следующая разметка похожа на приведенный выше код, но в ней используется Keep для сохранения данных в конце запроса: The following markup is similar to the preceding code, but uses Keep to preserve the data at the end of the request:

При переходе между страницами IndexPeek и IndexKeep TempData[«Message»] не удаляется. Navigating between the IndexPeek and IndexKeep pages won’t delete TempData[«Message»] .

Следующий код отображает TempData[«Message»] , но в конце запроса TempData[«Message»] удаляется: The following code displays TempData[«Message»] , but at the end of the request, TempData[«Message»] is deleted:

Поставщики TempData TempData providers

Поставщик TempData, основанный на файлах cookie, используется по умолчанию для хранения TempData в файлах cookie. The cookie-based TempData provider is used by default to store TempData in cookies.

Данные в файле cookie шифруются с помощью IDataProtector, кодируются с помощью Base64UrlTextEncoder, а затем фрагментируются. The cookie data is encrypted using IDataProtector, encoded with Base64UrlTextEncoder, then chunked. Так как файл cookie фрагментируется, ограничение на размер одного такого файла, заданное в ASP.NET Core 1.x, не применяется. Because the cookie is chunked, the single cookie size limit found in ASP.NET Core 1.x doesn’t apply. Данные файла cookie не сжимаются, так как сжатие зашифрованных данных может привести к проблемам с безопасностью, например атакам CRIME и BREACH. The cookie data isn’t compressed because compressing encrypted data can lead to security problems such as the CRIME and BREACH attacks. Дополнительные сведения на поставщике TempData, основанном на файлах cookie, см. в разделе CookieTempDataProvider. For more information on the cookie-based TempData provider, see CookieTempDataProvider.

Выбор поставщика TempData Choose a TempData provider

Выбор поставщика TempData включает в себя несколько аспектов: Choosing a TempData provider involves several considerations, such as:

  1. Приложение уже использует состояние сеанса? Does the app already use session state? Если это так, использование поставщика TempData для состояния сеанса не требует от приложения никаких дополнительных издержек (кроме объема данных). If so, using the session state TempData provider has no additional cost to the app (aside from the size of the data).
  2. Приложение использует TempData лишь ограниченно, для сравнительно небольших объемов данных (до 500 байт)? Does the app use TempData only sparingly for relatively small amounts of data (up to 500 bytes)? Если это так, поставщик TempData на основе файлов cookie незначительно увеличивает издержки для каждого запроса, переносящего TempData. If so, the cookie TempData provider adds a small cost to each request that carries TempData. В противном случае поставщик TempData для состояния сеанса удобно использовать, чтобы устранить круговой обход большого объема данных в каждом запросе до полного использования TempData. If not, the session state TempData provider can be beneficial to avoid round-tripping a large amount of data in each request until the TempData is consumed.
  3. Приложение выполняется на ферме серверов на нескольких серверах? Does the app run in a server farm on multiple servers? Если это так, не требуется дополнительная настройка для использования поставщика TempData для файлов cookie, за исключением защиты данных (см. статьи Защита данных в ASP.NET Core и Key storage providers in ASP.NET Core (Поставщики хранилища ключей в ASP.NET Core)). If so, there’s no additional configuration required to use the cookie TempData provider outside of Data Protection (see Защита данных в ASP.NET Core and Key storage providers).

Большинство веб-клиентов (например, веб-браузеры) налагают ограничение на максимальный размер каждого файла cookie и (или) общее количество таких файлов. Most web clients (such as web browsers) enforce limits on the maximum size of each cookie, the total number of cookies, or both. При использовании поставщика TempData на основе файлов cookie убедитесь, что приложение не нарушает эти ограничения. When using the cookie TempData provider, verify the app won’t exceed these limits. Учитывайте общий объем данных. Consider the total size of the data. Учитывайте увеличение размеров файла cookie в результате шифрования и фрагментирования. Account for increases in cookie size due to encryption and chunking.

Настройка поставщика TempData Configure the TempData provider

Поставщик TempData на основе файлов cookie включен по умолчанию. The cookie-based TempData provider is enabled by default.

Чтобы включить поставщик TempData на основе сеанса, используйте метод расширения AddSessionStateTempDataProvider: To enable the session-based TempData provider, use the AddSessionStateTempDataProvider extension method:


Порядок ПО промежуточного слоя важен. The order of middleware is important. В предыдущем примере исключение InvalidOperationException возникает при вызове UseSession после UseMvc . In the preceding example, an InvalidOperationException exception occurs when UseSession is invoked after UseMvc . Дополнительные сведения см. в разделе Порядок расположения ПО промежуточного слоя. For more information, see Middleware Ordering.

Если вы ориентируетесь на .NET Framework и используете поставщик TempData на основе сеансов, добавьте в проект пакет Microsoft.AspNetCore.Session. If targeting .NET Framework and using the session-based TempData provider, add the Microsoft.AspNetCore.Session package to the project.

Строки запроса Query strings

Вы можете передать ограниченный объем данных из одного запроса в другой, добавив их в строку запроса нового запроса. A limited amount of data can be passed from one request to another by adding it to the new request’s query string. Это удобно для захвата состояния в сохраняемом виде, что позволяет обмениваться ссылками с внедренным состоянием по электронной почте или через социальные сети. This is useful for capturing state in a persistent manner that allows links with embedded state to be shared through email or social networks. Поскольку строки запроса URL-адреса являются открытыми, никогда не используйте их для конфиденциальных данных. Because URL query strings are public, never use query strings for sensitive data.

Вдобавок к случайному раскрытию информации включение данных в строки запроса может открыть возможности для атак с подделкой межсайтовых запросов (CSRF), которые могут обманом вынудить пользователей посещать вредоносные веб-сайты во время проверки подлинности. In addition to unintended sharing, including data in query strings can create opportunities for Cross-Site Request Forgery (CSRF) attacks, which can trick users into visiting malicious sites while authenticated. Это позволит злоумышленникам похитить данные пользователей из приложения или предпринимать вредоносные действия от их имени. Attackers can then steal user data from the app or take malicious actions on behalf of the user. Любое сохраненное состояние приложения или сеанса необходимо защитить от атак CSRF. Any preserved app or session state must protect against CSRF attacks. Дополнительные сведения см. в статье Предотвращение атак с подделкой межсайтовых запросов (XSRF/CSRF). For more information, see Prevent Cross-Site Request Forgery (XSRF/CSRF) attacks.

Скрытые поля Hidden fields

Данные можно сохранить в скрытых полях формы и опубликовать обратно при следующем запросе. Data can be saved in hidden form fields and posted back on the next request. Это типичное поведение для многостраничных форм. This is common in multi-page forms. Так как клиент может незаконно изменить данные, приложение всегда должно перепроверять данные в скрытых полях. Because the client can potentially tamper with the data, the app must always revalidate the data stored in hidden fields.

HttpContext.Items HttpContext.Items

Коллекция HttpContext.Items используется для хранения данных при обработке одного запроса. The HttpContext.Items collection is used to store data while processing a single request. Ее содержимое удаляется после обработки каждого запроса. The collection’s contents are discarded after a request is processed. Коллекцию Items часто используют для обеспечения взаимодействия компонентов или ПО промежуточного слоя, когда они выполняются в разные моменты времени во время обработки запроса и не могут передавать параметры напрямую. The Items collection is often used to allow components or middleware to communicate when they operate at different points in time during a request and have no direct way to pass parameters.

В следующем примере ПО промежуточного слоя добавляет isVerified в коллекцию Items . In the following example, middleware adds isVerified to the Items collection.

Далее в конвейере другое ПО промежуточного слоя может получить доступ к значению isVerified : Later in the pipeline, another middleware can access the value of isVerified :

Для ПО промежуточного слоя, которое используется всего одним приложением, допустимы ключи string . For middleware that’s only used by a single app, string keys are acceptable. ПО промежуточного слоя, используемое несколькими экземплярами приложения, должно использовать уникальные ключи объекта во избежание конфликтов. Middleware shared between app instances should use unique object keys to avoid key collisions. В следующем примере показано, как использовать уникальный ключ объекта, определенный в классе ПО промежуточного слоя: The following example shows how to use a unique object key defined in a middleware class:

Другой код может обратиться к значению, хранящемуся в HttpContext.Items , с помощью ключа, предоставляемого классом ПО промежуточного слоя: Other code can access the value stored in HttpContext.Items using the key exposed by the middleware class:

Данный подход также позволяет не использовать строки ключей в коде. This approach also has the advantage of eliminating the use of key strings in the code.

Кэш Cache

Кэширование — это эффективный способ хранения и извлечения данных. Caching is an efficient way to store and retrieve data. Приложение может управлять временем существования элементов кэша. The app can control the lifetime of cached items.

Кэшированные данные не связаны с конкретным запросом, пользователем или сеансом. Cached data isn’t associated with a specific request, user, or session. Будьте внимательны и не кэшируйте данные пользователя, которые можно извлечь по запросу другого пользователя. Be careful not to cache user-specific data that may be retrieved by other users’ requests.

Дополнительные сведения можно найти по адресу: Кэширование ответов в ASP.NET Core. For more information, see Кэширование ответов в ASP.NET Core.

Внедрение зависимостей Dependency Injection

Используйте внедрение зависимостей, чтобы сделать данные доступными для всех пользователей: Use Dependency Injection to make data available to all users:

Определите службу, содержащую данные. Define a service containing the data. Например, определяется класс с именем MyAppData : For example, a class named MyAppData is defined:

Добавьте класс службы в Startup.ConfigureServices : Add the service class to Startup.ConfigureServices :

Используйте класс службы данных: Consume the data service class:

Распространенные ошибки Common errors

«Unable to resolve service for type «Microsoft.Extensions.Caching.Distributed.IDistributedCache» while attempting to activate «Microsoft.AspNetCore.Session.DistributedSessionStore»» (Не удается разрешить службу для типа «Microsoft.Extensions.Caching.Distributed.IDistributedCache» при попытке активировать «Microsoft.AspNetCore.Session.DistributedSessionStore»). «Unable to resolve service for type ‘Microsoft.Extensions.Caching.Distributed.IDistributedCache’ while attempting to activate ‘Microsoft.AspNetCore.Session.DistributedSessionStore’.»

Обычно она вызвана невозможностью настройки по меньшей мере одной реализации IDistributedCache . This is usually caused by failing to configure at least one IDistributedCache implementation. Дополнительные сведения см. в разделах Распределенное кэширование в ASP.NET Core и Кэширование в памяти в ASP.NET Core. For more information, see Распределенное кэширование в ASP.NET Core and Кэширование в памяти в ASP.NET Core.

Если ПО промежуточного слоя для сеанса не удается сохранить сеанс (например, резервное хранилище недоступно), оно регистрирует исключение и запрос выполняется обычным образом. In the event that the session middleware fails to persist a session (for example, if the backing store isn’t available), the middleware logs the exception and the request continues normally. Это приводит к непредсказуемому поведению. This leads to unpredictable behavior.

Например, пользователь сохраняет корзину для покупок в сеансе. For example, a user stores a shopping cart in session. Он добавляет товар в корзину, но фиксация завершается сбоем. The user adds an item to the cart but the commit fails. Приложению неизвестно о сбое, поэтому оно сообщает пользователю, что товар добавлен в корзину, хотя это не так. The app doesn’t know about the failure so it reports to the user that the item was added to their cart, which isn’t true.

Asp объект session

Описание объекта Session

Вы можете использовать данный объект для хранения информации о (и для) пользовательских сессий. Переменные, хранящиеся в объекте Session не уничтожаются когда пользователь осуществляет переходы между страницами в приложении, а хранятся на протяжении существования данной сессии.

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

Основное использование данного объекта это хранение в нем пользовательских «персоналий». К примеру, если пользователь указывает на то, что ему не надо показывать графические изображения вы можете запомнить эту информацию в объекте Session. Для более подробной информации по данному объекту вы можете обратиться к разделу Управление Сессиями в разделе APS-приложений.

Замечание: Данный объект может быть смонтирован только для браузеров, поддерживающих cookies.

Коллекция Session.Contents

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

ключ
Имя свойства для получения его значения.


Вы можно использовать структуру управления циклом через ключи данной коллекции. Это демонстрируется в следующем примере:

Dim sessitem
For each sessitem in Session.Contents
response.write(sessitem & » : » & Session.Contents(sessitem) & «
«)
Next
%>

Коллекция Session.StaticObjects

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

ключ
Название свойства, служащее для получения через него его значения.

Вы можете использовать структуру цикла через ключ для доступа к свойствам данной коллекции. Это демонстрирует следующий пример:

Dim objprop
For each objprop in Session.StaticObjects
Response.write(objproperty & «:» & Session.StaticObjects(objprop) & «
«)
Next
%>

Метод Session.Abandon

Метод Abandon разрушает все объекты запомненные в объекте Session и высвобождаются занятые этим ресурсы. Если вы не вызываете данного метода, то сервер сам «разрушит» эти объекты когда истечет время «жизни» сессии, т.е. тайм аут.

Когда метод Abandon вызывается, текущий объект Session ставится в очередь на удаление, но реально будет уничтожен только после того, как все команды данног скрипта будут обработаны.Это подразумевает, что можете еще воспользоватся обращением к переменным, запомненным в объекте Session в любом месте данной, но никакой другой страницы.

Следующий пример демонстрирует вывод клиенту переменной Mary. Этот пример работает работает потому, что объект Session будет уничтожен только после обработки всего текущего скрипта.

Session.Abandon
Session(«MyName») = «Mary»
Response.Write(Session(«MyName»))
%>

Если вы обращаетесь к переменной MyName на другой странице, то она будет пуста.

Сервер создает новый объект Session когда вы открываете другую страницу вэб сервере (другой скрипт) после прерывания (Abandon) сессии. Вы можете запоминать переменные и объекты в этом новом объекте Session.

Свойство Session.CodePage

кодовая_страница
беззнаковое целое значение, представляющее корректный номер кодовой страницы для системы, в которой запущена ASP-машина.

Кодовая страница это набор символов. Различные языки могут использовать различные кодовые страницы. К примеру ANSI — кодовая страница 1252 используется для «Американского» английского языка и большинства европейских языков. Страница — 1251 — кириллица для русского языва в среде Windows.

Свойство Session.LCID

Данное свойство определяет идентификатор расположения, который будет использован для вывода клиенту динамического содержимого.

LCID
корректный идентификатор месторасположениея.

Данное свойство указывает идентификатор расположения, который является стандартной мендународной аббривиатурой, которая уникальным образом идентифицирует одно предопределенное системой расположение.

Свойство Session.SessionID

Свойство SessionID возвращает идентификатор сессии для данного пользователя. Каждая сессия имеет уникальный идентификатор, который создается сервером, когда сессия создается. Данный идентификатор возвращается как данные типа Long.

Вы не должны использовать свойство SessionID для того, чтобы создать значение основного ключа в приложениях баз данных потому, что после рестарта Web-сервера, значения идентификатора сессии могут повторяться. Вместо этого вы можете использовать автоинкриментирующийся счетчик записей, к примеру IDENTITY, поддерживаемый Microsoft® SQL server или в Microsoft® Access — COUNTER.

Свойство Session.TimeOut

Свойство TimeOut указывает на период времени в минутах, связанный с объектом Session для приложения. Если пользователь не обновить (refresh) или не запросить страницу у сервера в течение указанного периода времени — сессия будет завершена.

минут
указанное время в минутах, по истечении которого сервер закончит сессию автоматически.

Событие Session.Session_OnEnd

Событие Session_OnEnd будет вызвано тогда, когда сессия будет прервана принудительно или по таймауту.

язык_скрипта
Указывает на язык программирования, который будет использован для написания данной процедуры. Им может быть любой из поддерживаемых языков программирования — таких как VBScript или JScript. Если более одного события используют один и тотже язык программирования, то они могут быть объеденены между парой тэгов

язык_скрипта
Указывает на язык программирования, который будет использован для написания данной процедуры. Им может быть любой из поддерживаемых языков программирования — таких как VBScript или JScript. Если более одного события используют один и тотже язык программирования, то они могут быть объеденены между парой тэгов

Приведенный пример работает только с браузером, который поддерживает cookies. Браузер, не поддерживающий cookie не возвратит SessionID — идентификатор, сервер будет создавать новые сессии каждый раз, когда пользователь будет запрашивать страницы. И для каждого такого запроса сервер будет обрабатывать скрипт события Session_OnStart и перенаправлять пользователя на стартовую страницу. Если вы воспользуетесь примером ниже, то вам необходимо на начальной странице вашего приложения оповестить посетителей о том, что для просмотра вашего сервера необходим cookie-совместимый браузер.

Вы должны учитывать, что любой текст скрипта события Session_OnStart, следующий за методом Redirect выполняться не будет! Для того, что бы учитывать эту особенность вы должны поставить вызов метода Redirect последней командой вашего скрипта события. Это продемонстрировано в примере ниже:

В предыдущем примере метод Redirect вызывается последним в процедуре и следовательно все предшествующие ему команды будут корректно выполнены.

Программирование на ASP

Объект Session

Объект Session представляет собой готовое средство управления состоянием с помощью элементов cookie. Объект Session управляет временем сеанса и информацией о конечном пользователе, запрещая программисту считывать и записывать значения элементов cookie и времени проверки для сеанса. Если компьютер клиента не разрешает использование элементов cookie, то объект Session не сможет записать сеансовый элемент cookie и будет функционировать неправильно. Элемент cookie, записываемый объектом Session , не имеет срока действия, поэтому он удаляется при закрытии браузера. Объект Session содержит все данные сеанса в наборе Session.Contents . Объектом Session и набором Contents управляют так же, как и другими наборами объектов ASP. WriteCollection (особая подпрограмма в листинге 12.2) используется для отображения содержимого набора Session.Contents точно так же, как при записи элементов cookie, переменных формы и наборов QueryString в браузер. В листинге 12.5 приведен пример кода, в котором объект Session используется аналогично набору Request.Cookies .


Листинг 12.5 представляет собой код ASP, выполняющий считывание значения объекта Session , обновление значения и запись новых значений в объект Session . Подпрограмма WriteCollection представляет собой файл включения, указанный в строке . Два других свойства, уникальных для объекта Session – SessionID и Timeout – записываются в браузер. Подпрограмма UpdateSession вызывается с помощью набора Session.Contents с использованием в качестве аргументов переменных sTime и sNumber . Переменные sTime и sNumber являются пустыми переменными, которым присваиваются значения сеанса в подпрограмме. После установки значения Session.Timeout , равного 1 минуте, в браузер записывается информация об обновлениях, внесенных в сеанс.

В VBScript по умолчанию все параметры в функции или подпрограмме передаются по обращению. Это значит, что значения аргументов примут в результате работы функции или подпрограммы значения переданных аргументов. В подпрограмме UpdateSession переменным sTime и sNumber не присвоено значений при их передаче в UpdateSession в качестве аргументов. В подпрограмме значение переменной sTime устанавливается равным текущему времени с помощью функции now() , а переменной sNumber – предыдущему значению, к которому прибавляется единица. После завершения подпрограммы обе переменные sTime и sNumber содержат новые значения, присвоенные им функцией UpdateSession . Если перед любым параметром в объявлении прототипа подпрограммы расположить ключевое слово byval , то передаваемый аргумент не будет изменяться после завершения подпрограммы.

При первом выполнении кода ASP в файле ReadWriteSession.asp (см. листинг 12.5) в браузере отображаются значения объекта Session . Параметр Session.Timeout по умолчанию равен 20, и в сеансе не устанавливаются никакие значения до тех пор, пока ASP не завершит свое выполнение. На рисунке 12.10 показаны результаты первого выполнения сеансового кода ASP.

Обновление файла ReadWriteSession.asp вызывает повторное выполнение кода ASP и обновление сеансового объекта посредством присвоения новых значений, а также вывод значений в браузер (см. рис. 12.11). Объект Session может содержать значения, ассоциированные с именем, подобно элементам cookie, что позволяет использовать его в качестве механизма управления состоянием приложения между запросами страницы. Элементы cookie (см. рис. 12.9) добавлены в объект Session для демонстрации аналогии хранения и получения данных с помощью сеанса и элемента cookie. Файл ReadWriteSession.asp также устанавливает новое значение Session.Timeout , равное 1 минуте.

Ограничения объекта Session

Объект Session имеет некоторые ограничения, с которыми необходимо ознакомиться, прежде чем реализовывать управление состоянием с помощью ASP на базе объекта Session . Сеанс не повторяется и не является общим между серверами, работающими в так называемой веб-ферме.

Session > Session object in ASP are there to store user specific information. In most cases sessions are used to maintain state as the user navigates through different pages. Some data we can pass by using query string, web forms and cookies but session variables has distinctive role than other ways while carrying data to different pages.

Say we want to carry the member login status to different pages and with this information the member can enter to members only pages. Here the session variables are stored at server side ( not at client side ) and it is connected to user browser. As long as the browser window is in contact with server, session details will be available and if there is no interaction from user end within a specific time the sessions variables will be destroyed. The user also can end or abandon the session. Let us learn some details about session object here.

Session ID

Response.Write Session.SessionID

When we should not use Session

Load on Server

Security

Amount of Data

Better not to load the server with more session data as it drains the server resources. This is important particularly for high traffic sites. Now temporary tables are available in databases which are fast and maintain overall small size for database.

We will learn more on session start, session variable and session time out.

Be the first to post comment on this article :

Как получить хранящееся значение в сессии ASP.NET MVC 4?

В одном из методов контроллера устанавливаю значение сессии:

В другом методе контроллера пытаюсь получить значение:

string test = Session[«User.Project»];

В переменную test попадает null. Пробовал HttpContext.Session тоже самое.
Конечно пользователь сначала проходит по первому методу контроллера, потом по второму методу.
Если достать значение сессии в первом методе контролера, сразу после записи то значение там есть. Работает нормально. Но вот во втором методе контроллера его как будто нет.

  • Вопрос задан более трёх лет назад
  • 4338 просмотров

Quber: по снимку, все нормально, так и должно быть. В контроллере доступ без Current, или вообще можно опустить HttpContext.

По вопросу, почему null — может напутали чего. Например, на снимке имя параметра сессии User_Project, а в тексте вопроса: User.Project. И тип данных разный.

Если нет, то поведение Session вы намерено не настраивали? Cookies у клиента нормально работают? Ну и глупый вопрос, вы уверены, что между переходом от метода, в котором создается сессия, к следующему методу проект не перекомпилируется? :-)

Еще один вопрос, если сессия возвращает тип object, то почему вы пишите string test = Session[«User.Project»]; Действительно такой код используете, или это просто ошибка в тексте вопроса?

Алексей Немиро: Спасибо за развёрнутый ответ.

По вопросу, почему null — может напутали чего.

Например, на снимке имя параметра сессии User_Project, а в тексте вопроса: User.Project. И тип данных разный.

Если нет, то поведение Session вы намерено не настраивали? Cookies у клиента нормально работают?

Ну и глупый вопрос, вы уверены, что между переходом от метода, в котором создается сессия, к следующему методу проект не перекомпилируется? :-)

Еще один вопрос, если сессия возвращает тип object, то почему вы пишите string test = Session[«User.Project»]; Действительно такой код используете, или это просто ошибка в тексте вопроса?

А применении точки в названии ключа сессии приводит к возвращению объекта? Или как вы определили, что сессия возвращает объект? По сути должно либо string, либо int. Но потом приводится к integer (int)


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

Я повторюсь, что при вызове ключа сессии в первом методе, сразу после объявления ключа, то значение он возвращает нормально. Проблемы начинаются, когда пользователь в рамках одной сессии вызывает второй метод, где данных в сессии уже нет. Я банально создал две страницы. При вызове первой, данные сохраняются в сессии. При переходе на вторую страницу, данные должны из сессии изыматься, то приходит null, как будто сессия очистилась. Возможно нужно что то сделать, чтобы данные не очищались при переходе со страницы на страницу, я не знаю.

Иллюстрированный самоучитель по Architecture .NET

Состояния в приложениях ASP.NET. Статические элементы данных. Объект Application (Приложение). Объект Session (Сеанс).

Сохранение состояния при запросах, посылаемых по протоколу передачи гипертекстовых файлов HTTP, – главная проблема в Web-программировании ASP.NET предоставляет для этого несколько удобных функций Необходимо сохранять два типа состояния.

  • Состояние приложения – глобальная информация, которая совместно используется всеми пользователями Web-приложения
  • Состояние сеанса используется для хранения данных конкретного пользователя, который многократно обращается к Web-приложению

Статические элементы данных

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

Объект Application (Приложение)

Глобальная информация приложения хранится во встроенном объекте Application (Приложение), который является экземпляром класса HttpApplicationState. Удобно получать доступ к этому объекту через свойство Application (Приложение) класса Page (Страница). Класс HttpApplicationState содержит словарь в формате «ключ – значение», используемый для хранения как объектов, так и скалярных величин.

Объект Session (Сеанс)

Информация о сеансе индивидуальных пользователей может храниться во встроенном объекте Session (Сеанс), который является экземпляром класса HttpSession-State. Доступ к этому объекту удобно получать с помощью свойства Session (Сеанс) класса Page (Страница). Класс HttpSessionState, аналогично классу HttpApplicationState, имеет словарь в формате «ключ – значение», который можно использовать для хранения как объектов, так и скалярных величин.

При реализации переменных сеанса возникают некоторые интересные вопросы.

  • Обычно для идентификации сеанса, от которого поступил запрос, используются небольшие фрагменты данных о предыстории обращений данного пользователя к данному Web-серверу, автоматически создаваемые сервером на машине пользователя (cookies). Что делать, если такие фрагменты данных (cookies) не поддерживаются браузером, или отключены пользователем?
  • Поддержка состояния сеанса для многих пользователей влечет накладные расходы. Истекает ли срок действия состояния сеанса после определенного периода времени?
  • Высокопроизводительными Web-узлами используется группа серверов. Каким образом приложение может получить необходимые ему данные, если второй запрос обслуживается не той машиной, которой обслуживался первый запрос?

Состояние сеанса и небольшие фрагменты данных о предыстории обращений конкретного пользователя к конкретному Web-серверу, автоматически создаваемые сервером на машине пользователя (cookies).

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

В такой модели идентификатор сеанса (Session ID), который обычно сохраняется в небольшом фрагменте данных о предыстории обращений конкретного пользователя к конкретному WWW-серверу, автоматически создаваемом сервером на машине пользователя (cookie), внедряется в унифицированный указатель информационного ресурса (URL). Конфигурация, где не используются небольшие фрагменты данных о предыстории обращений конкретного пользователя к конкретному Web-серверу, автоматически создаваемые сервером на машине пользователя (cookies), обсуждается в следующем разделе.

Предельное время ожидания для состояния сеанса

По умолчанию, предельное время ожидания для состояния сеанса истекает после 20 минут. Это означает, что если данный пользователь находится в состоянии ожидания (простоя) в течение указанного периода времени, сеанс прекращается, и запрос от клиента теперь будет обрабатываться как запрос от нового пользователя, причем будет создан новый сеанс. Как и другие параметры, предельное время ожидания указывается в файле конфигурации, – это мы обсудим в разделе «Конфигурация ASP.NET».

Хранение состояния сеанса

С помощью модели состояния сеанса, которая отделяет хранение информации от использования сохраненной информации приложениями, ASP.NET полностью решает не только проблему группы серверов, но и много других проблем. Модели состояния позволяют реализовать различные сценарии хранения так, чтобы не затрагивать при этом код приложения. Сервер состояния .NET не имеет «активных» объектов для запросов. Вместо этого в конце каждого сетевого запроса все объекты в коллекции сеанса преобразуются в последовательную форму, чтобы запомнить состояние сеанса. Когда тот же самый клиент возвращается к странице, объекты сеанса преобразуются из последовательной формы в параллельную.

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

Классические объекты ASP Store в объекте сеанса

Я новичок в классическом ASP, и мне нужно закодировать веб-приложение в классическом asp, потому что клиент хочет, чтобы он был в классическом asp.: (

В любом случае! вот мой вопрос:

Когда у меня есть объект класса с именем person:

До сих пор так хорошо.

При следующем запросе я пытаюсь прочитать сеанс var следующим образом:

Любые идеи о том, что происходит, будут очень полезны.

Я не могу объяснить, почему ваш код не работает, выглядит отлично.

Объект создается в контексте script, который впоследствии срывается после завершения запроса. Следовательно, в то время как имя типа доступно, функция объекта нарушена.

Я могу сказать вам, что неплохо хранить объекты в сеансе даже те, которые не созданы в script.

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

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

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

Вы можете сделать это, но вы должны быть немного подлыми. Мое понимание этого — когда вы храните домашний испеченный объект в сеансе, он сохраняет все данные, но теряет все функциональные возможности. Чтобы восстановить функциональность, вы должны «повторно увлажнить» данные из сеанса.

Вот пример в JScript для ASP:

Его довольно мощный метод управления сохранением состояния в сеансе и может быть легко заменен на вызовы DB/XML и т.д., если это необходимо.

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

Илон Маск рекомендует:  Тег группирования столбцов colgroup
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL