Monthly Archives: August 2009

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.

Képregény a SmartScreen filterről

Még régebben futottam bele az alábbi oldalba, elég tanulságos volt. Hány embert ismertek, aki azonnal bedőlne neki és nincs olyan szoftver vagy beállítás a gépén, ami megvédené?

Egy kereső találati listában egy ígéretes linkre kattintva ezzel találtam szembe magam:

SpywareRemover_00

Hmm, ez a weboldal próbálkozik valamivel, csak éppen nem sikerül neki, talán mert nem vagyok admin a gépen, ezért kap Access is denied hibaüzenetet. Debuggolni épp nem volt kedvem, ezért nyomtam az OK-ra, amitől a weboldal őrült villódzásba kezdett:

SpywareRemover_01

Windows Security Alert, hűha, ennek aztán a fele se tréfa! 🙂 Ugyan ordít róla, hogy ez egy sima weboldal, azért kipróbáltam, hova lehet kattintani. Gyakorlatilag mindegy, hova kattint az áldozat, úton a segítség, csak az OK-ra kell kattintanunk és máris töltődik lefelé az ingyenes vírusirtó.

SpywareRemover_02

Mindössze annyi dolgunk van, hogy kattintsunk a RUN vagy OPEN gombokra, amit “nyugodtan” megtehetünk, hiszen a weboldal maga mondja, hogy a fájl digitálisan alá van írva (ez ugye fontos, ma már mindenki hallott róla) és egyébként is 100% (talán több is), hogy vírus, reklám és képprogram mentes. Akár elhisszük, akár nem (ne tegyük), csak az OK gombra lehet kattintani, hiszen modális dialógus ablakról van szó.

SpywareRemover_03

Már töltődne is lefelé, a csábítóan hangzó bonuspromooffer szervere villámgyors.

SpywareRemover_04

Annyira azért nem voltam kíváncsi, hogy a gépemre engedjem a gonoszt, ezért természetesen Cancelt nyomtam még a letöltés kezdete előtt.

SpywareRemover_05

Meg is kaptam a fejmosást, hogy ilyet nem szabad ám tenni, mert zizis marad a gépem. A változatosság kedvéért itt már van OK és Cancel gomb is, meg hozzá egy nagy kérdőjel, amit összességében úgy értelmezhetünk, hogy “Felfogtad ??”. Akár igen, akár nem, azt azért nem árt tudnunk, hogy akár a registry vagy a fájl rendszerünk is tönkremehet, ami persze a világvégét jelentheti.

SpywareRemover_06

Na még egyszer, hátha nem értetted:

SpywareRemover_07

És hogy tudd, mekkora bajban vagy, a “Windows” máris ordít, hogy fertőzött a géped. Szép lassan végig is szkennel mindent, villognak a mappák, a fájlok, és csak úgy dől a lista a gépünkön tomboló gonosz fenyegetésekről:

SpywareRemover_08

Van belőlük összesen 527, méghozzá scrollozható listában! Az nem kevés ám, így aztán megint felajánlja a “jóságos” weboldal, hogy ad nekünk ingyenes csodapapit, amire azonnal szükségünk van, még mielőtt megsérülnének a fájljaink!

SpywareRemover_09

Ekkor próbáltam végig, hogy hova lehet kattintani az oldalon. Amikor épp nincs fent egy modális dialógus ablak, akkor lelkesen “szkenneli” a gépet és micsoda meglepetés, tonnányi fertőzött és fertőző fájlt talál. Ilyenkor lehet kattintgatni az oldalon, minden link és menüpont “működik”, vagy közvetlenül a fájl letöltésre vezet, vagy ide.

SpywareRemover_10

És ha még itt sem akarjuk letölteni az ingyenes programot, akkor elvisznek a krampuszok:

SpywareRemover_11

Ekkor fogyott el az aznapra rendelt játékidőm és kíméletlenül benyomtam a böngésző Smart Screen filterét, ami egy csapásra megoldotta a modális dialógusablakok és lelőhetetlen JavaScript ciklusok problémáját.

SpywareRemover_12

Közben végig azon gondolkodtam, hogy vajon az ismerőseim közül hányan dőlnének be ennek az amúgy igen profin elkészített oldalnak miközben rendszergazdai jogosultságokkal szaladgálnak a neten.

SEO szerszámosláda

Épp újratelepítem a gépemet – természetesen Windows 7-tel – és megint vadászhatom össze a kedvenc Firefox bővítményeimet.

SEO-Firebug Firebug

Letöltés. Remélem senkinek nem kell bemutatni, kötelező darab annak ellenére, hogy az IE8 már beépítetten tartalmaz hasonlót (Developer Tools). HTML és CSS környékén hasonló a tudásuk, Firebugban azonban sokkal jobban tudom monitorozni a hálózati forgalmat, az időket és a HTTP fejléceket.

A FF 3.5-ben megjelent Automatically start Firefox in a private browsing session opciót nem szabad bekapcsolni, mert akkor a Firebug minden oldalletöltéskor eltűnik és nem mutatja a forgalmat. Szóval döntsük el, hogy éppen pornót nézünk vagy forgalmat elemzünk 🙂

Google Page SpeedGoogle Page Speed

