jarda jirava .net - stránky věnované .net technologii, vývoji software s pomocí .net frameworku, návrhu software a architektuře řešení asp.net providers

Jistě každý zná situaci, kdy je nutné lokalizovat aplikaci a nabídnout ji uživatelům v několika jazykových mutacích. .NET framework toto řeší velice elegantně pomocí resource souborů a ResourceManagera. V asp.net 2.0 je celé řešení velice důmyslně řešeno, kdy je možnost jít ještě dále a nabízí se tak mít lokální a globální resource soubory, o tom, jak to celé funguje napsal poměrně zajímavý blogspot také Robert Haken v článku Lokalizace snadno a rychle - explicitní lokalizace. Jak už to však bývá, ne vše je tak kulaté jak se zdá.

Je to už nějaká chvíle co byl na konferenci o .net na fóru builder.cz položen dotaz ohledně možnosti lokalizace asp.net aplikací. Tenkrát jsem slíbil, že se pokusím sepsat nějaký krátký příspěvek na toto téma a zpřístupnit tak své nabyté zkušenosti také ostatním.

O co se konkrétně jedná? Autora dotazu zajímalo, zda je možné použít k lokalizaci texty, které má umístěny v databázi. Odkazů na řešení daného úkolu se našlo hnedka několik, ale většinou se jednalo o takové řešení, které nebylo elegantní (alespoň mě se nezdálo). Převážně se taková řešení opírala o skutečnost, že je nutné explicitně provést lokalizaci daného textu z codebehind stránky tj. vytvořit si nějaký vlastní DbResourceManager a pomocí metod GetString provádět lokalizaci jednotlivých textů. Přitom je velice elegantní a dostupné řešení v asp.net 2.0, a to použítí meta značek a nebo alespoň použití explicitní lokalizace tedy uvedení této konstrukce.

property="<%$ Resources: LokalizovanyText %>"

Jaká je tedy možnost lokalizace v případě, že nechci používat resource soubory? Mám já, jako vývojář, nějakou možnost si říci, že všechny texty budou uloženy třeba v databázi a odsud se budou načítat? A to ještě pokud možno s co nejmenším úsilým, které k lokalizaci bude nutné udělat? Nebude nutné se uchýlit k nějakému vlastnímu formátu řešení lokalizace, byť by bylo sebelépe navrženo, a upustit tak od modelu, který je v současné chvíli podporován v asp.net 2.0? Nesetkám se zde s podobným problémem, který nastavá u celkové konfigurace aplikace, kdy je možné používat ConfigurationManager pouze ve spojitosti s .config souborem a přitom je občas vhodné mít konfiguraci uloženu i jinde? 

Na poslední otázky je však v souvislosti s lokalizací možné odpovědět, nikoliv. Tím řešením je napsat si vlastní ResourceProviderFactory a implementovat několik rozhraní případně dědit z tříd již existujících. To celé potom spojit v jeden funkční celek pomocí konfiguračního souboru web.config v jeho sekci globalization a to atributem resourceProviderFactoryType.

O tom, jak si napsat takový jednoduchý ResourceProvider, kterým je možné lokalizovat asp.net aplikace a vesměs pouze přepínat pomocí konfigurace mezi jednotlivými možnostmi, se rozepíšu příště.

Jistě sami naleznete několik scénářů ve vlastní aplikaci, kdy zjistíte, že je dobré znát právě přihlášeného uživatele. Ať už je to z důvodu, že mu chcete udělat radost a přivítat jej oslovením, nabídnout mu něco navíc, co nepřihlášenému nemůžete, nebo mu jenom ušetřit práci s vyplňováním informací ve formuláři (příkladem mohou být e-shopy). Z toho důvodu je k dispozici Membership provider. Na druhé straně ovšem stojí otázka bezpečnosti citlivých dat. Snad každá lepší aplikace má svoje administrační rozhraní, ke kterému by měli mít přístup pouze oprávnění uživatelé a v takových situacích nám nebude stačit vědět pouze to, že daný uživatel je přihlášen. Budeme chtít uživatele přiřazovat do jednotlivých rolí, abychom jim zpřístupnili pouze tu "správnou" část aplikace, ve které má smysl, aby se pohybovali a činili nějaké úkony.

