Google Apps migrációs problémák és megoldásaik

Több domain levelezését átraktam Google Apps alá, mert az jó. De tényleg.. komplett megoldást nyújt már a Standard (ingyenes) változat is, sokkal jobb (érthető okok miatt) a SPAM szűrés, mint bármilyen saját szűrős megoldás, rengeteg plusz szolgáltatást (Calendar, Docs, ActiveSync, stb..) tudunk igénybevenni saját domainünkkel, kapunk egy egyszerű admin felületet, ahol szabályozhatjuk a domain felhasználóit (postafiókjait). Nem is részletezem, próbáljátok ki!

A levelezés migrációja nem mondható bonyolultnak, néhány új MX és CNAME rekord beállítására van csak szükség domainünk NS szerverein, létre kell hoznunk a kívánt email (domain) felhasználókat, esetlegesen áttölteni a régi leveleiket, aliasokat és csoportos kézbesítéseket létrehozhzni, stb, stb..

A migrációt követően viszont van néhány kellemetlen dolog, amik megoldásával el kell játszani egy darabig, főleg ha nem tudjuk mi is igazából a probléma.
Lássuk, nálam milyen problémák jöttek elő és azokra milyen megoldásokat találtam:

1. probléma: PHP levélküldés nem működik a domaint kiszolgáló webszerveren, SPAM-be kerül a címzettnél.

Ezzel a problémával nagy valószínűséggel szinte mindenki találkozik, aki weboldalt is hosztol egy másik szerveren a GoogleApps-al használt domain alatt. Nálam a mailszerver és a webszerver is egy vason volt korábban, ilyen esteben a php.ini-ben és a mailszerveren megadott beállítások relative egyszerűek, a php mail() függvény teszi a dolgát a lokális SMTP-n keresztül, nem is kell vele foglalkoznunk.

De mi van, ha a domaint valósan kiszolgáló MTA fizikailag egy másik szerverre, jelen esetben a Google Apps szervereire kerül? Ha megmarad a mailszerver használhatjuk annak SMTP-jét, vagy telepítünk valamilyen mini SMTP szervert  a webszerver mellé! Így a levélküldés működik szépen, csak az okosabb SPAM szűrők ki fogják dobni a címzett oldalán összes levelünket. Miért is?
Egyszerűen azért, mert a  szűrő csak annyit lát, hogy a domainem.hu MX rekordja nem arra a szerverre mutat,  amiről a levél érkezik. A Gmail szűrője (nagyon helyesen) ezt figyeli, rosszabb esetben törli és soha nem kapjuk meg, jobb esetben felcimkézi SPAM cimkével a levelet. Ha nem tenné, bárki küldözgethetne nekünk saját domainem.hu-s címünkkel leveleket..

A megoldás:

SPF rekord. Az SPF (Sender Policy Framework) TXT rekordok segítségével szabályozhatjuk DNS szinten, hogy mely szerverek küldhetnek domainünk alól levelet. Sok próbálkozás és a Google által ajánlott megoldás helyett végül a következő SPF rekord került beállításra nálam és azóta rendben mennek a dolgok:

v=spf1 a mx a:000.000.000.000 include:_spf.google.com include:aspmx.googlemail.com ~all

A 000.000.000.000 helyére a webszerver IP címét írjuk! Azét a szerverét, ahonnét php mail()-el küldeni akarunk.
Fontos! Az all végződés előtti karakter nem kötőjel (-) hanem hullám karakter!
A fenti SPF rekord beállításával működik a php-ből indított levelek küldése, nem kerülnek SPAM-be a címzettnél.

2.probléma: SPAM levelek és a POP3

A Gmailben nem lehet kikapcsolni a SPAM szűrést. Alapértelmezetten minden fiókban van egy “Spam” mappa, illetve Gmail címke, amelyet minden beérkező levél megkap. Így a bejövő levelek közt nem jelennek meg, csak a SPAM mappában (címke alatt). Innen a levelek egyébként 30 nap elteltével automatikusan törlődnek is, tehát érdemes gyakran ellenőrizni..

