OSX alatt ezt a következő paranccsal Terminal-ból megtehetjük (OSX 10.5+):

dscacheutil -flushcache

Korábbi OSX (10.4) esetén:

lookupd -flushcache

Windows alatt parancssorba (futtatás:cmd):

ipconfig /flushdns

OSX és linux alá is van működő megoldás:
rtmpdump (osx/linux/win) parancssori program. Kicsit kényelmetlenebb a használata, mert előbb ki kell bogarásznod az rtmp streaming url-t az oldal forrásából, aztán parancssorban felparaméterezni a progit. Viszont automatizált letöltésre emiatt kiválló. Osx 10.7 Lion alá itt egy bináris telepítő, hogy ne kelljen Xcode-al befordítani.

A levelezésemben ugyan 2004-es keltezésű az első levél, de a közel 30GB méret így is gyanús volt.. max. 10GB-ra saccoltam volna az 5 gmail fiókot összesen. Az óriási méret oka, hogy az OSX Mail mappa és a Gmail “tag” koncepciója nem igazán kompatibilis.

Van például Gmail-ben egy “Összes levél” tag, amely teljesen külön szinkronizálódik le egy-egy IMAP kéréskor egy Mail-es mappába, így gyakorlatilag minden levelünk legalább kétszer lesz meg. De hasonló a helyzet a Csillagozott levelekkel és más tagekkel is.

Szerencsére van megoldás az értelmetlenül használt tárterület visszaszerzésére és a rengeteg felesleges háttérszinkronizáció elkerülésére.

A Google vagyis a Gmail kivételesen tényleg a barátunk.. csak jelentkezzünk be fiókunkba és az email beállítások között a Címkék fülön vegyük ki a “Megjelenítés IMAP-en” pipát minden olyan címke mögül, amit nem akarunk szinkronizálni IMAP-en keresztül.

A hiba oka az, hogy a .air fájlokat az IIS MIME listája nem tartalmazza, így nem is szolgálja ki. A megoldás pofon egyszerű, adjunk hozzá az IIS Manager szerver beállításai között a MIME Type részben egy új típust:

Add..
File name extension: air
MIME Type: application/vnd.adobe.air-application-installer-package+zip

Sony NEX 5
Sony E Pancake f2.8 16mm
Minolta f1.4 50mm

Music credits: She – Atomic

A módszer lényege, hogy a két Dropbox példány más-más home folderral fut. A szkript készít hozzá egy új alkalmazás csomagot is, melyet ha hozzáadunk a System Preferences  / Accounts / Login items listához, akkor mindkét példány automatikusan indulni fog bejelentkezés után.

Az angol nyelvű leirás után volt egy mondat, amit szabad fordításban idéznék:

“Ne legyél paraszt, ne használj 10 ingyenes Dropbox accountot ezzel a módszerrel!” Köszi.

mkdir -p /Users/$USER/Applications/DropboxAltStarter.app/Contents/MacOS/

cat <<EOF >/Users/$USER/Applications/DropboxAltStarter.app/Contents/Info.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>CFBundlePackageType</key>
<string>APPL</string>
<key>CFBundleExecutable</key>
<string>DropboxAltStarter</string>
<key>LSUIElement</key>
<string>1</string>
</dict>
</plist>
EOF

cat <<EOF >/Users/$USER/Applications/DropboxAltStarter.app/Contents/MacOS/DropboxAltStarter
#!/bin/bash
# Assumes you have Dropbox in /Applications
HOME=/Users/$USER/.dropbox-alt /Applications/Dropbox.app/Contents/MacOS/Dropbox
EOF

chmod 755 /Users/$USER/Applications/DropboxAltStarter.app/Contents/MacOS/DropboxAltStarter

Mivel többnyire hegyek között járunk, internet elérés nincs.. helyette sms-ben küldjük a twitter üziket. Sajnos direktbe nem lehet sem a Twitterre, sem pedig a Facebookra SMS-t küldeni, mert Magyarországon nem elérhetőek ezek a szolgáltatások. (F*ck Twitter! F*ckbook!)

Van egy magyar twitter app, a Twittelo.hu ami részben megoldotta a problémánkat.. beregisztrálsz a twitter accountoddal, megadod a telefonszámodat és onnantól kezdve ha a twittelo  telefonszámára küldesz valamit sms-ben, az egyböl kikerül a twitter csatornába is. A dolog szépséghibája, hogy egy twitter accounthoz csak egy telefonszám tartozhat.. mi meg vagyunk huszonakárhányan..

Sokat keresgéltem ingyenes sms gatewayek után kutatva, de nem sok ilyen van, ingyen meg pláne nem.. Aztán rátaláltam a Connectotel M-Mail szolgáltatására, melynek segítségével telefonról sms-en keresztül bárkinek tudok emailt küldeni.

Van az egyesületnek Facebook accountja, ahol szintén meg szeretnénk jeleníteni az üzeneteket. Erre van is lehetőség a Facebook via email szolgáltatással, ami úgy működik, hogy kapsz egy mail címet a facebooktól és amit oda küldesz az szépen megjelenik az üzenőfaladon.. A dolog szépséghibája, hogy ilyen email címet kapsz: valami87masvalami@m.facebook.com Ember legyen a talpán aki ezt megjegyzi és -10 fokban bepötyögi a telefonba..

