Vannak lépések, amiket minden ASP.NET alapú alkalmazás élesbe állításakor meg kell tenni, és vannak amiket talán nem, de elgondolkozni rajtuk mindenképpen érdemes. Hogy ne csak ismerjük ezeket a lépéseket, de végre is hajtsuk őket, ahhoz pedig elengedhetetlen a jó memória, vagy egy ellenőrző-lista. Ez az én listám, nem fontossági sorrendben. Ha valami kimaradt, írd meg kommentben és kibővítem vele a listát:

Konfigurációs állományok

1. ha tudjuk, akkor a machine.configban lévő deployment tag retail attribútumát állítsuk true-ra
2. a web.configban a compilation tag debug attribútumát állítsuk flase-ra.
3. ha van trace tagünk, akkor azt is tiltsuk le (<trace enabled="false" />)
4. A web.configban az AspNetSqlMembershipProvider (illetve a default provider) beállításainal írjunk elő erősebb jelszót (minRequiredPasswordLength és minRequiredNonalphanumericCharacters attribútumok)
5. a rolemanager tag cacheRolesInCookie attribútumát tegyük true-ra, és a cookieProtection-t meg All-ra
6. a customErrors tag mode attribútumát állítsuk true-ra, és a defaultRedirect attribútumban adjuk meg a hibaoldalunkat
7. állítsuk be a system.web/caching/cache attribútumait attól függően, hogy mennyi RAM-ot szánunk az ASP.NET-nek
   • itt a privateBytesPollTime-hoz nem tudok best practice-t. Talán vegyük ki, mert a default a legjobb?!?
8. system.web/caching/outputcache-nél az enabled jellegűeket vegyük true-ra
9. sql kapcsolatra használjunk trusted connection a connectionstringben.
10. session timeout: sytem.web/sessionState tag timeout attribútumában kell megadni percben. Túl nagy szám esetén feleslegesen telik a memória, túl kicsi pedig idegesítő. Ha nincs specifikálva 10-20 percre tenném.
    • Session lejáratkor egyébként is jó ötlet kirúgni a felhasználót és elküldeni a kezdőlapra (ez ízlés kérdése).
    • Ha nem használja az alkalmazásunk a sessiont, akkor kapcsoljuk ki.
11. system.web/httpRuntime tag:
    • Az executiontimeout attribútum a feldolgozási időkorlátot adja meg másodpercben. Ha töltünk fel fájlt HTTP POST-tal az ASP.NET motoron keresztül, akkor meg kell tippelni, hogy mennyi ideig tartson a leghosszabb feltöltés (pl.: GPRS-es nettel) és mondjuk ha 1 óra, akkor ide 3600-at kell írni. De ha ilyen nincs, akkor vegyük kicsire, szerintem max. 1-2 percre, a célja alapvetően a végtelen ciklusba / deadlockba esett szálak kilövése, de 1-2 perc weben már amúgy is elfogadhatatlan (kivéve a POST-os feltöltést, ami semmiben sem különbözik egy Postback-től sajnos...).
    • maxRequestLength: a legnagyobb felposztolható kérés kilobyte-ban. ha nincs HTTP POST-os fájlfeltöltés, akkor kb. a legnagyobb oldalunk+mondjuk egy nagy hozzászólás+sütik, max. 1-2 megára tenném. Alapételmezetten talán 4 megabyte.
12. system.webServer/security/requestFiltering/requestLimits tag: ez a webszerver kérés-szűrője, az itt megadható legnagyobb kérés méretet szinkronban kell tartani az előző pontban írt maxRequestLength-szel. Az egységes elvek nagyobb dicsőségére ez byte-ban van! Így a fenti szám mögé még három darab nullát is kell írni.

IIS beállítások

1. Az alkalmazás egyedül fusson egy Application Poolban.
2. Ha van olyan mappa, ahova az alkalmazás felhasználói írhatnak/feltölthetnek, akkor arról szedjük le IIS-ben a script futtatást, hogy nehogy kész aspx-eket töltsenek fel!
3. IIS Manager -> AppPoolra –> Recycling
   • Érdemes végiggondolni, hogy mikor induljon újra a webalkalmazás.
   • Itt lehet megadni azt is, hogy mennyi memóriát szánunk az alkalmazásnak. Ez jó, ha szinkronban van a web.configos cache beállítással.
4. A statikus fájlokat (kép, CSS, JS) tartalmazó mappákra kapcsoljuk ki az IIS loggolást!

Az alkalmazás

1. Ha vannak béna jelszavú tesztuserek, akkor azokat töröljük ki.
2. A beépített usereknek adjunk normális jelszót.
3. Ha van hibalogunk töröljük ki.