Ha a Gmail felületét használjuk, ott van a mappa (címke), bármikor megnézhetjük,  semmi gond. Sőt IMAP protokoll használatával is szépen el lehet érni a címkét mint IMAP mappa.
Viszont a POP3 egy régi protokoll, csak arra képes, hogy a bejövő (INBOX) leveleket letöltse. Sok cégnél ragaszkodnak a POP-hoz, ezért a problémára valamilyen megoldást kellett keresnem:

A megoldás:

Sajnos csak olyan lehetőségünk van, amivel a SPAM szűrést mellőznünk kell. Persze ez arra a minimális SPAM mennyiségre vonatkozik, ami egy átlagos gmail fiókba érkezik.. (nálam napi 1-2 levél 3 ráirányított címmel). Rengeteg SPAM-et már eleve át sem enged a Gmail levélszemét szűrője és eldobja kézbesítés előtt.

A megoldás lényege, hogy létrehozunk egy Gmail szűrőt, ami a Spam mappa helyett a bejövő mailek közé rakja a levelet, így a POP kliens le tudja tölteni:

1. Hozzunk létre a Gmail / Beállítások / Szűrők menüben egy újat!
2.“Tartalmazza a következő szavakat:” nevű mező tartalma legyen ez:  is:spam
3. Tovább, majd jelöljük ki a “Soha ne legyen spam” opciót.
4. Done. Enjoy the SPAM!

Folyt. köv.

Wp Post Thumbnail 0.2b Loading.. bug fix

Finaly I found all the bugs in the Wordpress Post Thumbnail plugin. This fixed wppt.php file solves the famous “Loading.. ” problem, but only works under IIS hosted Wordpress blogs. If your hosting server or local development server is IIS (windows webserver) based, you should check this fix!

Download here the fixed file: wppt.php.zip

Please note:
This is NOT a crossplatform fix, only works under IIS!

Instructions:
1. Replace the original wppt.php with the unarchived.
2. If  the wp-content/uploads/wp-post-thumbnail/ directory doesn’t exist, create it!
3. Enjoy the fixed plugin!

If this bugfix saved your life or something like that, please send me some beer or donate (on the sidebar)!

Thank you!

Gmail Apps Php Mailer SMTP beállítások

Ezt a postot részben magamnak ajánlom, mert mindig elfelejtem valamelyik paramétert, részben pedig azoknak a sorstársaknak, akik a Google Apps / Gmail fiókjuk nevében akarnak emailt küldeni php mailer libraryvel.

$mail->IsSMTP();
$mail->Host = "ssl://smtp.gmail.com";
$mail->Port = 465;
$mail->SMTPAuth = true;
$mail->Username = "username@gmail.com";
$mail->Password = "password";

Flex: ViewStack select by id

Flashben programozni szívás, Flexben is. Ezzel a problémával több mint egy órát tököltem, ezért szentelek neki egy gyors kis blogbejegyzést..

Van egy ViewStack komponensünk (MyViewStack), ebben pedig szépen elnevezett gyermek elemek. Elnevezés alatt azt értem, hogy mindegyiknek van saját “id”-je. Szeretnénk, hogy ne csak hagyományos módon az index alapján  ( MyViewStack.selectedIndex=1) lehessen elérni, hanem a “Stack” id-je alapján, amit stringként közlünk a megjelenítő metódussal.

A metódus adott: MyViewStack.selectedChild=, viszont a bemenet nyilván nem lehet egy sima változónév, Container-re kell hivatkoznunk. Naív módon próbálkoztam ilyen flashes közhelyekkel: this[target] és társai..

Persze nem ment. Mivel Container kellett neki minden áron, beimportáltam az  mx.core.Container csomagot és rájöttem, hogy mennyire  szépen meg lehet ezek után oldani a problémát:

import mx.core.Container;
private function showTarget(target:String) : void
{
    MyViewStack.selectedChild = Container(MyViewStack.getChildByName(target)) ;
}

updown.com - online tőzsde

