Postsharp használata projekten és futó kód nélküle is:
Mivel a PostSharp aspektusa "csak" egy attribútum az osztályon/metóduson, ezért a kód le fog fordulni akkor is, ha a PostSharp nincs felinstallálva, sőt futni is fog, ha olyan jellegű a kód.
Ellenben, ha például jogosultságellenőrzés megy így, akkor mindig be fogja engedni a hívást PostSharp nélkül, fordul, fut, deploy-olható a kód.
Ha van egy szarul bekonfigurált gép és egy jól és felváltva csinálnak róla deploy-t a tesztrendszerre, akkor elkezdődik a most van-most nincs játék a tesztelőktől, amit fejlesztő persze nem hisz el... :)
A következő címkéjű bejegyzések mutatása: szívás. Összes bejegyzés megjelenítése
A következő címkéjű bejegyzések mutatása: szívás. Összes bejegyzés megjelenítése
2011. november 11., péntek
2010. május 12., szerda
userek MSSQL-ben, Windows-ban, és amivel szophatsz
Tegyük fel, hogy van egy 9 gépes tesztrendszered. Tegyük fel, hogy nem Te installáltad fel, és tegyük fel, hogy véletlenül a hozzátartozó dokumentumban elcseréltek két web szervert (DMZ-ben lévő, belső hálón lévő).
1. Megpróbálsz az általad belső webszervernek hitt szerverről bejelentkezni az SQL-be, nem megy.
2. OK, rosszul konfigoltál valamit, létrehozol SQL usert, hisz az tuti. Azzal se megy. Később rájössz, hogy SQL usert létre lehet hozni olyan SQL szerveren is, ami _nem_ mixed mode (ez logikus), de egy szót se szól, hogy ezzel ide biztos nem fogsz belépni...
3. Nem baj, leesik, megpróbálsz domain userrel belépni a webszerverre, hogy az SQL-be domain userrel tudj menni. Nem megy. A local admin és a domain admin jelszava megegyezik. Remote Desktop progival megadod kézzel, egyértelműen a domaint és a usert, alul írja is. TOVÁBBRA SEM MEGY az sql-be belépés, miközben az sql gépen megy ugyan ezzel a userrel, tűzfal nincs bekapcsolva. Aztán több órás szopás után észre veszed, hogy a Remote Desktop SZÓ NÉLKÜL lecseréli a domaint, ha az adott domainbe nincs beléptetve a gép (itt van az elcserélt szervereknek közül a történethez), és a saját domainba lépteti be a saját admint SIKERESEN, nem pedig a domain admint!
Tehát:
1. SQL nem szól, hogy ne szenvedj az sql userrel, mert nem fog menni, még hint szintjén se, ha sima windows mode-ban van feltéve.
2. Remote Desktop szó nélkül domaint cserél, ha ismeretlen a domain számára, és ha a usernév+jelszó megtalálható a gépen BE is fog lépni sikeresen...
1. Megpróbálsz az általad belső webszervernek hitt szerverről bejelentkezni az SQL-be, nem megy.
2. OK, rosszul konfigoltál valamit, létrehozol SQL usert, hisz az tuti. Azzal se megy. Később rájössz, hogy SQL usert létre lehet hozni olyan SQL szerveren is, ami _nem_ mixed mode (ez logikus), de egy szót se szól, hogy ezzel ide biztos nem fogsz belépni...
3. Nem baj, leesik, megpróbálsz domain userrel belépni a webszerverre, hogy az SQL-be domain userrel tudj menni. Nem megy. A local admin és a domain admin jelszava megegyezik. Remote Desktop progival megadod kézzel, egyértelműen a domaint és a usert, alul írja is. TOVÁBBRA SEM MEGY az sql-be belépés, miközben az sql gépen megy ugyan ezzel a userrel, tűzfal nincs bekapcsolva. Aztán több órás szopás után észre veszed, hogy a Remote Desktop SZÓ NÉLKÜL lecseréli a domaint, ha az adott domainbe nincs beléptetve a gép (itt van az elcserélt szervereknek közül a történethez), és a saját domainba lépteti be a saját admint SIKERESEN, nem pedig a domain admint!
Tehát:
1. SQL nem szól, hogy ne szenvedj az sql userrel, mert nem fog menni, még hint szintjén se, ha sima windows mode-ban van feltéve.
2. Remote Desktop szó nélkül domaint cserél, ha ismeretlen a domain számára, és ha a usernév+jelszó megtalálható a gépen BE is fog lépni sikeresen...
Feliratkozás:
Bejegyzések (Atom)