K zajištění tohoto úkolu nám poslouží právě Role provider. Ten umožňuje k založeným uživatelům přiřazovat role. V tomto ohledu se fantazii meze nekladou, a tak jeden uživatel, může být členem hned několika rolí a samozřejmě záleží jen na našem uvážení, zda potom takový uživatel bude mít dostatečná práva pro činnosti, které má vykonávat, nebo naopak nebude mít práv příliš mnoho. A to hlavně z toho důvodu, že podle těchto rolí je řízen přístup k jednotlivým zdrojům (stránkám, prvkům) naší aplikace.

Role uživatelů

Přiřazování

Když jsem se minule zmiňoval o velké podpoře v oblasti připravených uživatelským prvků, které postačovalo umístit na stránku a téměř vše bylo hotovo, v případě role providera je tomu naopak. Pro přiřazení role uživatelům musíme sáhnout do vlastních řad a prvky si vytvořit sami, případně můžeme využít možností již zmíněného nástroje Web site administration tool.

Ověřování

K práci s rolemi používáme, stejně jako u ostatních providerů, statickou třídu, tentokráte pojmenovanou Roles. K ověřování příslušnosti uživatele do role, můžeme použít ovšem hned tři možnosti, první z nich je metoda Roles.IsUserInRole(string role), která vezme aktuálně přihlášeného uživatele a ověří jej proti předané roli. Druhou možností je opět stejně nazvaná metoda, ale se dvěma parametry Roles.IsUserInRole(string username, string role) umožňující ověřit příslušnost jakéhokoli uživatele, zda je členem dané role. Poslední možností je použít vlastnost User (objektu Page nebo HttpContextu) a metodu, jak jinak, opět nazvanou IsUserInRole.

Na tomto místě je dobré se zmínit o tom, že kontrolovat přístup ke zdrojům nemusíme dělat jen my, ale tuto úlohu za nás plní i některé uživatelské prvky. Jako dobrý příklad bych mohl zmínit TreeView kontrol napojený na Site map provider s povolenou vlastností securitytrimmingenabled. Pokud je pak u položky menu vyplněna vlastnost Roles, porovnává se tato s rolemi přiřazenými pro uživatele a v případě, že daný uživatel nemá oprávnění na danou položku, tato se mu nezobrazí.

Nastavujeme oprávnění přístupu

V okamžiku, kdy jsem se v minulém odstavci zmiňoval o oprávněních uvědomil jsem si, že vlastně ještě nevíme, jak takové oprávnění nastavit. Samozřejmě to není nic těžkého a jedná se o jednoduchý zásah do konfiguračního souboru aplikace. V části pojmenované // můžeme specifikovat uživatele nebo role, které mají přístup do které části aplikace a do kterých jim má být přístup odmítnut. Jak se jistě dozvíte i odjinud, konfigurační soubor může být umístěn v každé složce a může obsahovat tyto informace, případně můžete mít pouze jeden konfigurační soubor a specifikovat element location s atributem path, který určí příslušný soubor nebo adresář, pro který budou platit nastavení. Níže se nachází část konfiguračního souboru, který umožní přístup anonymním uživatelům k souboru logon.aspx, aby se mohli přihlásit k aplikaci.

V závislosti na tom, jak máme strukturován web, tak můžeme povolovat a zakazovat přístup uživatelům, ale spíše předpokládám, že se budeme snažit nastavovat oprávnění právě skupinám. Tudíž elementy, které nás budou zajímat jsou

Nebo můžeme využít zástupných znaků * pro všechny uživatel a ? pro anonymní uživatele.

bezpečná aplikace

Právě jsme si dokázali, že zabezpečit aplikaci a nastavit oprávnění pro jednotlivé uživatele a role nemusí být vůbec náročné. Samozřejmě je nutné zminit, že to již bylo možné použít v .NETu 1.0 nebo 1.1, ovšem nikoli s takovou variabilitou. Neboť nesmíme zapomínat na to, co je hlavním důvodem a účelem pro použití provider patternu a tou je nezávislost, možnost změny. Také z toho důvodu je nutné připomenout, ža jako výchozí provider je nastaven AspNetSqlProfileProvider a pokud jej chceme změnit za jiný, můžeme tak učinit v konfiguračním souboru. Jako mávnutím kouzelným proutkem tak můžeme přebírat nastavení z Active directory nebo například xml souboru.

Pomalu se dostáváme k providerům, které můžeme sice použít samostatně, ale při jejich použít je budeme většinou využívat společně. Jedná se o Membership, který si představíme nyní, tak také Role a Profile provider, na které přijde řada v nejbližší možné době.