Van egy remek online játék, az updown.com. Igazi tőzsdei adatokkal (minimális késleltetéssel) működő online tőzsdei game. Kapsz 1M dollár kezdőtőkét, azt okosba befektetedheted, pontosan úgy adhatod-veheted a részvényeket, shortolhatod az OTP-t mint Soros Gyuri bácsi.. Közösségileg megvitathatod mik a trendek, mit és mit nem érdemes vásárolni, stb, stb.. (OTP amúgy nincs persze, ilyen balkáni (wc)papírokkal nem foglalkoznak.

Kb. fél éve volt egy BÉT előadás a tőzsde működéséről, alapfogalmakról, amit végighallgattam. Érdekes volt, akkor regisztráltam az updown.com-ra is. Akkor 1-2 hétig játszogattam vele, jópofának tűnt. Aztán se időm nem volt, se kedvem hozzá, nem foglalkoztam vele.
Benne maradt kb 100.000 USD részvényekben. A többi alaptőkét nem fektettem be. Jelenleg 1.165.000 USD-m van játékpénzben. Elgondolkodtató, nem? Szinte random módon kiválasztott cégek részvényeiről van szó, amikről pénzügyi szempontból semmit nem hallottam eddig, nem figyelem a híreket és egy grafikonjukat sem nézegettem még trendelemzési szándékkal. Hagytam őket érlelődni 5 hónapot és mi lett belőle? Dupla annyi pénz, sőt 1,5x-ese a befektetett összegnek. Ezek után örülnöm kellene a garantált <10 %-ékoknak? Most akkor mi legyen, tőzsdézzek?

E-felvételi 2010

Volt szerencsém kipróbálni az e-felvételi rendszert, jelentkeztem egy MSC kézésre. Imádom a kihívásokat, ezért döntöttem az online módszer mellett. Titkon reméltem, hogy látok majd valami jó megoldást, valami olyat, amire azt mondhatom: igen a Felvisek megcsinálták. Sajnos csalódnom kellett, ez a rendszer is a következő tipikusan “magyar IT modellen” alapul:
1. Végy egy lejárt tanúsítványt.
2. Egy tehetségtelen programozót, rendszergazdát és sitebuildert. Ha elég pénzed van (közigazgatási szektor, hogyne lenne), akkor akár egy csapatnyit is.
3. Félig működő állami infrastruktúrát és kapcsolódó szolgáltatásokat (pl. Ügyfélkapu).
4. Az OTP szutyok online fizetési rendszerét.
6. Jól gyúrd össze!
Készen is van! Ha véletlenül a magyaroszag.hu-t kaptad a felvi.hu helyett, akkor rossz irányba keverted.
Persze, tudom fikázni könnyű.. hibázni mindenki szokott, én is, de ha én egymagam ennyi hibát találtam, az már tényleg gáz:

0. Hol az efelvételi? Október 15-e éjjel (a jelentkezés első napja): Nézem a felvi.hu-t… mindenütt kinn a szöveg, hogy hogyan jelentkezz, mit adj meg, hova klikkelj, de az eFelvételi menüpont hiányzik. Okt. 16 de.: még mindig semmi, hívom az ügyfélszolgálatot, hogy bocsánat, lehet, hogy én vagyok a hülye, de nem találom az efelvételi menüpontot.
“Ja, az még nincs aktiválva.” “Hmm.. és mikor várható? ” “Őőőő talán a holnapi napon. De ha nem, akkor hétfőig biztosan.” “Ja, jó.. köszönöm. Viszhall!” Kiváncsi lennék, hogy ha én 3 nappal a jelentkezési határidő után jelentkeznék, azt elfogadnák-e.

1. Dokumentumfeltöltés esetén, ha túl nagy a fájl, benyom az iframe-be egy Bad Request HTTP error böszme feliratot.. Se hibakezelés, se semmi.. a szegény hétköznapi diák meg jöjjön rá mivan..

2. Lejárt session.. ajaxos művelet esetén kiokádja a div-be újra az egész oldalt.. Site in a div effect, értem én..

3. Ügyfélkapu hitelesítés.. na ez a legszebb, komolyan.. SSL error. Rossz a tanúsítvány, de nem csak szimplán rossz, hanem durván.. én ilyet még nem láttam.. Kb. 18-at kellett klikkelnem Firefoxban mire letöltötte és elfogadta az ócska tanúsítványt. Ok, én tudom, hogy ez a programozók, rendszergazdák hanyagsága, de egy ÁLLAMI cég tanúsítványa legyen már rendben könyörgöm!! Főleg ha azon a személyes adataimat hitelesítem. Miért neveljük szerencsétlen felhasználókat arra, hogy lesz@rják a tiltó és figyelmeztető üzeneteket?!

+1 a ráadás. OTP fizetés.. Fizetek, jön az SMS, 9essze’ levonva a számláról. Böngészőben szép kis HTTP error. Visszakavarodok a felvi.hu-ra.. látom, a felületen továbbra is “Önnek 9000 Ft díjtartozása van.” Ekkor a jelentkezés folyamata során harmadszor hívom az ügyfélszolgálatot.. Azonnal felveszik, mondom mi a gond. 10 msp múlva már mondja is a srác, hogy minden rendben, jóváírták az összeget, hamarosan a felületen is ezt látom majd. Elköszön.

Leteszem, aztán elgondolkodok.. Nem is érdekelte, hogy hibás a fizetési rendszer.. Feltételezem az ügyfélkapus hitelesítésnél felugró tanúsítványablakokkal sem bírkózott meg mindenki, arról is tudnak.. és tudjátok mi van? Leszarják. Leszarják, mert na és? Mi van, ha nem megy.. max beadod papíron, vagy nem leszel jövőre egyetemista. Ez az ami baromira dühítő az egészben.. na meg az, hogy a főnökeik, meg az ő főnökeik is így gondolkoznak.

De legalább a support gyors

IIS - MySQL Membership Provider telepítése

A cél egy integrált vitruális felhasználókat kezelő rendszer létrehozása volt IIS alá, ami független az IIS Manager Userektől és természetesen a Windows felhasználói fikókoktol is, ugyanakkor elérhető az IIS FTP, WebDAV és egyéb szolgáltatásaiból. A megoldás egyik alappillére a .Net Membership rendszere.

Az én megvalósításomban az adatbázis nem a megszokott Microsoft SQL, hanem MySQL. A telepítés kicsit macerás volt egy idegesítő hiba és a konfiguráció nüanszai miatt, ráadásul mivel nem vagyok .Net fejlesztő és VS-ből soha nem próbáltam ilyen kapcsolatot létrehozni, IIS-ből sem volt könnyebb.

Kapásból vakvágányra futottam, mert Google-ban keresgéltem, megszegve ezzel az MS fejlesztők és rendszergazdák elsőszámú szabályát: használd a Support weboldalakat, mert sz@runk a google-ra és nem hagyjuk, hogy a jó megoldásokat első oldalon hozza. Szal’ elkezdtem behackelni ezt a göncöt: http://www.codeproject.com/KB/database/mysqlmembershipprovider.aspx Már az SQL táblák létrehozása egy katasztrófa, hagyjuk is.

A jó megoldást a MySQL saját connectora jelenti: Connector/Net 6.2: Nem kell félni az MSI installertől, kiválóan működik.

A Connector mellé installálni kell a MySQL ODBC Drivert is. Töltsük le a MySQL oldaláról, majd telepítsük.

IIS Managerben elég bonyolult a sok kattintgatás, ezért inkább postolok egy helyes, jól működő web.config kódot:

<!-- Előbb eltávolítjuk az alapértelmezetteket, mert az IIS hiányolja őket és a sajátunk nem fog működni-->
<connectionStrings>
        <remove name="LocalSqlServer" />
        <remove name="LocalMySqlServer" />
        <add name="LocalMySqlServer" connectionString="Datasource=localhost;Database=dbname;uid=username;pwd=password;" providerName="MySql.Data.MySqlClient" />
</connectionStrings>

<system.web>
    <roleManager enabled="true" defaultProvider="MySQLRoleProvider">
      <providers>
        <clear />
        <add name="MySQLRoleProvider" type="MySql.Web.Security.MySQLRoleProvider, MySql.Web, Version=6.0.3.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d" connectionStringName="LocalMySqlServer" applicationName="LoginControl" />
      </providers>
    </roleManager>

<!-- autogenerateschema="true", ha nem kézzel akarjuk létrehozni a táblákat..-->
 <membership defaultProvider="MySQLMembershipAppProvider">
       <providers>
        <clear />
        <add name="MySQLMembershipAppProvider" type="MySql.Web.Security.MySQLMembershipProvider, MySql.Web, Version=6.0.3.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d" autogenerateschema="true" connectionStringName="LocalMySqlServer" enablePasswordRetrieval="false" enablePasswordReset="true" requiresQuestionAndAnswer="false" applicationName="LoginControl" requiresUniqueEmail="true" passwordFormat="hashed" maxInvalidPasswordAttempts="7" minRequiredPasswordLength="7" minRequiredNonalphanumericCharacters="1" passwordAttemptWindow="10" passwordStrengthRegularExpression="" />
      </providers>
    </membership>

    <compilation>
      <assemblies>
        <add assembly="MySql.Data, Version=6.0.3.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d" />
      </assemblies>
    </compilation>

</system.web>

Jellegzetes hibalehetőségek, amikkel én is szívtam:

1. ODBC Dirver tényleg legyen rendben, akár teszteljük is, mielőtt bármit konfigurálnánk.

2. Ha az ODBC rendben, ne felejtsük a schema=”true”-t hozzáadni a MemberShip Providerhez, mert különben nem jönnek létre a szükséges táblák a MySQL adatbázisunkban.

3. Figyeljünk, hogy ne legyen hiba a connection stringben, nem szereti a jelszóban a különleges karaktereket.

Ha mindent jól csináltunk, az IIS Manager ASP.NET / .Net Users-be belépve egyrészt nem kapunk hibát, másrészt létrejönnek adatbázisunkban a szükséges táblák és akár meg is kezdhetjük a felhasználók feltöltését. Az IIS tökéletes felhasználókezelést nyújt, nemsokára posztolom az én Flexben készült “Fancy Remote” applikációmat, ami még fejlesztés alatt áll.

IIS7 Custom Basic Authentication

Már régóta kerülgetem a Codeplex-en ezt a projektet, soha nem jutottam el addig, hogy kipróbáljam. Az a baj az IIS Basic Authentication-nel, hogy nem tudunk vele virtuális felhasználókat kezelni, csak igen komplikált módon. Akkor is csak úgy, hogy az IIS configjában tárolódnak a felhasználók adatai. A célom az volt, hogy egy külső MySQL adatbázisba valamilyen okos formában tárolódjanak az IIS virtuális felhasználói és azokat az összes IIS-es szolgáltatásból (Védett könyvtárak, FTP, WebDav, stb..) elérjem, autentikálhatóak legyenek. Pontosan erre jó a Custom Basic Authentication nevű kis projekt. Pontosabban arra, hogy egy .Net Membership Providert elérhetővé tegyen Basic Authentication formában.

Telepítése nem túl bonyolult:
Töltsük le a http://www.codeplex.com/CustomBasicAuth weboldalról (az installert, ne a forrást).
Persze gondok lesznek, különben nem ínék róla
Az installer.cmd a gautil.exe-t használja, ami nagy marhaság a kedves fejlesztő részéről, hiszen a .Net Framework 2 óta ez a utility nincs benn a Frameworkben, csak az SDK-ban. Kiszolgálókra meg ugyebár mióta divat SDK-t pakolni :S Az MS hivatalos álláspontja egyébként az, hogy a GACUTIL egy fejlesztői eszköz, ezért is vette ki a Frameworkből.

Itt kicsit tétováztam, mert nem igazán tudtam, mire jó egyáltalán ez a kis programocska. Aztán kiderült, hogy igazából nincs rá szükség. Fogjuk a 3db dll fájlt és másoljuk a C:/Windows/assembly könyvtárba, így bekerülnek a GAC-ba. Majd az installer kikommentelt utolsó két parancsát futtassuk le parancssorból a fájlok mappájában:

iisschema.exe /install CustomBasicAuthentication_schema.xml

IisRegMgmt CustomBasicAuth LeastPrivilege.CustomBasicAuthentication.Management.CustomBasicAuthenticationModuleProvider LeastPrivilege.CustomBasicAuthentication.Management.dll

Voila, készen is vagyunk, az IISManager-ben a Site-unk Authentication panelján már ott kell lennie a Custom Basic Authentication opciónak is. Az Edit-re kattintva konfigurálhatjuk, hogy melyik providert használja. Tiltsuk le az összes többi Authentication módot és próbáljuk ki a böngészőből. Ha feldobja az autentikációs ablakot, akkor nyertünk. A sikeres bejelentkezéshez persze kell a működő provider is.

Ha esetleg nem működne a cucc, és még nincs a helyén, akkor az IIS Managerben a Modules panelon adjuk hozzá az installált modulokhoz a CustomBasicAuthentication-t is a legördülő listából.

IIS7 Pass-through Authentication + WebDAV

Miután sikerült beüzemelni a .Net Membership Providert és a Custom Basic Authentication kiegészítést, lehetővé vállt, hogy MySQL-ben tárolt virtuális felhasználóimat minden szolgáltatásnál használhassam. A WebDAV persze megint bekavart..

Amit én szerettem volna az a következő:
1. WebDAV SSL titkosítással
2. Egy központi WebDAV root folder és abban Virtuális mappaként bemappolva a felhasználók Site-jai úgy, hogy a webdav root-hoz és más domainjai alatt lévő tartalomhoz se férjenek hozzá.
Az egyes hosztolt weboldalak elérései így néznének ki:
http://www.host.hu/webdav/domain1.hu
http://www.host.hu/webdav/domain2.hu

Az elképzelés tökéletesen működhetne, de nem ment elsőre a dolog..
A főbb lépések így néztek ki:
1. A host.hu/webdav/domain1.hu - virtuális mappa WebDav Authentication Rule-jai közé hozzáadtam a “test” nevű felhasználót.
2. Adtam neki WebDAV jogokat, innentől kezdve elméletileg van joga a virtuális könyvtár fizikai helyére és annak összes alkönyvtárára WebDAV-on keresztül.
3. Csatlakoztam a “test” nevű felhasználóval és rendben meg is jelent a domain1.hu könyvtár tartalma:

log/                   --        Tue, 20 Jan 2009 09:07:05 GMT
tmp/                   --        Tue, 20 Jan 2009 09:07:13 GMT
www/                   --        Wed, 28 Jan 2009 15:35:31 GMT

A log és tmp könyvtárakkal semmi gond, minden jog érvényesült. Viszont a www-re listázáskor hibát kaptam, nem érvényesültek rá a domain1.hu-ra kiadott jogok. Csak a www-re? Mivan? Miért is?

Mivel az IIS konfigurációja elosztott, több szinten definiálható, ezért amikor egy kérés jön a webszerverhez, ő gyorsan körbenéz minden beállítási szinten: megnézi az applicationHost.config fájlban az alapbeállításokat, érvényesíti, a location tagekben (ha van) a site konfigurációját, érvényesíti, egy szinttel lejjebb, a könyvtárstruktúrában elhelyezett web.config fájlokban keres, érvényesít és halad méglejjebb az almappák web.config-jaihoz, stb, stb.. Hopp! Ez lesz a baj!

Mivel a http://www.host.hu/domain1.hu/www mappa igazábol a szerveren hosztolt domain1.hu site root-ja, az ottani web.config fájlt is érvényesíteni szeretné függetlenül attól, hogy én WebDAV-on keresztül egy másik alkalmazásból hívom meg a könyvtár elemeit. Szeretne hozzáférni a web.config-hoz, de nyilván nem tud, innentől kezdve nagyon egyszerű dolgunk van, hiszen csak azt kell megakadályoznunk, hogy a domain1.hu alkönyvtárait és az azok alatti könyvtárak web.config fájljait is keresse az IIS. A legszebb az egészben, hogy ehhez csak annyit kell tennünk, hogy a domain1.hu virtuális könyvtárához hozzáadjuk az allowSubDirConfig=”false” paramétert az applicationHost.config központi konfigurációs fájlban.

A dolog működik, viszont óriási biztonsági rést üt. Gondolkozzunk el egy picit, hogy hogyan működik a WebDAV. A HTTP protokoll hátán utaznak az infok, a 80-as porton. Az IIS elkülöníti a WebDAV és sima HTTP kéréseket, jogosultságilag is, azzal nincs is gond, hogy a WebDAV jogokat csak a webdav/domain1.hu, webdav/domain2.hu stb.. virtuális mappákra és azok felhasználóira adom ki így megakadályozva, hogy egyik felhasználó a másik cuccai közt bóklásszon.
De ha ezt sima HTTP-n keresztül teszi, akkor autentikáció után a böngészőbe csak a mefelelő elérési utat kell bepötyögnie és bármilyen fájlhoz hozzáfér amit a virtuálsi WebDAV-os mappákkal bemappoltam. Azt mondanán, hogy ez sem gond, hiszen ezt közvetlenül mondjuk a domain1.hu/titok.html-en keresztül közvetlenül is megteheti. Pedig nem. Mivel a web.config fájlokban olyan autentikációs és authorizációs illetve átirányítási utasítások lehetnek, melyek elfednek bitonyos fájlokat a működő aplikációkban, ezért ha mi hatástalanítjuk a allowSubDirConfig-al, szabad az út az ilyen módon védett tartalomhoz. a http://www.host.hu/webdav/ felől érkezve.

Ezért mindenképp meg kell akadályoznunk, hogy a bejelentkezett felhasználó HTTP (nem WebDav) kéréssel elérje a könyvtárakat (persze a saját könyvtárát el kell, hogy érje, hiszen ha HTTP nincs, WebDAV sincs). A megoldás pofon egyszerű és szép is:

1. A webdav/ könyvtárunkat fosszuk meg az Authorization beállításoknál az Allow All-tól. Ezzel megakadályozva, hogy az autentikált felhasználó bármit is elérjen a könyvtáron belül.
2. Osszunk ki egy szinttel lejjebb a webdav/domain1.hu felhasználójának a “test” usernek egy Allow-t.

Kész a shared hosting webdav elérés is. Enjoy!
Felelőséget persze nem vállalok az itt leírtakért, mert csak részben érintem a biztonsági kérdéseket. Ezen kívül rengeteg egyéb követelménynek kell teljesülnie egy biztonságos kiszolgálón.

Napi Script: Window wget alternatívák

Ez az első szkript, amit megosztanék a “Napi script” sorozatban. Terveim szerint felteszek majd sokkal komplexebb, speciális kódrészleteket is főleg PowerShell és VBScript nyelveken. Elsősorban olyan szkripteket, amik az adminisztrátorok mindennapos problémáit oldják meg windows rendszereken. Rengeteg (akár fizetős) segédprogram és alkalmazás kiváltható szkriptes megoldásokkal. Minimális programozási tudással lehet rajtuk változtatni, testreszabni, okosítani őket.

WGET: A unixos wget parancs nagyon hasznos, gyakran használjuk és éppen ezért windowson erősen érezhető a hiánya. A Windows CMD parancsai között nincs ilyen, helyette több alternatívát ismertetnék:

1. Wget.exe - Remek kis utility. Aki nem akar sokat szórakozni töltse le, másolja be valamelyik PATH mappába és már használhatja is úgy mint más rendszereken. Mivel a normál commandline-ban nem csak wget parancs nincs, hanem a szögfeldolgozási lehetőségek is igen gyérek, a visszakapott http válasszal, vagy fájlal már nem nagyon tudunk mit kezdeni. Ha mégi ilyen szándékaink vannak, más, szkriptelési megoldások után kell néznünk:

2. VBScript: Az alap, IXMLHTTPRequest interfészt használó HTTP kérést végrehajtó szkript alább látható. Nem többről van szó, mint egy http kérés indításáról és a válasz tartalmának kiíratásáról. A kikommentelt rész az url paraméterként való megadhatóságára szolgál ha CMD-ből, szeretnénk futtatni.

Option Explicit
On Error Resume Next

Dim url
url="http://blog.vargapeter.com"

'Dim paramz
'Set paramz = WScript.Arguments
'url = paramz(0)

Set objHTTP = CreateObject("MSXML2.XMLHTTP.3.0")
objHTTP.open "GET", url, false
objHTTP.send()
MsgBox objHTTP.responseText
Set objHTTP = Nothing

3. Powershell: Mivel PS-ből meg tudunk hívni .Net-es osztályokat, használjuk a System.Net.WebClient-et. A neve beszédes, van egy rakás metódusa és tulajdonsága. Lássunk egy egyszerű példát az előző kód mintájára:

$httpclient= new-object System.Net.WebClient
$httpclient.DownloadString("http://blog.vargapeter.com")

4. Mi van még? PS alatt azért jól el vagyunk látva, írtak többen is cmdleteket az egyszerűbb hívás érdekében:
WGet 2 for PowerShell
Jacobian’s wget for PowerShell

Hát ennyi.. használjuk azt a megoldást, ami céljainknak legjobban megfelel.
Holnap új téma, új szkriptek!