Hlavní rozdíly mezi službou IIS a serverem ASP.NET Development Server (C#)

Scott Mitchell

Stáhnout PDF

Při místním testování aplikace ASP.NET pravděpodobně používáte webový server pro vývoj ASP.NET. Produkční web ale s největší pravděpodobností využívá službu IIS. Existují určité rozdíly mezi tím, jak tyto webové servery zpracovávají požadavky, a tyto rozdíly mohou mít důležité důsledky. V tomto kurzu se seznámíte s některými dalšími rozdíly.

Úvod

Pokaždé, když uživatel navštíví ASP.NET aplikaci, odešle prohlížeč žádost na web. Tento požadavek přebírá software webového serveru, který koordinuje modul runtime ASP.NET, aby vygeneroval a vrátil obsah požadovaného prostředku. I nternet I nformation S ervices (IIS) je sada služeb, které poskytují běžné internetové funkce pro servery 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 používaný poskytovatelem webového hostitele k poskytování ASP.NET aplikace. Službu IIS lze použít také 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 integrovaná do sady Visual Studio. Pokud není webová aplikace nakonfigurovaná pro použití služby 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í, které soubory je potřeba nasadit , byly webové aplikace založené na systému souborů, které nebyly nakonfigurovány pro použití 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 identické. Jak jsme ale probírali 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 se zabývá klíčovými rozdíly mezi službou IIS a ASP.NET Development Serverem. Vzhledem k těmto rozdílům existují scénáře, kdy kód, který běží bezvadně 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ý zaznamená určitou zprávu do souboru na disku. Aby se tato ASP.NET stránka spustila bez chyb, 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 ke kontextu zabezpečení aktuálně přihlášeného uživatele. Pokud jste k počítači přihlášení jako správce, budou mít stránky ASP.NET, které ASP.NET Development Server obsluhuje, stejná přístupová práva jako správce. ASP.NET požadavky 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 mohl pro každého zákazníka nakonfigurovat jedinečný účet. Navíc váš poskytovatel webového hostitele pravděpodobně udělil tomuto účtu počítače omezená oprávnění. Čistým výsledkem je, že můžete mít webové stránky, které se spouští bez chyby ve vývojovém prostředí, ale generují výjimky související s autorizací při hostování v produkčním prostředí.

Aby se tento typ chyby zobrazil v akci Vytvořil(a) jsem stránku na webu Recenze knih, která na disku vytvoří soubor, který ukládá poslední datum a čas, kdy někdo zobrazil učit se ASP.NET 3,5 za 24 hodin recenze. Pokud chcete postup sledovat, otevřete ~/Tech/TYASP35.aspx stránku a do obslužné rutiny Page_Load události přidejte následující kód:

protected void  Page_Load(object sender, EventArgs e)

{

    string filePath =  Server.MapPath("~/LastTYASP35Access.txt");

    string contents =  string.Format("Last accessed on {0} by {1}",

        DateTime.Now.ToString(), Request.UserHostAddress);

    System.IO.File.WriteAllText(filePath,  contents);

}

Dále navštivte stránku s přehledem knihy Naučte se ASP.NET 3,5 za 24 hodin ve vývojovém prostředí pomocí ASP.NET Development Serveru. Za předpokladu, že jste k počítači přihlášeni 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, se recenze knihy zobrazí stejně jako předtím, ale při každé návštěvě stránky se v LastTYASP35Access.txt souboru uloží datum a čas a IP adresa uživatele. Nasměrujte prohlížeč na tento soubor; měla by se zobrazit zpráva podobná té 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é stránky s přehledem knihy Naučte se ASP.NET 3.5 za 24 hodin . V tomto okamžiku byste měli vidět stránku revize knihy jako obvykle nebo chybovou zprávu zobrazenou na obrázku 2. Někteří poskytovatelé webového hostitele udělují anonymnímu účtu počítače ASP.NET oprávnění k zápisu. V takovém případě bude stránka fungovat bez chyb. Pokud však 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á nějaký 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 oprávnění k zápisu do kořenového adresáře a pak se znovu podívejte na stránku kontroly knihy. (V případě potřeby požádejte o pomoc poskytovatele webového hostitele, jak udělit 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 čtou nebo zapisují do registru systému Windows, budou při vývoji fungovat podle očekávání, ale generují výjimky v produkčním prostředí. Při vytváření webové aplikace, která bude nasazena do sdíleného webového hostitelského prostředí, nečtěte ani nezapisujte do protokolu událostí nebo registru systému Windows. Poznamenejte si také všechny ASP.NET stránky, 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 do 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 Development Serverem je způsob, jakým zpracovávají požadavky na statický obsah. Každý požadavek, který přijde na ASP.NET Development Server, ať už pro stránku ASP.NET, obrázek nebo soubor JavaScriptu, zpracuje modul runtime ASP.NET. Ve výchozím nastavení služba IIS vyvolá modul runtime ASP.NET pouze tehdy, když přijde požadavek na ASP.NET prostředek, například ASP.NET webovou stránku, webovou službu atd. Žádosti o 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é dát pokyn, 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 v tomto kurzu.)

Modul runtime ASP.NET provede řadu kroků pro 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ů uloží web soubor cookie ověřovacího lístku do prohlížeče 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é mohou nebo nemůžou získat přístup ke konkrétní 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é pouze ověřeným uživatelům nebo uživatelům, kteří patří do určité role.

Představte si web, který podporuje uživatelské účty využívající ověřování na základě formulářů a obsahuje složku, která je pomocí autorizace adres 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 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 některý 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í uživatelé tuto složku nenavštívovali. 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 webových bezpečnostních kurzů (jak fitovat!). 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"?>
<?xml version="1.0"?>

<configuration>

    <system.web>

         <authorization>

            <deny  users="?" />

         </authorization>

     </system.web>

</configuration>

Nakonec jsem nakonfiguroval(a) webovou aplikaci tak, aby používala ověřování na základě formulářů, a to aktualizací Web.config souboru 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 některého ze souborů PDF do adresního řádku prohlížeče. 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 Development Server pro soubor. Vývojový server ASP.NET předá požadavek modulu runtime ASP.NET ke zpracování. Vzhledem k tomu, že jsme se ještě nepřihlásili a protože Web.config je složka ve PrivateDocs složce 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, o kterou se uživatel pokoušel 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 načte a vrátí soubor 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 k souboru (kliknutím zobrazíte obrázek v plné velikosti).

Ověřování Forms-Based a ověřování pomocí adresy 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. V kostce můžete službě IIS dát pokyn, aby všechny příchozí požadavky (včetně statického obsahu, jako jsou soubory PDF), vyvolala modul ověřování a autorizace modulu ASP.NET runtime. 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).

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í:

• integrace ASP.NET se službou IIS 7.0
• Použití ověřování ASP.NET fór se všemi typy obsahu ve službě IIS 7 (video)
• Webové servery ve Visual Web Developeru