Letöltés.  Ez az egyik új kedvencem, a Firebugba épül be és bár kicsit lassú és gyakran kell újrafuttatni, hasznos tanácsokat ad a keresőoptimalizáláshoz. A kliens oldali cache konfigurálásához nagyon hasznos, add tippeket a képek, a CSS és a JavaScript optimalizálásához is, sőt azonnal fel is ajánlja ezeknek az erőforrásoknak az optimalizálását. Jól használható önmagában a doksija is, tömör és lényegre törő.

Tud timeline-t is, amiben a Firebugnál részletesebb bontásban jelenik meg, hogy a böngésző éppen mivel vacakolt.

SEO-SenSEO SenSEO

Letöltés. A változatosság kedvéért ez is a Firebugot bővíti ki méghozzá oly módon, hogy miután letöltöttünk egy oldalt, megmondja, hogy mit lát belőle egy keresőmotor, sőt megadhatunk neki egy kereső kifejezést, amire ő megmondja, hogy az oldal egyes részei (title, meta description stb.) mennyire felel meg neki.

Elemzi az oldal HTML kódját, azon belül nem csak a fejlécet, de a címsorokat is, továbbá a domaint és a path-t, az eredményt pedig egy színes-szagos HTML oldal formájában képes exportálni.

Live HTTP Headers Live HTTP Headers

Letöltés. Firebugtól független Firefox bővítmény, amely megmutatja a teljes HTTP forgalmat. Azt szeretem benne, hogy egy külön ablakban folyamatosan naplóz, így kiválóan látszanak az átirányítások.

Másik kedvencem benne a Replay funkció, amivel újrajátszhatom a kérést, természetesen előtte tetszőlegesen módosítva a HTTP fejléceket.

SEO-Tamper_Data Tamper Data

Letöltés. Ez a kis addon azt teszi lehetővé, hogy még az előtt belenyúljunk a HTTP kérésbe, hogy a böngésző elküldené azt a szerverre. További hasznos funkciója, hogy beépítetten tartalmaz egy rakás biztonság tesztelő funkciót, SQL injection, cross-site scripting és számok tesztelésére.

IIS 7 Search Engine Optimization Toolkit

Letöltés. Na ez kivételesen nem a Firefoxba, hanem az IIS 7-be beépülő egyik legújabb bővítmény, ami gyakorlatilag ugyanúgy végigjárja a webhelyünket, mint ahogy egy robot tenné, majd egy jelentésben összefoglalja, hogy mit kellene javítanunk: hol vannak törött linkek, hol hiányzik egy title vagy egy meta description, hol nem releváns egy hivatkozás szövege, melyek azok az oldalak, amelyekre több helyről máshogyan hivatkozunk stb.

Egyebek

Visual Round Trip Analyzer (VRTA)

Letöltés. Ez igencsak low-level elemzésre használatos jószág, a Netmonnal együttműködve mondja meg, hogy mi történik a hálózaton, miközben a böngésző előtt csak bambán vár a felhasználó. Kereső optimalizálásra nem jó, de a hálózati bottleneckek kiderítésére igen, ráadásul van benne néhány szabály is, ami alapján osztályozza a webhelyünk teljesítményét.

Fiddler

Letöltés. Ő sem igazán SEO elemző, inkább a nyers hálózati forgalmat célszerű vele nézegetni. Írtunk már róla korábban, Dávid Zoli egy hekkelős bevezető cikket, én pedig a JSON és a localhost használatáról.

FireShot

Letöltés. Ez a ráadás, ami leginkább kilóg a sorból: képernyőfotók készítésére jó, tökéletesen kezeli a képernyőből kilógó nagy méretű oldalakat is. Tavaly írtam egy Webpage Capture nevű programot, ami ugyanezt csinálja IE alatt, akkor kaptam a tippet, hogy érdemes kipróbálni a FireShotot.

 

Ti mit használtok még?

ASP.NET for Mobiles

Tapasztalatom szerint kevesen használják és még kevesebben tudják, hogy ASP.NET platformon nem csak asztali, hanem mobil böngészőkre is lehet webalkalmazást fejleszteni.

A rendszer alapja, hogy az ASP.NET rendelkezik egy olyan adatbázissal, ami tartalmazza a mobil eszközök képességeit, ami persze csak akkor működik jól, ha az új eszközök megjelenésével ez az adatbázis is frissül. Korábban a Microsoft ún. Device Update-eket adott ki, ezekből azonban 2003. decemberi az utolsó, nem is érdemes bajlódni vele.

Az ASP.NET 2.0 megjelenése óta azonban ennek az adatbázisnak a kezelése sokkal egyszerűbb, mindössze egy .browser kiterjesztésű XML fájlt kell az App_BrowsersDevices mappába elhelyeznünk. Ilyen Mobile Device Browser File-ból itt érdemes a legfrissebbet keresnünk, ezt a projectet a Live csapat hozta létre és tartja karban: http://mdbf.codeplex.com/

A hivatalos ASP.NET for Mobiles oldalon egyébként nem sok infót találunk erről a területről, de a hírek szerint az ASP.NET 4.0-ban ez változni fog, hiszen maga a rendszer is jelentősen módosul:

  • A System.Web.Mobile.dll összes osztálya elavult, azaz obsolete lesz.
  • Drasztikusan megváltozik a fent említett browser fájl, a mobil és a desktop böngészők leírásai is frissülnek, a régiek pedig (pl. IE 6 előttiek) kikerülnek.
  • A tervek szerint a böngésző definíciók leírása provider alapú lesz, tehát valószínűleg könnyebben lesz bővíthető.
Technorati-címkék: ,