Membership provider použijeme v okamžiku, kdy chceme spravovat uživatele naší aplikace, pokud chceme zajistit vytvoření uživatelského účtu, změnu hesla nebo jeho obnovení, můžeme si vynutit použití kontrolní otázky. Dále pak slouží k validaci uživatelského jména a přístupového hesla uživatele, který přistupuje do aplikace, a nesmíme zapomenout na to, že k danému uživateli můžeme sledovat další dodatečné informace jako je email adresa a další.

Jak už jsem se zmínil v prvním odstavci, membership provider budeme většinou používat ve spojitosti s role providerem. Neboť membership umožňuje pouze authentikaci uživatele, nikoli však už jeho autorizaci, tj. zajištění oprávnění ke zdrojům. Na toto nesmíme zapomenout při vytváření naší aplikace.

Co se týká vestavěné podpory v .NET Frameworku, tak ta obsahuje pouze dvě implementaci membership provideru a to Active directory a SqlMembership provider. Nesmíme ovšem zapomenout na to, že pro to, abychom mohli založit a spravovat uživatele, stejně jako dovolit uživatelům se přihlásit k naší aplikaci potřebujeme nějaké vizuální prvky, a těch máme k dispozici hned několik.

Uživatelské prvky využívající membership provider

• Login
- poskytuje základní prvky pro přihlášení uživatele, jako je uživatelské jméno a heslo, plus můžeme přidat zaškrtávací pole pro zapamatování (trvalé přihlášení) si uživatele
• LoginView
- představuje jednoduchý prvek, který má dva stavy, které zobrazuje na základě toho, zda je uživatel přihlášen, nebo naší aplikaci používá anonymní uživatel
• LoginStatus
- zobrazuje stav, ve kterém je uživatel a nabízí dvě možnosti, přihlásit nebo odhlásit
• LoginName
- zobrazuje jméno přihlášeného uživatele
• PasswordRecovery
- je prvek, který umožňuje uživateli zaslat, nebo spíše vygenerovat a odeslat na email nové heslo pro přístup do aplikace
• CreateUserWizard
- je komplexnější prvek, který umožní založení nového uživatele. Samozřejmě si tento prvek můžete přizpůsobit aby odpovídal vzhledu vaší aplikace
• ChangePassword
- umožňuje uživateli změnit si heslo.

Velice zajímavý prvek je CreateUserWizard, který umožňuje založit nového uživatele pro naši aplikaci. Tento prvek může být velice snadno upravitelný a můžeme jej rozšířit o další možnosti. Za tímto účelem můžeme definovat tento prvek jako průvodce vytvořením uživatelského účtu a přidat si kroky, kterými musí uživatel projít předtím, než jeho účet bude vytvořen. Zbývá nám ovšem ještě základní pohled na kterém je zobrazeno několik vstupních textových polí, pro které nenajdeme vlastnosti, jak je skrýt nebo jakkoli jinak nastavit. To nás ovšem nesmí zmást, protože několik vlastností je součástí Membership provideru a některé implementace nemusí mít dané vlastnosti funkční. Proto není možné je nastavovat na kontrolu, ale jejich nastavení se přebírá z právě aktivního provideru. Patří mezi ně vlastnosti requiresQuestionAndAnswer, minRequiredPasswordLength, minRequiredNonalphanumericCharacters nebo passwordStrengthRegularExpression. Obzvláště si dejte pozor na dvě prostřední, které mohou uživateli z(ne)příjemnit jeho přihlašování.

Určitě nastanou také situace, kdy budeme chtít vědět o uživateli více než jen jeho uživatelské jméno, a tak nás bude zajímat třída MembershipUser. Jakmile dostaneme data pomocí providera, např. pomocí statické metody Membership.GetUser(string userName), můžeme tyto informace zobrazit, nebo s nimi jinak naložit v naší aplikaci.

Web Site Administration Tool

Bez velké námahy můžeme vložením několika prvků na stránku zajistit celkem komplexní funkcionalitu správy uživatelů, ovšem co v situaci, kdy jsme administrátorem a potřebujeme nastavovat nejen uživatele, ale i jejich přiřazování do rolí a vlastně nejen do rolí, ale i správu dalších vlastností, které je možné konfigurovat? Teď si jistě říkáte, ale co s tím, teď jsme založili uživatele, role mě zatím nezajímají a o ostatních nastaveních, to není předmět tohoto webu. Ale přeci jen, Web site administration tool je mocným nástrojem, který nám umožní nastavit vše potřebné na jednom místě a to ať už se jedná o správu uživatelů, správu rolí a přístup k jednotlivým složkám webu, konfigurační hodnoty AppSettings, nastavení použitých providerů nebo nastavení SMTP serveru. Stejně tak jako nám dovolí nastavit trasování aplikace a chybové stránky nebo uvést aplikaci do stavu OffLine.

Jak je z popisu poznat, tento nástroj dává k dispozici komplexní nastavení aplikace a Vám nezbývá nic jiného, než k němu přistoupit a začít konfigurovat a hrát si s nastavením.

Co dodat

Uživatele umíme založit aniž bychom napsali řádek kódu, dokážeme uživateli nabídnout přihlašovací dialog a zobrazit mu jeho status, zda je přihlášen, nebo se může odhlásit. Ale metod, které můžeme použít se statickou třídou Membership je více a asi nemá význam, je zde po jedné rozebírat. Pokud budete chtít vědět více, určitě napiště do komentáře.

Jedny z mála řádků, které budeme muset dopsat do našeho kódu, jsou řádky pro autentikaci uživatele a jeho přihlášení pomocí Login prvku. A kolik je těch řádků? Samozřejmě co nejmíň, musíme se přeci soustředit na jiné věci, které má naše aplikace splňovat a ne si hrát s nastavováním uživatelů. Takže, tady jsou ty potřebné řádky (login představuje Login kontrol):

if (Membership.ValidateUser(login.UserName, login.Password))
			FormsAuthentication.RedirectFromLoginPage(login.UserName, login.RememberMeSet);

Konkrétní příklad - web event

Jak už jsem naznačil v minulém článku, v tomto pokračování se budu věnovat konkrétnímu příkladu, který by měl objasnit použití a možnosti, které nám přináší healt monitoring.

Určitě i Vás, případně Vaše klienty, zajímají odpovědi na otázky, jak je využívána aplikace, nejsou na ní prováděny neoprávněné operace, a jistě spousta dalších, které by zaplnily velkou část tohoto příspěvku. Sám jsem byl ovšem velice zvědavý na to, jakým způsobem je tato aplikace využívána a jakým způsobem se po ní pohybujete. Stejně tak jistě i Váš klient tyto informace ocení.

Tvorba WebRequestAdvEvent

Pro sledování Vašeho pohybu na těchto stránkách jsem původně chtěl využít již vestavěný WebRequestEvent. Ovšem zde jsem narazil, a to hnedka na dvě nepříjemné věci. Jedna mě zamrzela poměrně hodně, ta druhá o něco méně, protože jsem věděl, jak jí odstranit. Pravda, nakonec jsem tím odstranil obě, ale budu rád, když mi zanecháte Vaše zkušenosti, a případně postup jak jste odstranili první vadu.

WebRequestEvent

Nejdříve jsem si myslel, že použiju tuto třídu ke sledování pohybu na stránkách, ovšem již při testování jsem narazil. Přestože jsem vše nakonfiguroval, a troufám si tvrdit že správně, události této třídy se ne a ne logovat. Prošel jsem několik možných konfigurací, ale ani s jednou se mi nepovedlo úspěšně zalogovat jedinou událost, pomocí mého oblíbeného vyhledávače jsem se snažil o tomto problému najít více informací, ale ani tady jsem příliš neuspěl. Jediné co jsem zjistil, že už v Beta 1 byl tento problém, bohužel bez odpovědi. Tudíž logování informací z této třídy odpadlo, ono stejně bych tento přístup zavrhl, protože informace, které obsahuje a shromažďuje, ne úplně odpovídali tomu, co jsem chtěl sledovat já navíc.

Vlastní trída poděděná z WebRequestEvent

Po zjištění výše uvedeného jsem se rozhodl implementovat vlastní třídu, která bude rozšiřovat shromažďované informace a navíc půjde logovat. Tudíž jsem vytvořil vlastní třídu a přepsal jsem metodu public override void FormatCustomEventDetails(WebEventFormatter formatter). Do této metody jsem doplnil následující část kódu, která zjišťuje informace o prohlížeči, který uživatel použil a také, ze které stránky se na ty mé dostal.

System.Web.HttpContext ctx = System.Web.HttpContext.Current;
formatter.IndentationLevel++;
if (ctx != null) {
	formatter.AppendLine(string.Format("User agent : {0}", ctx.Request.UserAgent));
	if (!string.IsNullOrEmpty(ctx.Request.UrlReferrer))
		formatter.AppendLine(string.Format("Referrer : {0}", ctx.Request.UrlReferrer.ToString()));
} else {
	formatter.AppendLine("You use this web event outside of web application. No data are provided.");
}
formatter.IndentationLevel--;

Zde si dovolím upozornit, že všechny uživatelské události, by měli mít hodnotu eventCode větší než WebEventCodes.WebExtendedBase

Měl jsem vytvořenou vlastní třídu pro sledování událostí, teď jí ještě umístit na správné místo ve stránkách a nastavit konfigurační soubor. A měl jsem hotovo, stačilo pár řádků kódu a vím o Vás všechno :-).

Používáme WebRequestAdvEvent

Proto, abych mohl použít logování vlastních událostí, musí se tyto události někde generovat. Tato aplikace využívá možností MasterPage, takže umístění vyvolání události bylo snadné, přímo do metody Page_Load a to následovně.

WebRequestAdvEvent evt = new WebRequestAdvEvent(this);
evt.Raise();

Události se nám vyvolávají a jediné co zbývalo, je nastavit jejich logování pomocí konfiguračního souboru. Není přeci nic snažšího, protože z první a druhé části víme, jak na to.

Zhodnocení místo závěru

Osobně si myslím, že používání událostí tímto způsobem je poměrně užitečná věc, která nám ušetří něco málo práce. Jen bych měl několik poznámek ke způsobu, jakým dochází k zápisu informací. V době, kdy je prosazován formát xml, by aspoň mohl existovat přepínač, který by umožnil rozšířené hodnoty logovat do tohoto formátu. Přeci jen mít data nestrukturovaná znamená jejich horší zpracování. Rozumím, že při použití některých providerů, není tento formát úplně optimální, ale přeci jen, jedná se převážně o systémové informace, které uvidí zkušení uživatelé a ti si s XML už ví rady.

A nakonec prosba na Vás, pokud víte, jak zprovoznit logování událostí pocházejících ze třídy WebRequestEvent, budu rád, když napíšete své postřehy do komentářů. Díky

Tím vše nekončí - healthMonitoring ve web.config

Pokud si vezmeme ostatní providery, většinou tímto krokem končíme a jediné co musíme udělat, je korektně nastavit konfigurační soubor. Toto však až tak neplatí pro web events, i když vše je relativní a toho nastavování budeme moci provést o něco více, než v případě registrování ostatních provider patternů.

V konfiguračním souboru tak pod elementem nedefinujeme pouze podsekci providers, ale také říkáme, které události chceme sledovat, jakým způsobem budou sledovány, jaká pro ně existují pravidla a jak se seskupují, případně jaký chceme používat způsob cachování (bufferu). Jednotlivé sekce zkusím popsat

bufferModes

V této sekci definujeme možnosti bufferingu zvoleného providera, který zachytává a dále publikuje události. Nastavovat tímto způsobem můžeme providery, které jsou odvozeny od BufferedWebEventProvider. Tím, že zabezpečíme buffering, zvýšíme tak výkonnost naší aplikace, neboť nebudeme zapisovat okamžitě vzniklé události, ale tyto budou pozdrženy před jejich zápisem pomocí příslušného provideru, zároveň můžeme rozlišit mezi kritickými (urgentními) a standardními událostmi.

Ukázka

profiles

Přidáním této podsekce máme možnost ovlivnit profil zaznamenávání událostí. Nastavením vlastností tohoto profilu určíme, jaký je minimální počet instancí události, po kterých se má tato zalogovat, případně také její maximální počet (nic nám nebrání nastavit hodnotu Infinite), jakož i minimální časový interval mezi dvěma shodnými událostmi, které se mají logovat. Těchto profilů využijeme v okamžiku, kdy se dostáváme do kritických situací a potřebujeme kontrolovat počet zapisovaných dat a zátěž na systém.

Ukázka jaké je výchozí nastavení pro sekci profiles:

eventMappings