Peti a hegyekben van, írni akar valamit twitterre.. előkapja a telefont és bepötyögi sms üzenetként:

1. uzenet@summitsport.hu Itt vagyok a hegyekben!

2. Elküldi az SMS-t az M-Mail telefonszámára.

3. Az M-Mail az SMS szövegét elküldi a uzenet@summitsport.hu-ra no-reply@connectotel.com feladóként.

4. Az uzenet@summitsport.hu  forwardolja az üzenetet a Facebookos katyvasz email címre és Facebookon már kinn is az üzi.

6. Facebook üzeneteinket egyszerűen megjeleníthetjük Twitteren is, ha a Facebook – Twitter fantáziadús alkalmazását használjuk: http://www.facebook.com/twitter/

Twitter felől is meg lehet közelíteni a dolgot.. előbb twitterre érkezik meg emailben (Tweetymail segítségével) az üzenet, majd Twitterről a Selective Twitter FB alkalmazással Facebookra. Persze ez bonyolultabb, de ha valakinek pont ez kell, akkor csak rajta!

Időzóna.. A php.ini kapott több új direktívát, ilyen a date.timezone mostantól kötelező beállítás is. Állítsuk be a php.ini-ben tehát a következőt:

date.timezone = Europe/Budapest

Localhost és mysql esete.. Install után próbálgattam lefuttatni néhány weboldalamat, de nem ment.. jobban megvizsgálva, csak a mysql-t használó oldalak nem mentek, így gyanakodni kezdtem a mysql modulra. Az viszont rendben betöltődött, látszólag semmi gondja nem volt.. Némi guglizás után kiderült, hogy 5.3.1 óta a php valamiért nem bírja értelmezi az oprendszertől visszakapott localhost címeket, ha több mint egy ip van hozzárendelve. Így a localhost nem “fordul le” 127.0.0.1-re. Két bugfix kínálkozik, egyik sem a legszebb megoldás..

a.) localhost helyett ezentúl 127.0.0.1-et használunk adatbázis csatlakozáskor.

b.) átírjuk a hosts fájlunkat, amit a C:\Windows\System32\drivers\etc\alatt találunk:

::1             localhost

A fenti sort kommenteljük ki!

New windows specifikus, de ide tartozik, hogy az 5.3-as verzióban több függvényt is halálra ítéltek, az ítéletet viszont még nem hajtották végre. Az ilyen függvényeket ‘deprecated’ módba rakták, azaz használhatjuk, de egy új, “DEPRECATED ” típusú hiba figyelmeztet rá. Részletesen: http://www.php.net/manual/en/migration53.deprecated.php olvashatsz az érintett fügvényekről és régi-új megfelelőikről.

Találtam egy valóban működő és nagyon egyszerű megoldást:

PRAM Reset.. A gép indulásakor nyomjuk hosszan az ALMA + ALT + P + R kombinációt, amíg a gép újra nem indul (újra megszólal a boot dallam).

A PRAM resetelése a gép alapbeállításainak visszaállítását jelenti. A PRAM-ban olyan információk tárolódnak mint a képernyő színmélysége, felbontása, virtális mem. beállítások, kernel panic log, stb.. Alapesetben ezt nem érdemes piszkálni, de ha lassulást észlelünk bootoláskor, akkor nagy az esély rá, hogy a PRAM konfigurációjának hibája okozza azt.

1. Maga az install automatikus, letöltjük az ImageMagick honlapjáról a nekünk megfelelő Windows Binary installert és elindítjuk. Ha nem tudod melyik a neked megfelelő, akkor válaszd a ImageMagick-X.X.X-X-Q16-windows-dll.exe változatot.

2. Az installer alapbeállításban hozzáadja a progit a system path-hoz, így parancssorból könnyen használható a progi. Az installer utolsó ablakában van is egy teszt példa az image magick logójával. Ezt érdemes lefuttatni, hogy működik-e a dolog magában.

3. Jöhet a php-s kiegészítő dll, amit innen tölthetünk le:  http://snaps.php.net/win32/
Válasszuk a saját php verziónknak megfelelő kiadású peclX.X -win32-latest.zip fájlt és guberáljuk ki belőle a php_imagick.dll állományt! Másoljuk a php könyvtárának extension mappájába!

4. A php még nem tudja, hogy nekünk van ImageMagick progink a gépen, mondjuk meg neki! A php.ini fájlba vegyük fel a következő sorokat:

extension=php_imagick.dll

5. Indítsuk újra szervert, hogy a php.ini fájl feldolgozásra kerüljön!

6. Teszteljük!
teszt.php fájl tartalma első lépésben:

<?php phpinfo();?>

Futtatás után a phpinfo-ban szerepelnie kell egy Imagick résznek. Ha nem szerepel, akkor elrontottuk az installálást valahol. Ha szerepel, akkor próbáljuk ki:

A teszt.jpg-t másoljuk a teszt.php mellé, aminek a tartalma legyen:

<?php header('Content-type: image/jpeg');
$image = new Imagick('teszt.jpg');
$image->thumbnailImage(100, 0);
echo $image; ?>

Az Imagemagick egyik nagy előnye, hogy a php exec paranccsal lehetőség van a parancssoros feldolgozásra, azaz nem a php futtatja a képek átalakítását, hanem egy külön windows programszál. Erről majd máskor..

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.

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!

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

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)) ;
}

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?

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

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.

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.

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.