Управление на сесии в ASP.NET [Пример]

⚡ Умно обобщение

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

  • 🌐 HTTP без състояние: HTTP не запазва данни между заявките, така че ASP.NET добавя механизми за запазване на състоянието.
  • 🗂️ Състояние на изгледа: ViewState автоматично пренася контролните стойности от една страница на следващата.
  • 🔑 Обект на сесията: Сесия[„Ключ“] съхранява и извлича двойки ключ-стойност през целия жизнен цикъл на приложението.
  • ️ Режими на състоянието: Състоянието на сесията може да се съхранява в Proc, на StateServer, в SQL Server или в персонализирано хранилище.
  • ️ Време за изчакване: Времето за изчакване на sessionState в web.config контролира колко дълго една сесия остава активна.

Урок за управление на ASP.NET сесии с пример

ASP.NET Управление на сесии

HTTP протоколът, по който работят всички уеб приложения, е протокол без състояние. Без гражданство това просто означава, че информацията не се запазва от една заявка до друга.

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

В ASP.Net това се прави по различни начини. Първият начин е чрез концепция, наречена ViewState. Това е мястото, където ASP.Net автоматично съхранява съдържанието на всички контроли. Също така гарантира, че то се предава на следващата страница. Това се прави чрез свойство, наречено ViewState.

Не е идеално за програмист да променя нещо в състоянието на изгледа. Това е така, защото трябва да се обработва само от ASP.Net.

Обект на ASP.NET сесия

Другият начин е да използвате обект, наречен „Обект на сесията“. Обектът Session е достъпен през целия жизнен цикъл на приложението. Можете да съхранявате произволен брой двойки ключ-стойност в обекта Session. Така че на всяка страница можете да съхраните стойност в обекта Session чрез реда с код по-долу.

Session["Key"] = value

Това съхранява стойността в обект Session, а частта „key“ се използва, за да се даде име на стойността. Това позволява стойността да бъде извлечена в по-късен момент. За да извлечете стойност, можете просто да издадете следния оператор.

Session["Key"]

Пример за обект на ASP.NET сесия

В нашия пример ще използваме обекта Session, за да съхраним името, въведено в текстовото поле за име на страницата. След това ще извлечем тази стойност и ще я покажем на страницата съответно. Нека добавим кода по-долу към файла Demo.aspx.cs.

Използвайте обекта на сесията

protected void btnSubmit_Click(object sender, EventArgs e)
{
	Session["Name"] = txtName.Text;

	Response.Write(Session["Name"]);

	lblName.Visible = false;
	txtName.Visible = false;
	lstLocation.Visible = false;
	chkC.Visible = false;
	chkASP.Visible = false;
	rdMale.Visible = false;
	rdFemale.Visible = false;
	btnSubmit.Visible = false;
}

Code Обяснение:

  1. Първият ред код приема стойността на текстовото поле Name и я съхранява в обекта Session. Като указваме кода на Session[“Name”], даваме на свойството име, наречено „Name“. Като указваме име за свойството, става по-лесно да го извлечем в по-късен момент.
  2. Следващият ред код извлича съхранената стойност от обекта Session. След това записва тази стойност чрез метода „Response.Write“ обратно на клиента.
  3. Накрая правим всички контроли във формуляра невидими. Ако не направим това, всички контроли плюс стойностите на отговорите ни ще се показват заедно.

След като направите горните промени, ще видите следния резултат.

Изход:

Използвайте обекта на сесията

От изхода можете да видите, че стойността на сесията на името е извлечена и показана в браузъра.

Режими на състоянието на сесията в ASP.NET

ASP.NET може да съхранява данни от сесии на няколко места, наречени режими на състояние на сесия. Избраният от вас режим влияе върху производителността, мащабируемостта и дали данните оцеляват след рестартиране на приложението. Таблицата по-долу ги сравнява:

вид Къде се съхранява състоянието Най - доброто за
Входен процес В паметта на уеб сървъра (по подразбиране) Приложения за един сървър; най-бързи, но се губят при рестартиране
StateServer Отделен процес на ASP.NET State Service Уеб ферми; оцелява след рестартиране на приложения
SQLServer База данни на SQL Server Уеб ферми, нуждаещи се от издръжливо и мащабируемо състояние
Custom Персонализиран доставчик, който внедрявате Специализирани магазини като Redis
от Състоянието на сесията е деактивирано Приложения, които не се нуждаят от сесии

InProc е по подразбиране и най-бързият, но за внедрявания с балансирано натоварване, StateServer или SQLServer поддържа сесиите достъпни на множество сървъри.

Как да конфигурирате времето за изчакване на сесията в ASP.NET

Сесията не е вечна; тя изтича след период на неактивност. Можете да зададете това време за изчакване във файла web.config, като използвате елемента sessionState, където стойността на времето за изчакване е в минути:

<configuration>
  <system.web>
    <sessionState mode="InProc" timeout="20" />
  </system.web>
</configuration>

Можете също да го зададете в код с Session.Timeout = 30;Времето за изчакване по подразбиране е 20 минути. Избирането на по-кратко време за изчакване освобождава паметта на сървъра по-бързо и подобрява сигурността, докато по-дългото време за изчакване държи потребителите влезли в системата за по-дълго време.

Предимства и недостатъци на състоянието на сесията

Състоянието на сесията е удобно, но има компромиси, които трябва да прецените, преди да разчитате сериозно на него.

Предимства:

  • Лесен за използване за съхраняване на данни за всеки потребител, като например данни за магазинping данни за количка или вход.
  • Може да съхранява сложни обекти, не само низове.
  • Данните се съхраняват на сървъра, така че са по-сигурни от съхранението от страна на клиента.

Недостатъци:

  • Режимът InProc изразходва памет на сървъра и не се мащабира в уеб ферма.
  • Данните от сесията се губят, когато времето за изчакване на сесията изтече или приложението се рестартира (в режим InProc).
  • Съхраняването на големи количества данни на потребител може да навреди на производителността при голямо натоварване.

Въпроси и Отговори

Да. Асистентите с изкуствен интелект могат да генерират код за съхраняване и четене на стойности на сесията, да предложат правилния режим на състояние и да запишат настройките на web.config. RevПрегледайте генерирания код, за да потвърдите, че той отговаря на вашите нужди за мащабируемост и сигурност.

Да. Инструментите за преглед на код, базирани на изкуствен интелект, могат да сигнализират за рискове като фиксиране на сесия, липсващи HTTPS-бисквитки или съхраняване на чувствителни данни по време на сесия. Приемайте констатациите като насоки и потвърждавайте корекциите с тестове за сигурност преди внедряване.

Състоянието на сесията съхранява данни за сесията на един потребител, докато състоянието на приложението съхранява данни, споделени от всички потребители на приложението. Използвайте сесията за стойности за всеки потребител, а приложението – за глобални данни, като например броячи или конфигурация.

Не. Всеки потребител получава отделна сесия, идентифицирана с уникален идентификатор на сесията, съхранен в „бисквитка“. Един потребител не може да чете стойностите на сесията на друг потребител, поради което „Сесия“ се използва за данни за всеки потребител.

Обобщете тази публикация с: