Session timeout что это
Тайм-аут сеанса в ASP.NET
Я использую приложение ASP.NET 2.0 в IIS 6.0. Я хочу, чтобы время ожидания сеанса составляло 60 минут, а не 20 минут по умолчанию. Я сделал следующее
Я все еще получаю тайм-аут сессии в 20 минут. Есть ли что-нибудь еще, что мне нужно сделать?
Вы используете проверку подлинности с помощью форм?
Проверка подлинности с помощью форм использует свое собственное значение для тайм-аута (по умолчанию 30 минут). Тайм-аут аутентификации форм отправит пользователя на страницу входа в систему с еще активным сеансом. Это может выглядеть как поведение вашего приложения по истечении времени сеанса, что позволяет легко спутать одно с другим.
Установка времени ожидания формы на меньшее, чем время ожидания сеанса, может дать пользователю окно для входа в систему без потери данных сеанса.
Я не знаю о web.config или IIS. Но я считаю, что из кода C # вы можете сделать это как
Используйте следующий блок кода в вашем файле web.config. Здесь время сеанса по умолчанию составляет 80 минут.
Используйте следующую ссылку для Session Timeout с всплывающим предупреждающим сообщением.
К сведению: приведенные выше примеры сделаны с помощью всплывающего элемента управления devexpress, поэтому вам нужно настроить / заменить всплывающий элемент управления devexpress обычным управлением всплывающими окнами. Если вы используете devexpress, нет необходимости настраивать
Есть ли у вас что-нибудь в machine.config, которое может вступить в силу? Задание времени ожидания сеанса в web.config должно переопределить любые настройки в IIS или machine.config, однако, если у вас есть файл web.config где-то в подпапке вашего приложения, этот параметр переопределит тот, который находится в корне вашего приложения.
В моей ситуации это был Application Pool. Он настроен на перезапуск при простое в течение хх минут. Когда я установил его не перезагружать, он использует значение из Web Config.
Если вы используете аутентификацию, я рекомендую добавить следующее в файл web.config.
В моем случае пользователи перенаправляются на страницу входа по истечении времени ожидания:
Или, если вы хотите использовать appsettings.json файл, вы можете сделать что-то вроде:
Вы можете найти настройки здесь в IIS:
Его можно найти на уровне сервера, веб-сайта или приложения в разделе «ASP».
Я думаю, что вы можете установить его на уровне web.config здесь. Пожалуйста, подтвердите это для себя.
Время ожидания сеанса по умолчанию определено в IIS до 20 минут.
Следуйте приведенным ниже процедурам для каждого сайта, размещенного на веб-сайте IIS 8.5.
Нажмите на название сайта.
Выберите «Редактор конфигурации» в разделе «Управление».
В раскрывающемся списке «Раздел:» в верхней части редактора конфигурации найдите «system.web / sessionState».
На панели «Действия» нажмите «Применить».
Настройка значения времени ожидания для сеанса
Настройте время, в течение которого сеанс входа или экземпляр Meeting будет продолжать ожидание до его отключения сервером.
В сеансах Adobe Connect используются компоненты Adobe Connect Meeting и Adobe Connect Central. Значение времени ожидания для сеанса указывает, как долго продолжается ожидание сеанса до его отключения сервером. При отключении сеанса пользователь перенаправляется на страницу входа Adobe Connect Central.
Для настройки времени ожидания для сеанса в файле custom.ini выполните следующие действия.
Откройте файл [корневой_каталог_установки]\custom.ini в текстовом редакторе.
Выберите для следующих параметров нужное значение в минутах. В следующем примере продолжительность тайм-аут для сеанса изменена на 60 минут.
Параметр SESSION_TIMEOUT управляет значениями тайм-аута для Adobe Connect Central. Минимальное допустимое значение этого параметра (в минутах) составляет 5, а максимальное — 720. Значение по умолчанию — 30 минут.
Параметр CONNECT_APP_SESSION_TIMEOUT управляет значениями тайм-аута для сеанса собрания в приложении Adobe Connect для настольных ПК под управлением Windows и Mac. Минимальное допустимое значение этого параметра (в минутах) составляет 0, а максимальное — 43 200 (30 дней). Значение по умолчанию — 4 дня.
В течение указанного выше тайм-аута можно закрывать и открывать любое количество сеансов в приложении Adobe Connect для настольных ПК без необходимости повторно вводить учетные данные для входа. Это работает в приложении как для Windows, так и для Mac.
Настройка лимитов (таймаутов) для RDP/RDS сессий в Windows
По-умолчанию, когда пользователь со своего компьютера закрывает окно своей RDP/RDS сессией в терминальном клиенте (mstsc, rdcman или rdp html web клиент) простым нажатием по крестику в окне, без выполнения выхода (logoff), его сессия переходит в режим disconnected (разъединённый сеанс). В этом режиме все запущенные пользователем программы, открытые документы и окна продолжают работать на удаленном сервере и потреблять ресурсы.
По-умолчанию в Windows RDP сессия пользователя может находится в состоянии disconnected до перезагрузки компьютера или явного ее завершения пользователем или администратором. Это довольно удобно, т.к. пользователь может в любой момент подключиться к своей старой сессии и продолжить работу с открытыми программами и документами.
На следующем скриншоте видно, что отключенные сессии пользователей на RDS сервере с Windows Server 2016 используют около 35% памяти сервера. Кроме того незавершенные сессии могут блокировать открытые файлы на файловых серверах, вызывать проблемы с корректным сохранением данных в приложениях, профилях или User Profile Disks.
С помощью команды quser можно узнать, когда начата RDP сессия пользователя, длительность простоя и статус сессии.
Для автоматического завершения отключенных RDP/RDS сессий через определенный промежуток времени, вам нужно правильно настроить лимиты (таймауты).
При использовании RDS сервера, вы можете настроить параметры таймаутов сессий в настройках RDS коллекций на вкладке Session.
Укажите время, через которое нужно завершить отключенный сеанс в параметре End a disconnected session (по умолчанию срок сеанса неограничен – never). Также вы можете выставить максимальную длительность активной RDP сессии (Active session limit) и отключение бездействующего сеанса (Idle session limit). Это жесткие таймауты применяются для всех сессий в RDS коллекции.
Также можно настроить ограничение времени RDP сессии в свойства локального (консоль lusrmgr.msc) или доменного пользователя (консоль dsa.msc — ADUC).
В Windows Server 2012 R2/2016/2019 можно настроить таймауты RDP сессий с помощью групповых политик. Можно использовать как редактор доменных GPO gpmc.msc, так и редактор локальных групповых политик (gpedit.msc) на конкретном RDS сервере или клиенте (если вы используете десктопную Windows в качестве терминального сервера)
Параметры таймаутов RDP сессий находятся в разделе GPO
По умолчанию эти параметры не настроены. Чтобы автоматически завершать отключенные RDP сеансы пользователей через 8 часов, включите политику “Set time limit for disconnected session” = Enabled, и в выпадающем списке выберите 8 часов.
Сохраните изменения и обновите политики сервера (gpupdate /force). Новые настройки таймаутов будут применяться только к новым RDP сеансам, текущие сеансы придется завершить вручную.
Состояние сеанса
— это самая сложная технология для управления состояниями. Она позволяет сохранять информацию на одной странице и затем получать к ней доступ с другой страницы, а также поддерживает объекты любого типа, включая специальные, создаваемые самим разработчиком типы данных. Лучше всего то, что состояние сеанса использует такой же основанный на коллекциях синтаксис, что и состояние представления. Единственное отличие связано с именем встроенного свойства страницы, которое в данном случае выглядит как Session.
Каждый клиент, который получает доступ к приложению, имеет свой сеанс и отдельную коллекцию данных. Состояние сеанса идеально подходит для сохранения таких данных, как элементы, которые находятся в корзине для покупок пользователя, когда он переходит с одной страницы на другую.
Но за использование состояния сеанса необходимо платить свою цену. Хотя оно решает многие из проблем, которые возникают в случае применения других технологий управления состояниями, его использование вынуждает веб-сервер сохранять дополнительную информацию в памяти. Необходимость в использовании дополнительных ресурсов памяти сервера, пусть даже в небольшом объеме, очень быстро может достичь угрожающего производительности уровня, когда к сайту начнут получать доступ тысячи клиентов.
Архитектура сеанса
Управление сеансом не является частью HTTP-стандарта. Поэтому для отслеживания информации сеанса и ее привязки к соответствующему ответу ASP.NET приходится выполнять дополнительную работу.
ASP.NET отслеживает каждый сеанс с помощью уникального 120-битового идентификатора. Для генерации этого значения ASP.NET использует патентованный алгоритм, что, согласно статистике, обеспечивает гарантию того, что число будет уникальным и достаточно случайным для того, чтобы злоумышленник не смог воссоздать или угадать идентификатор сеанса, которым будет пользоваться данный клиент. Этот идентификатор является единственным фрагментом информации, который передается между вебсервером и клиентом.
Когда клиент предоставляет идентификатор сеанса, ASP.NET отыскивает соответствующий сеанс, извлекает с сервера состояний сериализированные данные, преобразует их в реальные объекты и помещает эти объекты в специальную коллекцию для того, чтобы к ним можно было получить доступ в коде. Весь этот процесс выполняется автоматически.
При каждом новом запросе ASP.NET генерирует новый идентификатор сеанса до тех пор, пока состояние сеанса не будет фактически использовано для сохранения какой-то информации. Такое поведение позволяет немного увеличить производительность. Коротко это можно объяснить так: зачем тратить время на сохранение идентификатора сеанса, если он не используется?
Когда ASP.NET обрабатывает HTTP-запрос, тот проходит через конвейер различных модулей, которые могут реагировать на события приложения. Одним из модулей в этой цепочке является SessionStateModule (который находится в пространстве имен System.Web.SessionState). Этот модуль генерирует идентификатор сеанса, извлекает из внешних поставщиков состояния данные сеанса и затем привязывает эти данные к контексту вызовов запроса. Он также сохраняет данные состояния сеанса, когда обработка страницы завершается.
Однако важно понимать, что модуль SessionStateModule фактически не хранит данные сеанса. Вместо этого состояние сеанса сохраняется во внешних компонентах, которые называются поставщиками состояния:
Чтобы механизм состояния сеанса работал, клиент вместе с каждым запросом должен предоставлять соответствующий идентификатор сеанса. Финальным фрагментом данной головоломки является способ отслеживания этого идентификатора сеанса от одного запроса к другому. Это можно делать двумя способами:
С применением cookie-наборов. В этом случае идентификатор сеанса передается в специальном cookie-наборе (по имени ASP.NET_SessionId), который ASP.NET создает автоматически, когда используется коллекция сеанса. Он применяется по умолчанию и соответствует способу из более ранних версий ASP.
С помощью измененных URL-адресов. В этом случае идентификатор сеанса передается в специально измененном URL-адресе. Это дает возможность создавать приложения, которые используют состояние сеанса для клиентов, не поддерживающих cookie-наборы.
Использование состояния сеанса
Взаимодействовать с состоянием сеанса можно с помощью класса System.Web.SessionState.HttpSessionState, который на веб-странице ASP.NET доступен в виде встроенного объекта Session. Синтаксис для добавления элементов в эту коллекцию и их извлечения выглядит практически так же, как и синтаксис, который используется для добавления элементов в состояние представления страницы.
Например, вот как сохранить объект DataSet в памяти сеанса:
После этого его можно извлечь с помощью соответствующей операции преобразования:
Контекст состояния сеанса охватывает все приложение и является глобальным для текущего пользователя. Данные состояния сеанса могут быть утеряны в следующих случаях:
Если пользователь закрывает и заново запускает браузер.
Если пользователь получает доступ к той же странице через другое окно браузера, хотя сеанс будет по-прежнему существовать, если доступ к веб-странице получается из исходного окна браузера. Разные браузеры ведут себя в такой ситуации по-разному.
Если сеанс завершается из-за отсутствия активности со стороны пользователя. По умолчанию сеанс автоматически завершается после 20 минут простоя.
Если программист завершает сеанс вызовом метода Session.Abandon().
В первых двух случаях данные состояния сеанса фактически остаются в памяти сервера, потому что веб-сервер не разбирается в том, закрыл клиент окно браузера или открыл новое. Они будут продолжать находиться там, оставаясь недоступным, до тех пор, пока не истечет срок их хранения.
Вдобавок данные состояния сеанса также будут утеряны и в случае повторного создания домена приложения. Этот процесс происходит автоматически при обновлении веб-приложения либо изменении конфигурационных параметров. Домен приложения также может создаваться заново через определенные промежутки времени для поддержания приложения в нормальном работоспособном состоянии. Если такое поведение приводит к возникновению проблем, данные состояния сеанса можно хранить вне процесса. В таком случае они не потеряются даже в результате завершения домена приложения.
В таблице ниже перечислены основные методы и свойства класса HttpSessionState:
Конфигурирование состояния сеанса
Сконфигурировать состояние сеанса можно с помощью элемента в файле web.config. Ниже показаны все доступные параметры настройки, которые можно применять:
Атрибуты сеанса подробно описаны в последующих разделах.
Параметр настройки состояния сеанса Mode позволяет указать, какой поставщик состояния сеанса должен использоваться для хранения данных состояния сеанса между запросами. Допустимые значения перечислены ниже:
Установка значения Off отключает управление состоянием сеанса для всех страниц в приложении. Это может немного увеличить производительность веб-сайтов, которые не используют состояние сеанса.
InProc
Установка значения InProc напоминает подход, который использовался для хранения состояния сеанса в классической версии ASP. Это значение указывает ASP.NET хранить информацию в текущем домене приложения, что обеспечивает наилучшую производительность, но наименьший срок хранения: если вы перезапустите сервер, данные состояния будут утеряны.
Значение InProc используется по умолчанию и подходит для большинства веб-сайтов небольшого размера. Однако в сценарии веб-фабрики от него не будет никакого толку. Чтобы состояние сеанса совместно использовалось множеством серверов, необходимо применять внепроцессный поставщик или службу состояний SQL Server.
Еще одна причина, по которой установка значения InProc может быть нежелательной, состоит в том, что она приводит к получению более «хрупких» сеансов. В ASP.NET домены приложений создаются заново в ответ на различные действия, включая изменения конфигурационных настроек, обновления страниц, а также достижение определенных пороговых значений (независимо от того, произошла ошибка или нет). Если вы обнаружите, что домен приложения часто перезапускается, что приводит к преждевременному завершению сеансов, можете воспользоваться одним из более надежных поставщиков состояния сеанса.
StateServer
В случае установки этого значения ASP.NET будет использовать для управления состоянием отдельную Windows-службу. Даже при запуске на том же самом веб-сервере эта служба будет загружаться за пределами главного процесса ASP.NET, что обеспечивает для нее базовый уровень защиты, когда возникает необходимость перезапуска процесса ASP.NET. Недостаток такого подхода в том, что из-за передачи данных состояния между двумя процессами увеличивается время задержки. Если доступ к данным сеанса получается часто, и они часто изменяются, работа может существенно замедлиться.
Выбрав режим StateServer, обязательно следует указать значение для параметра stateConnectionString. Эта строка сообщает TCP/IP-адрес компьютера, на котором запускается служба StateServer, и номер его порта (который определяется ASP.NET и который обычно изменять не нужно), что позволяет обслуживать службу StateServer на другом компьютере. Если не изменить значение этого параметра, использоваться будет локальный сервер (с адресом 127.0.0.1).
Отыскав службу в списке, вы можете вручную запустить или остановить ее с помощью щелчка правой кнопкой мыши. Обычно имеет смысл сконфигурировать ОС Windows так, чтобы эта служба запускалась автоматически. Для этого щелкните на имени службы правой кнопкой мыши, в появившемся контекстном меню выберите пункт Properties (Свойства). После этого в списке Startup Type (Тип запуска) выберите значение Automatic (Автоматически), как показано на рисунке ниже. Далее щелкните на кнопке Start (Запустить), чтобы запустить эту службу немедленно.
Используя режим StateServer, можно также установить значение для необязательного атрибута stateNetworkTimeout, задающего максимальное количество секунд, в течение которых должен ожидаться ответ от службы, прежде чем запрос будет отменен. По умолчанию это значение равно 10 секунд.
SQLServer
Это значение заставляет ASP.NET использовать для хранения информации о сеансе базу данных SQL Server, применяя параметры, определенные в атрибуте sqlConnectionString. Такой способ управления состоянием является наиболее удобным, но пока что самым медленным. Чтобы его можно было использовать, на сервере должна быть установлена система SQL Server.
Установка значения для атрибута sqlConnectionString выполняется по схеме, подобной той, что применяется для получения доступа к данным ADO.NET. В целом это подразумевает указание источника данных (адреса сервера), имени пользователя и пароля, если только не используется интегрированная система безопасности SQL.
Вдобавок также должны быть установлены специальные хранимые процедуры и временные базы данных сеансов. Эти хранимые процедуры будут отвечать за сохранение и извлечение данных сеанса. В состав ASP.NET входит утилита командной строки, позволяющая выполнять эту задачу автоматически. Называется она aspnet_regsql.exe и находится в каталоге c:\Windows\Microsoft.NET\Framework\[Версия].
Ниже показана команда, которая создает базу данных для хранения данных сеанса на текущем компьютере, используя для нее стандартное имя ASPState:
В этой команде используется псевдоним localhost, который указывает aspnet_regsql.exe подключаться к серверу баз данных на текущем компьютере. Но вместо этого псевдонима может использоваться имя любого другого компьютера, на котором находится нужный сервер баз данных.
После создания базы данных состояния сеанса необходимо указать ASP.NET ее использовать, внеся соответствующие изменения в раздел файла web.config. Если для хранения информации о состоянии сеанса была создана база данных ASPState (это принято по умолчанию), тогда предоставлять ее имя в разделе не нужно. Вместо этого следует указать место размещения сервера и тип аутентификации, который ASP.NET должна применять для подключения к этому серверу:
На этом процедура настройки завершена. Однако если нужно использовать постоянные сеансы или специальную базу данных, эти шаги могут быть немного изменены, как будет показано далее.
Обычно при управлении состоянием с помощью SQL Server по-прежнему действует стандартный параметр тайм-аута состояния сеанса. Причина в том, что утилита aspnet_regsql.exe также создает для SQL Server новое задание по имени ASPState_Job_DeleteExpiredSessions. До тех пор, пока работает служба SQLServerAgent, это задание будет выполняться каждую минуту.
Теперь записи сеанса будут оставаться в базе данных даже в случае перезапуска SQL Server.
При таком подходе таблицы данных сеанса будут сразу же созданы как постоянные, так что содержащиеся в них записи будут оставаться даже после перезапуска SQL Server.
В случае использования специальной базы данных также потребуется выполнить две конфигурационные настройки в разделе файла web.сonfig. Во-первых, необходимо установить атрибут allowCustomSqlDatabase в true. Во-вторых, понадобится добавить в строку соединения параметр InitialCatalog с именем используемой базы данных. Ниже показан должным образом настроенный элемент :
В случае выбора режима SQLServer также можно устанавливать значение для необязательного атрибута sqlCommandTimeout, который задает максимальное количество секунд на ожидание ответа от базы данных перед отменой запроса. По умолчанию значение равно 30 секундам.
Custom
Выбор специального (Custom) режима требует указания используемого поставщика хранилища данных о состоянии сеанса с помощью атрибута customProvider. В атрибуте customProvider может быть задано как имя класса, являющегося частью веб-приложения и хранящегося в каталоге App_Code, так и имя класса, входящего в состав скомпилированной сборки и хранящегося в каталоге Bin или в глобальном кэше сборок (GAC).
К числу наиболее распространенных причин для применения специального поставщика хранилища данных о состоянии сеанса относится необходимость хранить информацию сеанса в базе данных, отличной от SQL Server, и потребность использовать какую-то существующую таблицу в базе данных, которая имеет определенную схему.
Создание специального поставщика представляет собой низкоуровневую процедуру, которая должна проводиться очень тщательно и осторожно для гарантии безопасности, стабильности и масштабируемости, из-за чего всегда лучше пользоваться готовым поставщиком, который был разработан и протестирован надежной сторонней компанией.
Сжатие
В ASP.NET доступно средство сжатия, которое позволяет сократить размер сериализируемых данных сеанса. Если установить атрибут enableCompression в true, данные сеанса перед отправкой за пределы процесса будут сжиматься (с использованием класса System.IO.Compression.GZipStream). Параметр enableCompression действует только при использовании внепроцессного хранилища состояния сеанса, поскольку только в такой ситуации данные сериализируются.
Для сжатия и восстановления данных сеанса веб-сервер должен выполнять дополнительную работу. Однако обычно это никакой проблемы не представляет, т.к. сжатие применяется лишь в тех сценариях, когда веб-серверы имеют массу лишнего времени ЦП, но ограничены по каким-то другим показателям. Сжатие данных состояния сеанса имеет смысл в описанных двух ключевых ситуациях:
При сохранении больших объемов данных состояния сеанса в памяти. Память вебсервера является очень ценным ресурсом. В идеале состояние сеанса применяется для сохранения относительно небольших фрагментов информации, а для остальных требующих более длительного хранения и больших по объему данных применяется база данных. Но если это не так и внепроцессный сервер состояния требует огромных объемов памяти, сжатие может оказаться подходящим решением.
При сохранении данных состояния сеанса данных на другом компьютере. В некоторых веб-приложениях с высокой степенью масштабируемости состояние сеанса сохраняется за пределами процесса (обычно в базе данных SQL Server) или на отдельном компьютере. Из-за этого среда ASP.NET должна передавать информацию сеанса туда и обратно через сетевое соединение. Очевидно, что при таком проектном решении показатели производительности будут значительно ниже, чем при сохранении состояния сеанса на компьютере веб-сервера. Однако для некоторых веб-приложений, с высоким трафиком и большими потребностями в плане сохранения данных состояния сеанса это решение все равно может быть лучшим компромиссом.
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-наборов (что удобно для целей тестирования):
В режиме без поддержки cookie-наборов идентификатор сеанса будет автоматически вставляться в URL-адрес. Получив запрос, ASP.NET будет удалять идентификатор, извлекать коллекцию сеанса и направлять запрос в соответствующий каталог. Измененный URL-адрес показан ниже:
Поскольку идентификатор сеанса вставляется в текущий URL-адрес, все относительные ссылки также автоматически получают этот идентификатор сеанса. Другими словами, если пользователь на текущий момент находится на странице Page1.aspx и щелкает на относительной ссылке, указывающей на страницу Page2.aspx, эта относительная ссылка будет включать текущий идентификатор сеанса как часть URL-адреса. То же самое произойдет и если вызвать метод Response.Redirect() с относительным URL-адресом.
Единственное реальное ограничение режима без поддержки cookie-наборов состоит в том, что с ним нельзя применять абсолютные ссылки, потому что они не будут содержать идентификатора сеанса. Например, выполнение следующего оператора приведет к утрате пользователем всей информации о сеансе:
По умолчанию ASP.NET допускает повторное использование идентификатора сеанса. Например, если делается запрос и строка запроса содержит просроченный сеанс, ASP.NET создает новый сеанс и использует этот же идентификатор сеанса. Проблема в том, что идентификатор сеанса может случайно появиться в каком-то публичном месте, например, на странице результатов в поисковой службе. Это может привести к тому, что множество пользователей получат доступ к серверу с одним и тем же идентификатором сеанса и затем присоединятся к одному и тому же сеансу с теми же самыми разделяемыми данными.
Во избежание такой потенциальной угрозы безопасности, рекомендуется включать в код необязательный атрибут regenerateExpiredSessionId и устанавливать его в true при использовании сеансов без cookie-наборов. В этом случае при подключении пользователя с просроченным идентификатором сеанса будет генерироваться новый идентификатор сеанса.
Единственный недостаток такого подхода состоит в том, что он подразумевает утерю всех данных состояния представления и формы на текущей странице, т.к. для обеспечения нового идентификатора сеанса ASP.NET выполняет переадресацию браузера.
Чтобы выяснить, используется ли в текущий момент сеанс без cookie-наборов, необходимо проверить свойство IsCookieless объекта Session.
Timeout
Еще одним важным параметром настройки состояния сеанса в файле web.config является Timeout. Он указывает количество минут, в течение которых ASP.NET будет находиться в режиме ожидания (не получая запрос), прежде чем завершит сеанс:
Этот параметр является одним из наиболее важных параметров состояния сеанса. Неправильно выбранное количество минут может значительно увеличить нагрузку на сервер и крайне негативно сказаться на производительности приложения. В идеале выбираемый промежуток времени должен быть достаточно коротким для того, чтобы сервер мог быстро восстанавливать бесценные ресурсы памяти после того, как клиент прекращает использовать приложение, но и достаточно длинным для того, чтобы клиент мог делать паузу и продолжать сеанс, не утратив его.
Значение параметра Timeout можно также изменять в коде. Например, если известно, что сеанс содержит чрезвычайно большое количество информации, время хранения сеанса лучше ограничить. Для этого можно отобразить пользователю соответствующее предупредительное сообщение и затем просто изменить значение свойства Timeout. Следующая строка кода ограничивает время тайм-аута до 10 минут:
Обеспечение безопасности состояния сеанса
Данные в состоянии сеанса хорошо защищены, т.к. они хранятся исключительно на сервере. Однако cookie-набор и идентификатор сеанса крайне уязвимы. Это означает, что злоумышленник может похитить cookie-набор и инициировать сеанс на другом компьютере.
Существует несколько подходов, позволяющих обойти эту проблему. Наиболее распространенный из них — воспользоваться специальным модулем сеанса, выполняющим проверку на наличие изменений в IP-адресе клиента. Однако единственным действительно безопасным подходом является разрешение доступа к cookie-наборам сеанса только из тех разделов веб-сайта, где используется SSL-шифрование. В таком случае cookie-набор сеанса шифруется и, следовательно, становится бесполезным на других компьютерах.
Если решено воспользоваться этим подходом, также имеет смысл пометить cookie-набор как безопасный, чтобы он пересылался только через SSL-соединения. Это не позволит пользователям изменять URL-адрес с https:// на http:// и, следовательно, пересылать cookie-набор без SSL-шифрования. Ниже показан необходимый код:
Как правило, этот код применяется сразу после аутентификации пользователя. Удостоверьтесь, что в состоянии сеанса присутствует, по крайней мере, один фрагмент информации, чтобы сеанс не был завершен (и позже создан заново).
При использовании сеансов без cookie-наборов существует еще одна потенциальная угроза нарушения системы безопасности. Даже если идентификатор сеанса зашифрован, применив прием социальной инженерии, сообразительный пользователь может вынудить другого пользователя подключиться к определенному сеансу. Все, что злоумышленнику понадобится — это подсунуть другому пользователю URL-адрес с действительным идентификатором сеанса. Щелкнув на ссылке, этот пользователь сразу же подключится к такому сеансу. Хотя с этого момента идентификатор сеанса будет защищаться, атакующему уже известно, какой идентификатор сеанса используется, поэтому он сможет позже взломать этот сеанс.
Чтобы снизить возможность такой атаки, необходимо выполнить ряд определенных шагов. Во-первых, при использовании сеансов без cookie-наборов всегда устанавливайте атрибут regenerateExpiredSessionId в true. Это не позволит злоумышленнику предоставлять просроченный идентификатор сеанса. Во-вторых, явно прекращайте текущий сеанс перед входом в систему нового пользователя.