Hlavní rozdíly mezi službou IIS a serverem ASP.NET Development Server (VB)
Při místním testování aplikace ASP.NET je pravděpodobné, že používáte webový server ASP.NET Development Web Server. Produkční web je však s největší pravděpodobností spuštěnou službou IIS. Mezi tím, jak tyto webové servery zpracovávají požadavky, existují určité rozdíly a tyto rozdíly můžou mít důležité důsledky. Tento kurz prozkoumá některé z dalších německých rozdílů.
Úvod
Pokaždé, když uživatel navštíví aplikaci ASP.NET, odešle prohlížeč žádost na web. Tento požadavek přebírá software webového serveru, který koordinuje s modulem runtime ASP.NET, aby vygeneroval a vrátil obsah požadovaného prostředku. Služba I nternet I nformation S ervices (IIS) je sada služeb, které poskytují společné internetové funkce pro servery s Windows. SLUŽBA IIS je nejčastěji používaný webový server pro ASP.NET aplikace v produkčních prostředích. s největší pravděpodobností se jedná o software webového serveru, který váš poskytovatel webového hostitele používá k poskytování ASP.NET aplikace. Službu IIS lze také použít jako software webového serveru ve vývojovém prostředí, i když to zahrnuje instalaci a správnou konfiguraci služby IIS.
ASP.NET Development Server je alternativní možnost webového serveru pro vývojové prostředí. Dodává se se sadou Visual Studio a je integrován do sady Visual Studio. Pokud není webová aplikace nakonfigurovaná tak, aby používala službu IIS, ASP.NET Development Server se automaticky spustí a použije jako webový server při první návštěvě webové stránky v sadě Visual Studio. Ukázkové webové aplikace, které jsme vytvořili v kurzu Určení, jaké soubory je potřeba nasadit , byly obě webové aplikace založené na systému souborů, které nebyly nakonfigurované pro používání služby IIS. Proto se při návštěvě některého z těchto webů v sadě Visual Studio používá ASP.NET Development Server.
V dokonalém světě by vývojové a produkční prostředí bylo stejné. Jak jsme ale probrali v předchozím kurzu, není neobvyklé, že prostředí mají různá nastavení konfigurace. Použití jiného softwaru webového serveru v prostředí přidá další proměnnou, kterou je potřeba vzít v úvahu při nasazování aplikace. Tento kurz popisuje klíčové rozdíly mezi službou IIS a ASP.NET Development Serverem. Vzhledem k těmto rozdílům existují scénáře, ve kterých kód, který běží bezchybně ve vývojovém prostředí, vyvolá výjimku nebo se při spuštění v produkčním prostředí chová odlišně.
Rozdíly v kontextu zabezpečení
Kdykoli software webového serveru zpracuje příchozí požadavek, přidruží tento požadavek ke konkrétnímu kontextu zabezpečení. Tyto informace o kontextu zabezpečení používá operační systém k určení akcí, které jsou pro požadavek přípustné. Stránka ASP.NET může například obsahovat kód, který protokoluje určitou zprávu do souboru na disku. Aby se tato stránka ASP.NET spustila bez chyby, kontext zabezpečení musí mít příslušná oprávnění na úrovni systému souborů, konkrétně oprávnění k zápisu do tohoto souboru.
ASP.NET Development Server přidruží příchozí požadavky k kontextu zabezpečení aktuálně přihlášeného uživatele. Pokud jste přihlášeni k počítači jako správce, budou mít ASP.NET stránky, které ASP.NET Development Server obsluhuje, stejná přístupová práva jako správce. ASP.NET žádosti zpracovávané službou IIS jsou však přidruženy ke konkrétnímu účtu počítače. Ve výchozím nastavení se účet počítače síťové služby používá ve službě IIS verze 6 a 7, i když váš poskytovatel webového hostitele možná pro každého zákazníka nakonfiguroval jedinečný účet. A co víc, váš poskytovatel webového hostitele pravděpodobně udělil tomuto účtu počítače omezená oprávnění. Výsledkem je, že můžete mít webové stránky, které se spouští bez chyby ve vývojovém prostředí, ale při hostování v produkčním prostředí generují výjimky související s autorizací.
Chcete-li zobrazit tento typ chyby v akci Vytvořil(a) jsem stránku na webu Recenze knih, která vytvoří soubor na disku, který ukládá poslední datum a čas, který někdo zobrazil ASP.NET 3,5 za 24 hodin recenzi. Pokud chcete pokračovat, otevřete ~/Tech/TYASP35.aspx stránku a do obslužné rutiny Page_Load události přidejte následující kód:
Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
Dim filePath As String = Server.MapPath("~/LastTYASP35Access.txt")
Dim contents As String = String.Format("Last accessed on {0} by {1}", _
DateTime.Now.ToString(), Request.UserHostAddress)
System.IO.File.WriteAllText(filePath, contents)
End Sub
Poznámka
MetodaFile.WriteAllText vytvoří nový soubor, pokud neexistuje, a pak do něj zapíše zadaný obsah. Pokud soubor již existuje, je jeho stávající obsah přepsán.
Dále navštivte stránku s přehledem knihy 3,5 ASP.NET 3,5 za 24 hodin ve vývojovém prostředí pomocí ASP.NET Development Serveru. Za předpokladu, že jste přihlášeni k počítači pomocí účtu, který má odpovídající oprávnění k vytvoření a úpravě textového souboru v kořenovém adresáři webové aplikace, bude kontrola knihy vypadat stejně jako předtím, ale při každé návštěvě stránky se datum a čas a IP adresa uživatele uloží do LastTYASP35Access.txt souboru. Nasměrujte prohlížeč na tento soubor. měla by se zobrazit zpráva podobná té, která je zobrazená na obrázku 1.
Obrázek 1: Textový soubor obsahuje datum a čas poslední návštěvy recenze knihy (kliknutím zobrazíte obrázek v plné velikosti)
Nasaďte webovou aplikaci do produkčního prostředí a pak navštivte hostovaný ASP.NET 3.5 ve 24hodinovém prostředí. V tomto okamžiku byste měli buď vidět stránku revize knihy jako obvykle, nebo chybovou zprávu zobrazenou na obrázku 2. Někteří poskytovatelé webových hostitelů udělují anonymnímu účtu ASP.NET počítače oprávnění k zápisu. V takovém případě bude stránka fungovat bez chyby. Pokud však váš poskytovatel webového hostitele zakáže přístup k zápisu pro anonymní účet, UnauthorizedAccessException při pokusu TYASP35.aspx stránky o zápis aktuálního data a času do souboru dojde k výjimceLastTYASP35Access.txt.
Obrázek 2: Výchozí účet počítače používaný službou IIS nemá oprávnění k zápisu do systému souborů (kliknutím zobrazíte obrázek v plné velikosti)
Dobrou zprávou je, že většina poskytovatelů webových hostitelů má určitý druh nástroje pro oprávnění, který umožňuje určit oprávnění systému souborů na vašem webu. Udělte anonymnímu účtu ASP.NET přístup k zápisu do kořenového adresáře a pak znovu přejděte na stránku revize knihy. (V případě potřeby požádejte poskytovatele webového hostitele o pomoc s udělením oprávnění k zápisu výchozímu účtu ASP.NET.) Tentokrát by se stránka měla načíst bez chyby a LastTYASP35Access.txt soubor by se měl úspěšně vytvořit.
Protože ASP.NET Vývojový server funguje v jiném kontextu zabezpečení než služba IIS, je možné, že vaše ASP.NET stránky, které čtou nebo zapisují do systému souborů, čtou z protokolu událostí Systému Windows nebo do něj zapisují nebo čtou nebo zapisují do registru systému Windows, budou při vývoji fungovat podle očekávání, ale v produkčním prostředí generují výjimky. Při vytváření webové aplikace, která bude nasazena do sdíleného hostitelského prostředí webu, nečtěte protokol událostí ani do registru Systému Windows ani do ho nezapisujte. Všimněte si také všech ASP.NET stránek, které čtou ze systému souborů nebo do systému souborů zapisuje, protože možná budete muset udělit oprávnění ke čtení a zápisu u příslušných složek v produkčním prostředí.
Rozdíly při poskytování statického obsahu
Dalším základním rozdílem mezi službou IIS a ASP.NET Vývojový server je způsob zpracování požadavků na statický obsah. Každý požadavek, který přijde na ASP.NET Development Server, ať už se jedná o stránku ASP.NET, image nebo soubor JavaScriptu, zpracovává modul runtime ASP.NET. Ve výchozím nastavení služba IIS vyvolá modul runtime ASP.NET pouze v případě, že přijde požadavek na ASP.NET prostředek, například webovou stránku ASP.NET, webovou službu atd. Požadavky na statický obsah – obrázky, soubory CSS, soubory JavaScriptu, soubory PDF, soubory ZIP a podobně – načítá služba IIS bez zásahu modulu runtime ASP.NET. (Službu IIS je možné instruovat, aby při poskytování statického obsahu pracovala s modulem runtime ASP.NET. Další informace najdete v části Provádění ověřování Forms-Based a ověřování pomocí adresy URL u statických souborů se službou IIS 7.)
Modul runtime ASP.NET provede řadu kroků k vygenerování požadovaného obsahu, včetně ověřování (identifikace žadatele) a autorizace (určení, jestli má žadatel oprávnění k zobrazení požadovaného obsahu). Oblíbenou formou ověřování je ověřování na základě formulářů, při kterém je uživatel identifikován zadáním svých přihlašovacích údajů – obvykle uživatelského jména a hesla – do textových polí na webové stránce. Po ověření přihlašovacích údajů ukládá web soubor cookie ověřovacího lístku v prohlížeči uživatele, který se odesílá s každým dalším požadavkem na web a slouží k ověření uživatele. Kromě toho je možné zadat autorizační pravidla adresy URL , která určují, co uživatelé můžou nebo nemůžou získat přístup k určité složce. Mnoho ASP.NET webů používá ověřování na základě formulářů a autorizaci adres URL k podpoře uživatelských účtů a k definování částí webu, které jsou přístupné jenom ověřeným uživatelům nebo uživatelům, kteří patří do určité role.
Poznámka
Pro důkladné prozkoumání ASP. Ověřování na základě formulářů, autorizace adres URL a další funkce související s uživatelskými účty, nezapomeňte si prohlédnout moje kurzy zabezpečení webu.
Představte si web, který podporuje uživatelské účty využívající autorizaci na základě formulářů a obsahuje složku, která je pomocí autorizace url nakonfigurovaná tak, aby povolovala jenom ověřené uživatele. Představte si, že tato složka obsahuje ASP.NET stránky a soubory PDF a že záměrem je, aby tyto soubory PDF mohli zobrazit jenom ověření uživatelé.
Co se stane, když se návštěvník pokusí zobrazit jeden z těchto souborů PDF zadáním adresy URL přímo do adresního řádku prohlížeče? Abychom to zjistili, vytvoříme novou složku na webu Recenze knih, přidáme nějaké soubory PDF a nakonfigurujeme web tak, aby používal autorizaci adresy URL, aby anonymním uživatelům zakázali navštěvovat tuto složku. Pokud si stáhnete ukázkovou aplikaci, uvidíte, že jsem vytvořil složku s názvem PrivateDocs a přidal PDF z mých kurzů o zabezpečení webových stránek (jak fit!). Složka PrivateDocs obsahuje Web.config také soubor, který určuje autorizační pravidla adresy URL pro odepření anonymních uživatelů:
<?xml version="1.0"?>
<configuration>
<system.web>
<authorization>
<deny users="?" />
</authorization>
</system.web>
</configuration>
Nakonec jsem webovou aplikaci nakonfiguroval tak, aby používala ověřování na základě formulářů, a to aktualizací souboru Web.config v kořenovém adresáři a nahrazením:
<authentication mode="Windows" />
Tímto:
<authentication mode="Forms" />
Pomocí vývojového serveru ASP.NET navštivte web a zadejte přímou adresu URL jednoho ze souborů PDF na panelu Adresa v prohlížeči. Pokud jste si stáhli web přidružený k tomuto kurzu, měla by adresa URL vypadat nějak takto: http://localhost:portNumber/PrivateDocs/aspnet_tutorial01_Basics_vb.pdf
Zadání této adresy URL do panelu Adresa způsobí, že prohlížeč odešle požadavek na ASP.NET Vývojový server pro soubor. Vývojový server ASP.NET předá žádost modulu runtime ASP.NET ke zpracování. Vzhledem k tomu, že jsme se ještě nepřihlásili a protože Web.config složka ve PrivateDocs složce je nakonfigurovaná tak, aby odepřela anonymní přístup, modul runtime ASP.NET nás automaticky přesměruje na přihlašovací stránku Login.aspx (viz obrázek 3). Při přesměrování uživatele na přihlašovací stránku ASP.NET obsahuje ReturnUrl parametr řetězce dotazu, který označuje stránku, kterou se uživatel pokouší zobrazit. Po úspěšném přihlášení se uživatel může vrátit na tuto stránku.
Obrázek 3: Neautorizovaní uživatelé jsou automaticky přesměrováni na přihlašovací stránku (kliknutím zobrazíte obrázek v plné velikosti)
Teď se podíváme, jak se to chová v produkčním prostředí. Nasaďte aplikaci a zadejte přímou adresu URL do jednoho ze souborů PDF ve složce v produkčním PrivateDocs prostředí. Tím se v prohlížeči zobrazí výzva k odeslání požadavku služby IIS pro soubor. Vzhledem k tomu, že je požadován statický soubor, služba IIS soubor načte a vrátí bez vyvolání modulu runtime ASP.NET. V důsledku toho nebyla provedena žádná kontrola autorizace adresy URL; obsah domnělého soukromého SOUBORU PDF je přístupný každému, kdo zná přímou adresu URL souboru.
Obrázek 4: Anonymní uživatelé si můžou stáhnout soukromé soubory PDF zadáním přímé adresy URL souboru (kliknutím zobrazíte obrázek v plné velikosti)
Ověřování Forms-Based a ověřování url u statických souborů se službou IIS 7
Existuje několik technik, které můžete použít k ochraně statického obsahu před neoprávněnými uživateli. Služba IIS 7 zavedla integrovaný kanál, který snoubí pracovní postup služby IIS s pracovním postupem modulu runtime ASP.NET. Stručně řečeno, můžete dát službě IIS pokyn, aby vyvolala moduly ověřování a autorizace modulu runtime ASP.NET všechny příchozí požadavky (včetně statického obsahu, jako jsou soubory PDF). Pokud chcete zjistit, jak nakonfigurovat web tak, aby používal integrovaný kanál, obraťte se na svého poskytovatele webového hostitele.
Jakmile je služba IIS nakonfigurovaná tak, aby používala integrovaný kanál, přidejte do Web.config souboru v kořenovém adresáři následující kód:
<system.webServer>
<modules>
<add name="FormsAuthenticationModule" type="System.Web.Security.FormsAuthenticationModule" />
<remove name="UrlAuthorization" />
<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" />
<remove name="DefaultAuthentication" />
<add name="DefaultAuthentication" type="System.Web.Security.DefaultAuthenticationModule" />
</modules>
</system.webServer>
Tento kód dává službě IIS 7 pokyn, aby používala moduly ověřování a autorizace založené na ASP.NET. Znovu nasaďte aplikaci a pak znovu přejděte do souboru PDF. Když služba IIS zpracuje požadavek, tentokrát dává logiku ověřování a autorizace modulu runtime ASP.NET příležitost požadavek zkontrolovat. Vzhledem k tomu, že k zobrazení obsahu ve PrivateDocs složce mají oprávnění jenom ověření uživatelé, anonymní návštěvník se automaticky přesměruje na přihlašovací stránku (viz obrázek 3).
Poznámka
Pokud váš poskytovatel webového hostitele stále používá službu IIS 6, nemůžete použít funkci integrovaného kanálu. Jedním z alternativních řešení je umístit soukromé dokumenty do složky, která zakazuje přístup HTTP (například App_Data), a pak vytvořit stránku, která bude tyto dokumenty obsluhovat. Tato stránka může mít název GetPDF.aspxa předá se jí název SOUBORU PDF prostřednictvím parametru řetězce dotazu. Stránka GetPDF.aspx nejprve ověří, že uživatel má oprávnění k zobrazení souboru, a pokud ano, použije metodu Response.WriteFile(filePath) k odeslání obsahu požadovaného souboru PDF zpět do žádajícího klienta. Tato technika by fungovala také pro službu IIS 7, pokud nechcete povolit integrovaný kanál.
Souhrn
Webové aplikace v produkčním prostředí jsou hostovány pomocí softwaru webového serveru služby IIS společnosti Microsoft. Ve vývojovém prostředí však může být aplikace hostována pomocí služby IIS nebo ASP.NET Vývojového serveru. V ideálním případě by se měl v obou prostředích používat stejný software webového serveru, protože použití jiného softwaru přidá do kombinace další proměnnou. Snadné použití vývojového serveru ASP.NET z něj ale činí atraktivní volbu ve vývojovém prostředí. Dobrou zprávou je, že mezi službou IIS a serverem ASP.NET Development Server existuje jen několik základních rozdílů. Pokud o těchto rozdílech víte, můžete podniknout kroky, které vám pomohou zajistit, aby aplikace fungovala a fungovala stejným způsobem bez ohledu na prostředí.
Všechno nejlepší na programování!
Další čtení
Další informace o tématech probíraných v tomto kurzu najdete v následujících zdrojích informací: