2009. augusztus havi bejegyzések

IIS 7 és a Home Editionök

Érdekes módon lehet IIS 7-et telepíteni a különböző Vista és Windows 7 Home Editionökre, csak éppen az eredmény nem mindig egy működő webkiszolgáló lesz. Ráadásul nagy különbségek vannak a Home Basic, Starter és Premium változatok között.

Teljes IIS 7 vagy 7.5 webkiszolgálót az alábbi operációs rendszereken kapunk:

  • Windows Server 2008 vagy 2008 R2
  • Windows Vista Business vagy Ultimate
  • Windows 7 Ultimate, Professional vagy Enterprise

Vista és Windows 7 Home Premium változatokon egészen használható webkiszolgálót kapunk, ami akár fejlesztésre is használható. Nem lesz FTP szerverünk, távoli adminisztráció, nem kapunk rendes hitelesítést és jogosultság ellenőrzést, továbbá a rendszer maximum 3 párhuzamos kapcsolatot fog kiszolgálni. Kicsit hiányos, kicsit púpos, de a miénk.

Nem így Vista Starter, Home és Windows 7 Home Basic és Starter Edition operációs rendszereken, ezeken ugyanis az IIS 7 mint webkiszolgáló nem támogatott. Szemfülesek észrevehetik, hogy ennek ellenére megjelenik a telepíthető operációs rendszer összetevők között, lehet telepíteni például a HTTP Errors és HTTP Redirection modulokat, de például a Default Document, Static Content és Directory Browsing modulok hiányoznak. Ergo amit kapunk eredményül, az még statikus fájlokat sem tud elküldeni egy HTTP kérésre válaszul. Na, ezért nem hívom én az ilyet webszervernek 🙂 Azért lehet mégis telepíteni ezeket a komponenseket, mert lehet olyan WCF-es alkalmazást írni, amely a Windows Process Activation Service-re (WAS) épül, amely a gyakorlatban ezeknek a komponenseknek az összefoglaló neve. Tehát nem azért “van” IIS 7 Home Basic és Starter változatokon, hogy webszerverként használjuk, hanem hogy a WCF-es alkalmazásunk boldog legyen.

Bejövő kérések szűrése IIS 7 alatt

Az IIS 6-ban az URL Scan bővítmény számos alkalmazást megcélzó buffer overrun jellegű támadás ellen nyújtott védelmet, melyek az URL-ek vagy az URL paraméterek (query string) hibás feldolgozását használták ki. Az IIS 7-ben a továbbfejlesztett, alapértelmezés szerint beépített és működő Request Filtering modul látja el ugyanezt a feladatot. Az IIS 7 Request Filtering modulja lehetővé teszi a beérkező kérésekre vonatkozóan bizonyos kényszerek meghatározását, amelyek segítségével megvédhetjük alkalmazásainkat a kérés rossz szándékú formázásával elért néhány tipikus támadási formától.

IIS 7 request filtering A Request Filtering modul segítségével az alábbiakat tudjuk beállítani:

  • A kérés méretének korlátozása: az URL, a query string, egyes fejlécek és a teljes kérés hossza, az URL-ben használható karakterek kódolása és a használható HTTP parancsok (verb).
  • Kiterjesztések korlátozása: a handler mappingtől függetlenül megadható, hogy milyen kiterjesztésű fájlokat érhetnek el a kliensek és melyeket nem.
  • Rejtett URL szegmensek: megadható, hogy mely URL szegmenseket nem lehet a kliensről elérni (pl. App_Code mappa).
  • Tiltott URL minták: megadható, hogy milyen szekvenciák nem szerepelhetnek az URL-ben.

Az IIS 7 alapértelmezett telepítésekor nem kapunk grafikus IIS Managerbeli felhasználói felületet a request filtering beállításához, a konfigurálást vagy közvetlenül a konfigurációs fájlokban vagy az appcmd.exe segítségével kell elvégeznünk.

Demó

A demóban az Administration Pack for IIS 7.0 segítségével, az IIS Managerbe épülő grafikus felületen keresztül mutatjuk be a request filtering modul szolgáltatásait.

IIS 7 kérések szűrése

Letöltés: Keresek szurese.wmv (13:52, 62.3 MB)

Első lépések

Az IIS 7 Request Filtering modullal leggyorsabban úgy ismerkedhetünk meg, ha letöltjük és telepítjük az Administration Pack for IIS 7.0 bővítményt, amely az IIS Managerbe beépülő grafikus felhasználói felületet ad a request filtering paramétereinek konfigurálásához.

Jó tudni

Amennyiben a request filtering modul valamelyik szabálya miatt meghiúsul egy kérés feldolgozása, az alábbi hibakódokkal értesíti a webkiszolgáló a klienst:

Error Status Codes
Site not found 404.1
Denied by policy 404.2
Denied by mime map 404.3
No handler 404.4
Request Filtering: URL Sequence denied 404.5
Request Filtering: Verb denied 404.6
Request Filtering: File extension denied 404.7
Request Filtering: Denied by hidden segment 404.8
Denied since hidden file attribute has been set 404.9
Request Filtering: Denied because request header is too long 404.10
Request Filtering: Denied because URL doubled escaping 404.11
Request Filtering: Denied because of high bit characters 404.12
Request Filtering: Denied because content length too large 404.13
Request Filtering: Denied because URL too long 404.14
Request Filtering: Denied because query string too long 404.15

További információk

Mi az a SharePoint?

Erre a kérdésre nem egyszerű a válasz, és lássuk be, eddig a Microsoftnak sem sikerült. Elég csak megnézni a hivatalos weboldalt, ahol a kötelező bűvszavakból (effectiveness, extensibility, interoperability, processes, information sharing, enterprise stb.) áll össze a nagy büdös semmi négy hosszú sorban. Most azonban úgy tűnik, hogy rátaláltak a CommonCraft cégre, akik arra specializálódtak, hogy egyszerűen és röviden magyarázzanak el bármit. Ezt is rövidebben mondják el, mint én: “our product is explanation”.

Ez a 3 perces videójuk többet ér, mint az összes marketing maszlag:

SharePoint in plain English SharePoint in plain English

Érdemes megnézni a többi videójukat is.

Technorati-címkék: ,,

Run as Admin egy kattintásra Windows 7-en

Bizony gyakran előfordul, hogy Windows 7-en vagy Server 2008-on valamelyik MMC-t (például az IIS Managert) rendszergazdai jogosultságokkal kellene elindítanunk. Ekkor a szokásos megoldás a körülményes jobb klikk –> Run as Administrator menüpontra kattintás, amit bármelyik parancsikonon megspórolhatunk, ha a bal egérgombos kattintás közben nyomjuk a CTRL+SHIFT párost.

Köszönet Viktornak a tippért.

Technorati-címkék: ,,

Amikor nem lehet redirectelni

Nagyon hasznos és kényelmes az AJAX használata, azt azonban egy pillanatra sem szabad elfelejteni, hogy aszinkron postback (pl. page method) esetén nincs akkora szabadságunk, mint egy sima szinkron kérés esetén. Bár bizonyos esetekben a teljes oldal életciklus lefut, még egy sima Response.Redirect sem működik.

Ha mégis megpróbáljuk, az alábbi hibaüzenetet kapjuk, sajnos csak futási időben:

Response.Redirect cannot be called in a Page callback.

A megoldás az, hogy ebben az esetben szerver oldalon lemondunk az átirányításról:

  if( !this.Page.IsCallback )
  {
    this.Response.Redirect( "MasikOldal.aspx" );
  }

Helyette kénytelenek vagyunk a böngészőnek JavaScriptet visszaküldeni, ami a window.location tulajdonság írásával kliens oldalról végzi az átirányítást.

Tudtok jobb megoldást?

Technorati-címkék: ,,

ASP.NET 4: fogyókúrán a web.config

Aki hosszabb ideje foglalkozik már az ASP.NET-tel, annak biztosan feltűnt, hogy minden verzióval jelentősen hízott a web.config. Elég csak létrehozni egy új webhelyet Visual Studioban és kapunk egy több képernyős konfig fájlt, ami ráadásul szinte minden webalkalmazásnál ugyanaz. A beállítások többségéhez többnyire hozzá sem nyúlunk (tegye fel a kezét, aki kiszedte a .vb fájlok fordítására vonatkozó beállításokat egy C# projektből), viszont nap mint nap kerülgetjük. A helyzet az IIS 7-tel csak “rosszabbodott”, hiszen Windows Server 2008-on már a webkiszolgáló beállításai is a web.configba kerülnek.

Erre a problémára úgy látszik Redmondban is felfigyeltek, mert a .NET Framework 4-től kezdve a beállítások nagy része átkerül a machine.config fájlba és az ott szereplő értékeket az egyes webalkalmazások öröklik. Ez a gyors fogyókúra alapesetben ennyire fogja redukálni a web.configot (béta 2 példa – változhat):

  <?xml version="1.0"?>
  <configuration>
    <system.web>
      <compilation targetFramework="4.0" />
    </system.web>
  </configuration>

Sőt, ha a webalkalmazásunk .NET Framework 4 application poolban fut, akkor a fenti “4.0” az alapértelmezett targetFramework érték, tehát akár üres is lehet a web.configunk.

Ami már most is működik

Van éppen egy projektünk, amiben az IIS 7 UrlRewrite modulját használjuk. Nagyon jó eszköz, azonban alapértelmezés szerint ez is a web.configba pakolja a létrehozott szabályokat, ami a mi esetünkben jelen pillanatban közel 200 sor és ez a szám gyors ütemben növekszik. Ezért azt a megoldást választottuk, hogy a szabályokat kitettük külön .config fájlba a configSource attribútum használatával. A web.configban a modul által használt rewrite szekcióból ez maradt:

  <rewrite>
    <rules configSource="web_rewrite_rules.config" />
  </rewrite>

A web_rewrite_rules.config fájl pedig így kezdődik:

  <?xml version="1.0" encoding="UTF-8"?>
  <rules>
    <rule ...>
      ...
    </rule>
...
</rules>

Ez a módszer tökéletesen működik .NET Framework 3.5 és IIS 7.5 (Windows 7) alatt, az IIS Management Console felismeri a configSource attribútumot és a grafikus felületen végzett módosításokat a külső fájlba írja. Eddig egy mellékhatást tapasztaltunk: a hivatkozott külső fájl módosítása esetén nem indul újra automatikusan a webalkalmazás és mivel a beállítások gyorsítótárban tárolódnak, a rendszer észre sem veszi, hogy változtattunk valamin. Az már a konkrét helyzettől függ, hogy ez éppen előny vagy hátrány.

SharePoint Access Web Datasheet hiba

Egy Windows SharePoint Services webhely egyik adatlap nézetben megjelenő listája a minap az alábbi hibaüzenettel üdvözölt:

“The Access Web Datasheet is attempting to retrieve data from a different domain. You will be redirected to an error page. Contact your system administrator to resolve this error.”

A legszebb az egészben, hogy mindez csak akkor jelent meg, amikor a listát a http://intranet címen keresztül értem el, amikor FQDN-en keresztül, akkor működött simán. Ezek után nem lepődtem meg, hogy a guglizás eredménye az lett, hogy nézzek körül az Alternate Access Mappings beállításoknál.

A megoldás azonban lényegesen egyszerűbb volt: elfogyott a szabad hely a C: meghajtón. Kiderült, hogy a bűnös maga a WSS volt, a keresőmotor elindított egy teljes újraindexelést és közben telehányta a naplót a C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions12LOGS mappában. Magasabbra vettem a naplózási küszöböt a Központi Felügyelet oldalon, kitöröltem a LOGS mappa tartalmát és azóta megint szépen forog a gép.

Hogy ennek mi köze a fenti hibaüzenethez? Szerintem semmi. Contact your developer to fix this error message.