Předpokládám, že tato sekce nás bude zajímat více než ostatní, zejména v okamžiku, kdy budeme tvořit vlastní události. V této sekci můžeme přidávat vlastní seskupování událostí, nebo přidávat vlastní události do již předpřipravených skupin. Tyto připravené skupiny jsou dvě All Events a All Audits, které se pak ještě rozpadají na <All Errors a All Failure. Nic nám ovšem nebrání v tom, abychom si definovali vlastní skupiny a tyto skupiny si nechali zpracovávat vlastním providerem.

Ukázka se zařazením vlastní události do nové skupiny My Errors

rules

Poslední z podsekcí, kterými můžeme nastovovat chování a zpracovávání událostí. Pomocí tohoto nastavení definujeme a vlastně tak seskupíme všechny výše naspecifikované hodnoty. Zapsáním pravidel tak říkáme, jakým providerem budou zpracovány jaké události a jakým způsobem profilem se tak bude dít.

Ani pro poslední podsekci nesmí chybět ukázka. Kdy si pro naši fiktivní událost definovanou v eventMapping zvolíme jeden ze standardních providerů a nastavíme jí critický profil.

Shrnutí konfigurace

Jak je vidět, můžeme díky konfiguraci sledovat a nastavovat nepřeberné množství vlastností a ovlivňovat tak způsob, kterým budeme sledovat naši aplikaci. Pokud nám stačí sledovat pouze frameworkem generované události, postačí nám k tomu jednoduché nastavení a povolení v konfiguračním souboru. Potom se použijí výchozí hodnoty a události vyskytující se ve skupinách All Errors a Failure Audits se budou zapisovat do Event logu.

Příště si na příkladu ukážeme, jak vytvořit vlastní událost a sledovat jí pomocí vlastního provideru.

Pro dnešní příspěvek jsem si vybral jednu ze zajímavých, ale podle mého názoru, lehce opomíjených oblastí, jsou to Web events neboli také Health Monitoring. Ty slouží k monitorování webových aplikací a mohou tak pomoci administrátorům a vývojářům pomoci s výkonností aplikace a její sledování, rychlé diagnostice aplikace, ve které dochází k chybám a v neposlední řadě i sledování průběhu životního cyklu stránky.

Které všechny události můžeme sledovat

Samozřejmě že můžeme definovat i vlastní třídy, které budou sledovat události, ale aby nám vývojáři od Microsoftu ušetřili spoustu práce, máme ihned k dispozici několik tříd pro sledování událostí. Vrhneme se na jejich prozkoumání s chutí.

• WebBaseEvent - základní třída pro všechny eventy, která obsahuje povinné vlastnosti, které musí mít každý web event. Mezi tyto vlastnosti patří, kód události, detailní kód události, datum a čas vzniku události, sekvenční číslo, text událost a detaily o události.
• WebManagementEvent - je základní třídou pro události týkající se správy událostí, životního cyklu aplikace, zpracování požadavků a chyb, stejně jako auditních událostí.
• WebHeartbeatEvent - je třída pro zpracování událostí, které jsou generovány v pravidelných časových intervalech pro zachycení stavových informací aplikace.
• WebAuditEvent - základní třída pro evidování bezpečnostních událostí, používá se pro audit při zpracování autorizace, a to jak provedených tak i chybných. A nejen týkající se bezpečnosti, ale i kryptování a dalších ...
• WebRequestEvent - základní třída pro informace zpracovávající události o požadavcích [requestech].
• WebBaseErrorEvent - jak už název napovídá, jedná se o základní třídu pro všechny události týkající se chyb.

Dobrá, známe tedy třídy, které budeme moci používat, ale jakým způsobem je použít a jak to vše zakomponovat do našich stránek, aby to přineslo kýžený efekt. Po jakých informacích se nejspíše budeme dále shánět, jsou informace typu, kde se všechny ty informace budou shromažďovat, jak se k nim dostanu a co všechno budu muset dopsat. Nenapadá Vás to také? Mě ano a mám potěšující informaci, těch řádků, které se musí napsat není tolik, možná i méně něž kolik jsem jich již sepsal v tomto příspěvku. ;-) Ale zpátky od laškování k suchému konstatování.

Můžeme si vybrat hnedka z několika nabízených providerů, které zapisují informace o událostech do WMI, Event logu, posílají email používají SQL Server a další, případně si můžeme napsat vlastní úložiště ... po čem jsem viděl velký ohlas byl XmlWebEventProvider.