htaccess tutorial BEVEZETÉS:

Átírás

1 htaccess tutorial Készítette: Cyber Zero Web: Msn: Skype: cyberzero_cz Fb: BEVEZETÉS: A htaccess, azaz hypertext access, egy könyvtár szintű konfigurációs fájl, ami lehetővé teszi, hogy a webszerver fő konfigurációjától eltérő beállításokat alkalmazzunk könyvtárakon, továbbá, hogy lehetőségünk legyen egyedi beállításokat alkalmazni a különböző könyvtárakra, és ne csak egy beállítási lehetőségünk legyen, ami az egész webszervert egyszerre befolyásolja. Lehetőségünk van a segítségével a könyvtárra vonatkozó biztonsági beállítások használatára a könyvtáron, amelyekkel meghatározhatjuk az engedélyeket és hitelesíthetjük a felhasználókat. Ilyenkor a.htaccess fájlt gyakran követi egy.htpasswd fájl, amely tárolja az érvényes felhasználónév és jelszó párosokat. A htaccess-t használhatjuk hosszú, emberek számára értelmezhetetlen url címek átírására, melyeket így rövidebbre, megjegyezhetőbbre és a kereső robotok számára is barátságosabbá tehetünk. Lehetőségünk van IP cím, vagy domain név alapján megtiltani a mappákhoz való hozzáférést például a kereső robotok vagy egyéb nem kívánt személyek számára. Beállíthatjuk a mappák listázását, ha nem egy egyedi oldal címét gépeli be a felhasználó a böngészőbe, hanem egy mappa elérési útvonalát. Készíthetünk testre szabható hibaüzeneteket, ha az oldal nem található (404), vagy ha véglegesen el lett távolítva (301). Utasíthatjuk a kiszolgálót, hogy az egyes MIME típusokat, hogyan kezelje a különböző fájltípusoknál és végezhetünk gyorsítótár beállítást a szerver terhelésének csökkentésére. Összegezve tehát a htaccess előnye abban rejlik, hogy a hatásuk azonnal érvénybe lép, ellentétben a központi szerver beállításokkal, amikhez újra kell indítani a szervert, illetve lehetővé teszi a különböző oldallal rendelkező felhasználók számára, hogy saját weboldalaik beállításait elvégezhessék, anélkül, hogy jogot kéne adnunk nekik a központi beállításokhoz. Természetesen így ha a szerver nincs megfelelően beállítva, akkor biztonsági aggályokat vet fel, hogy minden felhasználó azt állítgathat be magának amit akar a htacces fájlok segítségével és a szervert is jobban leterheli. Ha saját szerverünk van, akkor inkább a központi beállításokat használjuk, mert az kevésbé terheli a szervert, de ha elosztott szerveren vagyunk egy másik szolgáltatónál, akkor ez a legjobb lehetőségünk a testreszabásra. A szerver konfigurációi között jól be lehet állítani, hogy mit engedélyez a htaccess fájloknak módosítani. Ha a mi könyvtárunkra be van állítva az AllowOverride All opció, akkor bármit megtehetünk, amit csak szeretnénk.

2 A htaccess fájlból több is lehet egy weboldal könyvtárszerkezetében. Ha egy könyvtárba behelyezünk egy ilyen fájlt, akkor a benne szereplő beállítások a könyvtárra és az összes alkönyvtárára vonatkoznak, azaz öröklődik a hatás az almappákra is. A hatás megszakítható, ha az egyik almappába egy újabb htaccess fájlt készítünk, hiszen ilyenkor ettől a mappától kezdődően, a mappára és az almappákra, ennek a fájlnak a beállításai lesznek érvényesek, és ezek felülírhatják és bővíthetik is a mappa szerekezetben feljebbi szinten elhelyezkedő htaccess fájl beállításait. Ebből a lehetőségből adódik, hogy a htaccess fájlok használata leterheli a szervert, hiszen ilyenkor végig kell járnia minden mappát, és meg kell keresnie minden htaccess fájlt, hogy meghatározza, hogy a könyvtárra milyen beállítások vonatkoznak. Ez kevés felhasználónál nem érezhető, de egy oldalnak, amely nagy felhasználói bázissal rendelkezik, jelentős teljesítmény romlást jelenthet. A tanulást egy saját gépünkön futó szerveren kezdjük, hiszen itt nem okozhatunk semmi olyan problémát, aminek súlyos következményei lennének egy weboldalra. Egy ilyen gyorsan telepíthető ingyenes webszerver letölthető a weboldalról. A telepítésének menetébe most nem megyünk bele, de gondolom aki a htaccess fájlokkal foglalkozik, annak már nem okozhat különösebb fejtörést. Ha végül eljutunk arra a szintre, hogy feltöltsük a helyi szerveren már jól működő htaccess fájljainkat egy éles szerverre, akkor ezt ugyanolyan könnyedén megtehetjük egy FTP kliens segítségével, mint a weboldalunkhoz tartozó bármilyen más fájlt. Azonban ha egy régi létező fájlt szeretnénk lecserélni, akkor célszerű az eredetit nem felülírni, hanem átnevezni és megtartani, mert megeshet, hogy végül mégis inkább az eredeti beállításokra lenne szükségünk. SZINTAKTIKA: Amit tudnunk kell a htaccess fájl készítésénél, hogy a sorokat a szerver sorra egymás után értelmezi és minden sor egy beállítást tartalmaz. A #-el kezdődő sorok a megjegyzések, arra használhatjuk, hogyha egy későbbi időpontban amikor elővesszük szerkesztésre a fájlt, akkor könnyebb legyen az értelmezése. Szintén sokat segít olyankor, amikor egy új fejlesztő lép be a projektbe, így gyorsabban át tudja látni a dolgok menetét. Végül alkalmazható még olyankor is, amikor egy parancs, vagy egymás után akár több is jelenleg feleslegessé vált a fájlban, de a későbbiekben még szükségünk lehet rá, hiszen ilyenkor nem célszerű végleg kitörölni. Elég ha csak kikommentezzük, ilyenkor a rendszer figyelmen kívül hagyja, de ha esetleg újra használatba szeretnénk majd venni, akkor csak ki kell törölnünk előle a # jelet. Most akkor hozzunk létre egy.htaccess nevű fájlt weboldalunk gyökérkönyvtárába és írjunk bele egy érvénytelen utasítást. Ilyenkor felmerülhet, hogy nem tudunk.htaccess nevű fájlt létrehozni, mert az operációs rendszerünk nem engedi.

3 Ilyen esetben hozzunk létre egy egyszerű txt fájlt bármilyen névvel, és például Total Commanderrel nevezzük át. Ezek után nyissuk meg bármilyen szövegszerkesztővel. Én jegyzettömbbel nyitottam meg és az alábbi szöveget gépeltem bele értelmetlen utasítás gyanánt:

4 Most nyissuk meg a helyi webszerverünk címen, ahol az alábbihoz hasonló hibaüzenetet kell kapjunk, a hibás htaccess fájl miatt, ha van.htaccess támogatás a szerveren. Most, hogy tisztáztuk, hogy működik a htaccess a szerverünkön, töröljük ki a hibás htacces fájl tartalmát és mentsük el így. A következőekben módosítsunk a kevés információt nyújtó hibaüzeneteinken úgy, hogy létrehozunk sajátokat, amelyek részletesebb információt nyújtanak a hibáról, és amelyek segítségével több eséllyel marad a felhasználó az oldalunkon, ahelyett, hogy elmenne egy másik weboldalra azért a tartalomért, amit nálunk nem talált meg egy hiba folytán. Alapesetben egy 404-es hiba, amikor a felhasználó egy nem létező aloldalt próbált elérni a weboldalunkon, az így néz ki: Nem túl barátságos, és egy átlag felhasználó nem is biztos, hogy megérti, hogy most mi történik, sőt valószínűleg meg is rémíti az amit lát. Most készítsünk egy weboldalt mondjuk 404.html névvel és másoljuk bele az alábbi sorokat. <!doctype html> <html lang="hu"> <head> <meta charset="utf-8"> <title>az oldal nem található!</title> </head> <body> <h1>az oldal nem található!</h1> <p>ne essen kétségbe, valószínűleg elgépelte a webcímet,<br /> vagy idő közben elérhetetlenné vált a tartalom.</p> <p>kérjük próbálja meg később és ha továbbra is fenn áll a probléma,<br/> akkor írjon nekünk levelet: <a href="ambrus.attila.cz@gmail.com">itt</a>.</p> </body> </html>

5 Végül htaccess fájlunk tartalmát módosítsuk az alábbi sorral, amiből jól látható, a hibák átirányításának szerkezete: ErrorDocument parancs, ezt kövei a hibakód, majd lezárásként az oldal elérési útvonala, amit meg szeretnénk a hiba esetén jeleníteni. ErrorDocument 404 /404.html Most ha begépeljük a nem létező címet, akkor az alábbi hibaüzenetet kapjuk. Ez már sokkal jobb, persze a kinézetét és a tartalmát ízlés szerint módosíthatjuk igényeinknek megfelelően. A webszerverek általában az index.php fájlt nyitják meg alapértelmezetten, ha a weboldal egy almappájára hivatkozunk fájlnév nélkül. Ha ez nincs akkor az index.html -t próbálják megnyitni. Ezt az alapértelmezést könnyen megváltoztathatjuk a htaccess segítségével. Most készítsünk egy ezt.html nevű fájlt a szerver főkönyvtárába az alábbi tartalommal: <!doctype html> <html lang="hu"> <head> <meta charset="utf-8"> <title>ezt nyitjuk meg...</title> </head> <body> <h1>ezt nyitjuk meg...</h1> <p>az index.html helyett alapértelmezettként.</p> </body> </html> A htaccess fájl tartalmát pedig módosítsuk úgy, hogy az alábbi sor szerepeljen benne: DirectoryIndex ezt.html

6 Majd ha így megnyitjuk a webcímet a böngészőnkben, akkor hiába lesz index.html fájl a gyökérkönyvtárban mégis az ezt.html fájlt fogja megnyitni. Ez a beállítás az egész weboldalra vonatkozik így, de természetesen bármilyen alkönyvtárban is alkalmazhatjuk. Saját sorrendet is megadhatunk, ha szeretnénk. Például ha azt akarjuk, hogy elsőként a szerver a ezt.html -t keresse, majd ha ezt nem találja, akkor az index.php -t, majd ha ezt sem akkor az index.html -t, akkor az alábbi sort kell a fájlba lementenünk: DirectoryIndex ezt.html index.php index.html Ha kitöröljük az alapértelmezett fájlokat, akkor nem tud megnyitni a szerver semmit és általában hibát dob, vagy kilistázza a mappában található fájlokat. Ha azt szeretnénk, hogy amikor nem található alapértelmezett fájl a mappában, akkor 403-as hibát dobjon arról árulkodva, hogy nincs hozzáférésünk a mappához, akkor azt az alábbi sorral érhetjük el: Options Indexes Ha meg szeretnénk jeleníteni a könyvtár tartalmát, akkor a következő sort szúrjuk be. Options +Indexes Lehetőségünk van arra, hogy a listázásból bizonyos tartalmakat elrejtsünk, bizonyos kiterjesztésű képeket, konkrét nevű fájlokat, vagy mappákat.

7 Az alábbi parancsok hatására az index nélküli könyvtárak tartalma kilistázódik, de elrejtődik benne minden.gif és jpg kiterjesztésű kép, a szotar nevű mappa és a szoveg.txt fájlnévvel rendelkező fájl. Figyeljünk arra, hogy ezek a tartalmak csak a listázásból rejtődnek el, de egy konkrét webcím beütésekor megjelennek. Options +Indexes IndexIgnore *.gif *.jpg./szotar szoveg.txt Ha bizonyos fájljainkat jobban meg szeretnénk védeni, akkor elérhetjük azt, hogy a webszerver bizonyos fájljait kívülről ne lehessen elérni, de belülről a többi php-val tudjuk használni. Ehhez nem kell mást tenni, mint az alábbi két sort begépelni. A deny from all lesz az a sor, ami ténylegesen megtiltja az összes webes kérés kiszolgálását a mappára. Minden ilyen kéréskor egy 403-as hibaüzenet lesz megjelenítve. order allow,deny deny from all Lehetőség van a tiltást úgy alakítani, hogy ne mindenhonnan érkező kéréseket tiltson le így a htaccess, csak mondjuk egy konkrét IP címet, vagy IP tartományt. Itt jelenik meg az első sor jelentősége. Ez igazából a tiltás és az engedélyezés sorrendjét (order) határozza meg. Ebben az esetben az engedélyezés (allow) az alapértelmezett, tehát ha valamit nem tiltunk meg konkrétan, az engedélyezve lesz, valamint, ha valamire egyszerre vonatkozik megengedő és tiltó szabály, akkor a megengedés lesz az érvényes. Ha a deny szerepel a rendezésben hátul, akkor a tiltás az alapértelmezett, és amit nem engedélyezünk konkrétan, az tiltva lesz és az engedélyezés és a tiltás közül a tiltás szabálya lesz az erősebb. Tehát, ha valamit nem szabályozunk, vagy mindkét szabályt egyszerre alkalmazzuk rá, akkor az order sorrend szerinti alapértelmezés lesz a meghatározó. order deny,allow deny from

8 Tudjuk konkrét tartománynév alapján tiltani a kiszolgálást. order allow,deny allow from all deny from ezt.hu Vagy csak konkrétan egy tartomány felől érkező kéréseket engedélyezhetünk. order deny,allow deny from all allow from innenjohet.hu Megoldható az is, hogy egyes országokat kitiltsunk a szerverünkről. order allow,deny allow from all deny from fr Ez csak akkor működik, ha a felhasználó szolgáltatója automatikusan adja az LTD-t is. Így a mindennapokban használt módszer nem ez. Általában sűrűn karbantartott IP listákat használnak a tiltásra a webszerver fő konfigurációs fájljában, amik az országok IP cím tartományait tárolják. Ha ugyanezt htaccess-ben próbálnánk elérni, akkor az jelentősen lassítaná a szervert. Összefoglalásként leírom, hogy ha mindent engedélyezni szeretnénk akkor az allow from all -t használjuk, ha pedig mindent tiltani, akkor a deny from all -t. Ha szelektíven szeretnénk valamit engedélyezni, akkor az alábbi struktúrát használjuk: order deny,allow deny from all allow from eztengedelyezd.hu Ha pedig szelektíven tiltani: order allow,deny allow from all deny from ezttiltsdle.hu A többi kombináció csak bonyodalmat okoz. Ha olyan tartalmat szeretnénk feltenni, amit csak bizonyos felhasználók érhetnek el, akkor lehetőségünk van jelszavas védelemmel ellátni az oldalt. Ehhez a.htaccess fájlunk mellé készítenünk kell egy.htpasswd nevű fájlt is. A webszerverek általában nem engedik kívülről megtekinteni a.ht -vel kezdődő fájlokat így jelszavaink biztonságban vannak. Ez a fájl tárolja soronként azokat a felhasználókat, akik a későbbiekben hozzáférhetnek jelszavuk segítségével a mappa tartalmaihoz. A sorok szintaktikája a következő: felhasználónév:titkosított jelszó

9 Hogy előállítsuk ezt a fájlt, indítsuk el a Star menü -ben a Futtatás -on keresztül a cmd.exe -t. Ez a windows parancssor -t nyitja meg számunkra. Itt lépjünk be a xampp gyökerében található apache mappán keresztül a bin nevű mappába. Itt gépeljük be, hogy htp és nyomjunk egy tabulátort. Ha minden jól megy, akkor a parancssor kiegészíti nekünk htpasswd.exe -re. Ha nem, akkor szükségünk van egy jelszó titkosítóra.ne töltsetek le és telepítsetek egyet, csak ezért a számítógépetekre, hogy foglalja a helyet. Üssétek be a Google-be, hogy online htpasswd generator és az első találaton készítsetek egyet online. De mivel nekem megtalálta, ezért nem az online felületen, hanem a htpasswd.exe-vel generáltatok egyet, mert ez biztonságosabb, nem szerezhetik meg illetéktelenek az elkészítése közben. Az alábbi parancs fogja létrehozni a fájlt, az első felhasználóval. A c kapcsoló azt jelzi, hogy el kell készíteni a fájlt, ha nem létezik. A b kapcsoló azt hivatott megoldani, hogy ne kelljen kétszer begépelni a jelszót, hanem közvetlenül a parancsból kivegye a htaccess. Az m kapcsoló beállítja a titkosítás módját MD5-re, ami a htaccess-nél elérhető titkosítások közül a legbiztonságosabb, hiszen a jelszavakhoz hozzáfűz egy véletlenszerű szót is, így nehezebb őket visszafejteni. A következő paraméter annak a jelszó fájlnak az elérési útvonala és neve, amiben a jelszavakat szeretnénk tárolni. Majd ezt követi a felhasználónév, végül pedig a jelszó. htpasswd.exe -c -b -m C:\xampp\htdocs\.htpasswd CyberZero J3lsZo

10 Ha már létezik a fájl, akkor a c kapcsolót lehagyhatjuk. Most hozzunk létre egy második felhasználót. Fontos, hogy a több szóból álló felhasználóneveket és jelszavakat idéző jelek közé tegyük. htpasswd.exe -b -m C:\xampp\htdocs\.htpasswd "Agyalá Gyula" J3lsZo2 Ezek után a jelszavakat tartalmazó fájlunkban két felhasználónak kell lennie. Most nincs más dolgunk, mint beállítani a htaccess fájlt az alábbiak szerint. Az első sor a autentikációt alapszintűre állítja. A második sor a felhasználónevet és jelszót bekérő párbeszédpanelnek az üzenetét határozza meg. Ez nem jól jeleníti meg az ékezetes karaktereket, így azokat ne használjunk, vagy az ékezetes karakter helyére a rövid megfelelőjét írjuk, mögé pedig tegyünk be egy aposztróf jelet. A harmadik sor a jelszavakat tartalmazó fájl teljes elérési útját tárolja. Ez azért problémás, mert egy idegen szerveren nem feltétlenül tudjuk ezt az útvonalat. A későbbiekben majd elsajátítunk egy trükköt, ennek a kiderítésére. Végül a negyedik sor teszi lehetővé azt, hogy csak az érvényes felhasználókat engedje belépni az oldalra.

11 AuthType Basic AuthName "Jelszo'val ve'dett tartalom:" AuthUserFile C:\xampp\htdocs\.htpasswd require valid-user Érvényes felhasználónév és jelszó páros esetén megjelenik a védett tartalom, hibás esetén pedig addig kéri újból amíg jót meg nem adunk, vagy ki nem lépünk az ablakból. Ha kilépünk az ablakból, akkor a webszerver 401-es hibakóddal reagál. Ebben a párbeszédablakban megadott jelszó titkosítatlanul közlekedik az interneten, így lehallgathatják illetéktelenek. A felhasználók kezelésére ez a technika nem alkalmas, csupán arra használható, hogy olyan tartalmakat levédjük, amikhez kevés embernek kell hozzáférnie és fontosságuk nem életbevágó. Jobban is személyre szabható ez a bejelentkeztetés. Létrehozhatunk például csoportokat is. Ez akkor célszerű, ha a felhasználók egy csoportjának szeretnénk csak engedélyezni a belépést, és nem mindenkinek. Ilyenkor egy.htgroups fájlt kell létrehozni, amely sorosan tárolja a csoportok neveit, és mellettük a csoportba tartozó felhasználókat szóközökkel tagolva. Hozzunk létre egy fejleszto nevű csoportot a htgroups fájlba és vegyük fel a csoportba a már meglévő két felhasználónkat. fejleszto: CyberZero "Agyalá Gyula" Most vegyünk fel még egy felhasználót a.htpasswd fájlba, aki nem fog beletartozni a csoportunkba. htpasswd.exe -b -m C:\xampp\htdocs\.htpasswd galamb J3lsZo3 Végül írjuk át a htaccess fájlt úgy hogy csak a fejleszto csoport tagjait engedje a levédett tartalomhoz hozzáférni és vegyük fel a htgroups fájlt. AuthType Basic AuthName "Csoport ve'delem" AuthUserFile C:\xampp\htdocs\.htpasswd AuthGroupFile C:\xampp\htdocs\.htgroups require group fejleszto

12 Itt jól megfigyelhető, hogy a require parancs nem csak a valid-user, hanem a group szerint is tud autentikálni. Továbbá az is jól érzékelhető, hogy nem csak az összes felhasználóra, vagy az összes csoportra tudjuk engedélyezni a tartalmat, hanem akár egy részükre is. Felhasználók esetében a require user után fel kell sorolnunk az engedélyezett felhasználókat, csoportok esetén pedig a require group után fel kell sorolnunk az engedélyezett csoportokat. A htaccess segítségével alkalmazhatunk különböző átirányításokat. Az átirányításokhoz a szerver fő konfigjában engedélyezve kell, hogy legyen a mod_rewrite modul, ha ez mégsem így van, akkor az átirányításos parancsokat a szerver hibás parancsnak érzékeli és 500-as hibakóddal tér vissza. Lehetőség van a kódok IfModule blokkba helyezésére. Ilyenkor a modulban lévő parancsok csak akkor futnak le, ha a megfelelő feltétel teljesül, ha mégsem, akkor pedig nem dobnak hibát. <IfModule mod_rewrite.c> RewriteBase / </IfModule> A fent látható kódot akkor kell használjuk, ha nem tudjuk, hogy milyen szerverkörnyezetbe kerül a weboldalunk, így elkerülhetjük az esetleges hibákat. Én azonban nem fogom használni ezt a szerkezetet, hiszen a saját szerverünkről illik tudni, hogy fut-e rajta a modul, vagy sem. Az első sor lehetővé teszi a szimbolikus linkek követését. A szimbolikus linkek arra valók, hogy elválasszák a fájlok elméleti helyét a tényleges fizikai helyétől. A Linux felhasználóknak ez a kifejezés ismerős, a Windows felhasználók számára leginkább egy parancsikonhoz tudnám hasonlítani, csak nem az operációs rendszerben, hanem webes környezetben. Általában egyébként ennek a parancsnak a kiadása felesleges, hiszen a webszerver fő konfigurációs fájljában be van állítva, de azért jobb a békesség. A második sor az átirányítások bekapcsolásáért felelős. Az utolsó sor pedig az átirányítások bázisát határozza meg, azaz, hogy egy átirányításnál honnan kell figyelembe venni az átirányítás útvonalát. Alapértelmezésként ez mindig az a mappa amiben éppen állunk. A jelenlegi parancs a weboldalunk gyökerét teszi meg az átirányítások bázisának. Ez a három sor minden átirányításnál használatos. RewriteBase / Most például hozzunk létre egy index.html és egy kakao.html nevű fájlt és mindkettőben a saját fájlnevét mentsük el. Majd ezek után írjuk át a htaccess fájlt, úgy hogy ha az index.html nevű fájlt hívjuk meg, akkor a háttérben a kakao.html nyílik meg. Ezt a tevékenységet átírásnak nevezzük, hiszen a háttérben történik az egész és a felhasználó nem vesz a címsorban belőle észre semmit. Így könnyen alakíthatunk ki keresőbarát, illetve könnyen megjegyezhető url-eket. Tökéletes példa erre, amikor a felhasználó azt írja be a címsorba, vagy egy linkre kattintva azt látja, hogy a betöltött oldal a de igazából a töltődött be, csak nem tud róla. Vagy amikor a feliratot látja a címsorban, de igazából a jatekok.php-t hívja meg az?id=kepkirako paraméterrel, amely segítségével egy adatbázisból dinamikusan töltjük fel az oldalt az id-nak megfelelően.

13 A jelenlegi egyszerű átírásunknál fontos, hogy létezzen a kakao.html nevű állomány, különben a htaccess hibát ad eredményül. RewriteBase / RewriteRule ^index\.html$ kakao.html Ezek után hívjuk meg a címsorban a oldalt és mégis a kakao.html feliratot fogjuk látni a weboldalon, hiszen a háttérben a kakao.html töltődött be az index.html helyett. A másik tevékenység az átirányítás. Az átirányításokat, az átírásokkal ellentétben, a felhasználó látja. Ezzel jelezzük a felhasználó számára, hogy az eredeti oldal helyett, amit várt, egy másikat kapott. Ez akkor jön jól, ha az oldalunkat átalakítottuk, vagy elköltöztettük és a felhasználó egy régi link-re kattint, ami idő közben megszűnt. Ilyenkor a webszerver átirányítja az általunk beállított urlre. Ráadásul a keresőknél hibapontot jelentenek a megszűnt oldalak, ezeket az átirányításokkal könnyedén kezelhetjük. Az átirányítások további előnye hogy a weboldalak gyakran ugyanazzal a tartalommal megjelennek www-s, és www nélküli útvonalakon is, ami duplikációt jelent és a keresők negatívan értékelik. Ilyenkor célszerű az egyiket kiválasztani weboldalunk számára, a másikat pedig erre átirányítani. Most írjuk át a htaccess parancsainkat úgy, hogy ne átírja, hanem átirányítsa az index.html-ről a webezőt a kakao.html-re. Ehhez nem kell semmi egyebet tennünk, minthogy az utolsó parancs végéhez hozzáfűzzük a [R] jelölést, ami a 302-es kódú ideiglenes átirányítást jelenti. Ezt használhatjuk, ha a tartalom csak ideiglenesen lett átirányítva. Végleges átirányításhoz az [R=301] jelölést kell használni a sima [R] helyett. RewriteBase / RewriteRule ^index\.html$ kakao.html [R]

14 Most ha megnyitnánk a url-t, akkor a htaccess átirányítana a kakao.html-re, ahogy azt az alábbi képen is láthatjuk. Most hogy tovább haladjunk elemezzük ki az előbbi példákban használt reguláris kifejezéseket, amelyek sokat segítenek nekünk a továbbiakban is. RewriteRule ^index\.html$ kakao.html [R] Ebben a sorban három ilyen jelölő van. A ^ egy kezdeti illeszkedés jelez, tehát minden olyan szóra igaz, ami index kifejezéssel kezdődik. A $ egy hátsó illeszkedést jelez, tehát minden olyan szóra igaz, aminek html a vége. A. egy olyan speciális jelölés, amire minden illeszkedik. Mivel most nem erre van szükségünk, hanem ténylegesen csak egy pontra, ezért a \ jellel tudjuk levédeni, hogy eredeti szerepét töltse be. A. karakter jelöl egy darab tetszőleges karaktert. A () jelek közötti szöveget egy karaktersorozatnak tekinti, ami összetartozik. A? jelöli az előtte levő karakter, vagy zárójeles kifejezés szereplését 0-szor vagy 1-szer. A * jelöli az őt megelőző karakter vagy zárójeles kifejezés legalább 0-szor, legfeljebb akárhányszor való szereplését. A + jelöli az őt megelőző karakter vagy zárójeles kifejezés legalább 1-szer, legfeljebb akárhányszor való szereplését. A [] jelben felsorolt karakterek csoportjából 1 darab tetszőleges karaktert jelöl. Például [azd] esetén vagy a -t, vagy z -t, vagy d -t. A speciális karakterek a [] között önmagukat jelentik és elveszítik speciális jelentésüket. Például a [.?*+] egy pontot, vagy kérdőjelet, vagy csillagot, vagy plusz jelet jelöl. A jel egy [] belül az őt közrefogó két karakter közé tartozó karakterosztály 1 tagját jelenti. Például a [0-9] egy számjegyet, [a-z] egy kis betűt, [A-Z] egy nagy betűt, [a-za-z] egy tetszőleges karaktert az angol ABC-ből, ami lehet kicsi és nagy is. A ^ jel a [] jeleken belül a mögötte álló értékek inverzét jelenti. Például a [^abc] bármilyen karaktert jelölhet, az a -n, a b -n, vagy a c -n kívül. Vagy a [^0-9] bármilyen karaktert a számjegyeken kívül. A jel két vagy több dolog közüli választást tesz lehetővé. Például az (ablak ajtó) vagy az ablak -ot, vagy az ajtó -t. Vannak további reguláris jelölők, de a jelenlegieknek is számtalan kombinációja létezik és ezek is bőven elegendőek lesznek számunkra.

15 Egy másik példával élve, hozzuk létre a hirek.php nevű fájlt a weboldalunk gyökerében az alábbi tartalommal. A következő php kód az url címből átveszi az id paramétert, és ennek alapján jeleníti meg az oldalt. <?php $asd=$_get['id']; if($asd!='') echo "A weboldal a(z) $asd paraméterrel lett megnyitva.";?> A htaccess fájlunkban pedig alkalmazzuk a következő parancsokat: RewriteBase / RewriteRule ^hirek/(.*)/?$ hirek.php?id=$1 Így ha a weboldalt nyitjuk meg a böngészőben az valójában egy átírása a weboldalnak. Elemezzük egy kicsit ki a következő kifejezést: RewriteRule ^hirek/(.*)/?$ hirek.php?id=$1 A.* kombináció bármilyen karaktert tetszőleges számban jelent, azaz egy tetszőleges szöveget. A () jelek második fontos szerepe, amit még nem említettünk a korábbiakban az, hogy képesek változóba menteni a tetszőleges szöveget. A /? azt jelenti, hogy a / jel azon a helyen 0-szor, vagy 1-szer szerepelhet. Mivel ezt $ jel követi ezért a / jel a kifejezés végén szerepelhet 0-szor, vagy 1- szer. Így összegezve tehát egy hirek/ el kezdődő tetszőleges szöveg, aminek a végén lehet 1 darab / jel, de nem kötelező, hogy legyen. Mindezt úgy, hogy a tetszőleges szöveget 1 változóba mentettük.

16 A $1 kifejezés a végén, az első elmentett változót jelenti. Azaz minden az előzőeknek megfelelő kifejezést átirányítunk a hirek.php?id= elmentett változó kifejezésre. Ilyen változóból nem csak egyet, hozhatunk létre. Jelölésük a $ jelből és a változó sorszámából áll. Tehát a 3. változót $3-al jelöljük. Ebben az esetben a és a is a címre irányítódik át. A /? így láthatóan abban segít, hogy az elmentett változóba a két / jel közötti tetszőleges szöveg mentődjön el. Ha a /? lemaradna a htacess parancsból, így az alábbi sornak megfelelően nézne ki, akkor mondjuk egy esetén az elmentett változóba az asd/qwe kifejezés kerülne és így hibás lenne az átírás, hiszen a -re mutatna. RewriteRule ^hirek/(.*)$ hirek.php?id=$1 A RewriteRule utasításnál a mit irányítunk át rész csak a hosztnév utáni résztől kezdődhet és a paraméterek már nem tartoznak bele. Tehát ezek a reguláris kifejezések egy url-ben csak az teszt/index.php részt látja. Ez nagyon lekorlátozna minket, de szerencsére rendelkezésünkre állnak feltételes átirányítási lehetőségek. Az alábbi példában, ha a hosztnév sima, azaz nincs benne www, akkor átirányítjuk a felhasználót a www-t tartalmazó URL-re. Ezt a RewriteCond, átirányítás feltétel paranccsal tudjuk megtenni. A % után lévő {} jelek között található a feltétel alapjául szolgáló kifejezés, jelen esetben a hosztnév, majd ezt követi a reguláris kifejezés, ami a feltételt írja le. Ezt egy [] jelek között lévő flag zárja példánkban. Ez az NC flag arra való, hogy a kis és nagy betűk között ne tegyen különbséget a feltétel. RewriteCond %{HTTP_HOST} ^cyberzero\.tk [NC] RewriteRule ^(.*)$ [R=301] Összegezve tehát, ha a cyberzero.tk/qwe/asd/index.php?id=100 url-t gépeljük be a böngészőbe, akár kis, akár nagy, akár vegyes méretű betűkkel, akkor ebből a linkből kimenti egy változóba a hoszt név utáni részt a paraméterek kezdetéig (tehát a paramétereket, már nem), majd végleges átirányítással átirányítja a -ra úgy, hogy hogy hozzáteszi a változóba elmentett részt, tehát a cyberzero.tk/qwe/asd/index.php?id=100 -ról a -ra irányít. Visszatérve a feltétel alapjára, még számtalan hozzá hasonló beépített feltétel létezik: API_VERSION, AUTH_TYPE, CONTENT_LENGTH, CONTENT_TYPE, DOCUMENT_ROOT, GATEWAY_INTERFACE, HTTPS, HTTP_ACCEPT, HTTP_ACCEPT_CHARSET, HTTP_ACCEPT_ENCODING, HTTP_ACCEPT_LANGUAGE, HTTP_CACHE_CONTROL, HTTP_CONNECTION, HTTP_COOKIE, HTTP_FORWARDED, HTTP_HOST, HTTP_KEEP_ALIVE, HTTP_PROXY_CONNECTION, HTTP_REFERER, HTTP_USER_AGENT, IS_SUBREQ, ORIG_PATH_INFO, ORIG_PATH_TRANSLATED, ORIG_SCRIPT_FILENAME, ORIG_SCRIPT_NAME, PATH, PATH_INFO, PHP_SELF, QUERY_STRING, REDIRECT_QUERY_STRING, REDIRECT_REMOTE_USER, REDIRECT_STATUS, REDIRECT_URL, REMOTE_ADDR, REMOTE_HOST, REMOTE_IDENT, REMOTE_PORT, REMOTE_USER, REQUEST_FILENAME, REQUEST_METHOD, REQUEST_TIME, REQUEST_URI, SCRIPT_FILENAME, SCRIPT_GROUP, SCRIPT_NAME, SCRIPT_URI, SCRIPT_URL, SCRIPT_USER, SERVER_ADDR, SERVER_ADMIN, SERVER_NAME,

17 SERVER_PORT, SERVER_PROTOCOL, SERVER_SIGNATURE, SERVER_SOFTWARE, SSL_CIPHER, SSL_CIPHER_ALGKEYSIZE, SSL_CIPHER_EXPORT, SSL_CIPHER_USEKEYSIZE, SSL_CLIENT_VERIFY, SSL_PROTOCOL, SSL_SERVER_A_KEY, SSL_SERVER_A_SIG, SSL_SERVER_CERT, SSL_SERVER_I_DN, SSL_SERVER_I_DN_C, SSL_SERVER_I_DN_CN, SSL_SERVER_I_DN_L, SSL_SERVER_I_DN_O, SSL_SERVER_I_DN_OU, SSL_SERVER_I_DN_ST, SSL_SERVER_M_SERIAL, SSL_SERVER_M_VERSION, SSL_SERVER_S_DN, SSL_SERVER_S_DN_CN, SSL_SERVER_S_DN_O, SSL_SERVER_S_DN_OU, SSL_SERVER_V_END, SSL_SERVER_V_START, SSL_SESSION_ID, SSL_VERSION_INTERFACE, SSL_VERSION_LIBRARY, THE_REQUEST, TIME, TIME_DAY, TIME_HOUR, TIME_MIN, TIME_MON, TIME_SEC, TIME_WDAY, TIME_YEAR, TZ, UNIQUE_ID. A leggyakrabban használatosak közül most megmagyarázok párat. A HTTP_USER_AGENT segítségével lekérdezhetőek a felhasználó böngészőjének adatai. Például: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/ Firefox/ A HTTP_REFERER-el megtudhatjuk, hogy melyik oldalról lépett át ránk a felhasználó, a HTTP_HOST az elérési útvonal, ahogy a felhasználó begépelte a böngészőbe a weblapunk címét, vagy ahogy egy link hivatkozott ránk. A REMOTE_ADDR megadja a felhasználó IP-címét, a REMOTE_HOST pedig a hosztnevét. A QUERY_STRING megadja a paramétereket is, amikkel ránk hivatkoztak, tehát a? utáni részek a cyberzero.tk/qwe/asd/index.php?id=100 url-ben. A TIME_YEAR, TIME_MON, TIME_DAY, TIME_HOUR, TIME_MIN, TIME_SEC, és a TIME_WDAY, TIME a szerver idő különböző részeinek vizsgálatára valók. A THE_REQUEST a böngésző által küldött teljes kérést figyeli, például GET /index.php HTTP/1.1, a REQUEST_URI pedig az url-t adja meg a hoszt név nélkül. Ezekkel már számtalan feltételt létrehozhatunk. Például kitilthatjuk a botokat, tilthatjuk a képeink más oldalba való illesztését, átirányíthatjuk a www nélküli oldalunk a www-sre. IP vagy HOST név alapján különböző nyelvű oldalakra irányíthatunk, feldolgozhatjuk a paramétereket is, az időpontoktól függő átirányításokat végezhetünk egy előre meghatározott időintervallumban, tilthatjuk a POST-ot vagy a GET-et... Megemlítettük a flag-eket. Ezekből is több van: C, CO, E, F, G, H, L, N, NC, NE, NS, P, PT, QSA, R, S, T és az AND és az OR. Idáig az R és az NC flag-eket vizsgáltuk. Ha több feltételt szeretnénk egyszerre alkalmazni, akkor jól jön a kapcsolatuk meghatározására az AND és az OR. Ha azt szeretnénk, hogy akkor történjen átirányítás, amikor mindkét feltétel egyszerre teljesül, akkor [AND] flag-el kell őket összekapcsolni. Ha pedig azt szeretnénk, hogy akkor történjen átirányítás, ha legalább vagy az egyik vagy a másik teljesül, akkor az [OR] flag-et kell használni. Több flag együtt való alkalmazásakor a flag-eket a [] jeleken belül vesszővel kell elválasztani egymástól. Például: [NC,OR]. A feltételeknél használhatunk reguláris kifejezéseken kívül <,>, és = jeleket is, de vigyáznunk kell. A relációs jelek ABC sorrendben rendeznek, tehát az 1>2, de a 111<2 az értéke hiába nagyobb.

18 A RewriteCond-ban is menthetünk el változókat, amiket tovább vihetünk a RewriteRule-ba. Például, ha aldomain-eket szeretnénk kezelni. Tegyük fel, hogy azt szeretném, hogy amikor a címet beütöm a böngészőbe, akkor az igazából a címre irányítson. Ezt egy RewriteCond változó átvitelével érjük el a RewriteRule-ba. Továbbá, mivel azt szeretnénk, hogy a hosztnév mögötti részt is megjegyezze, ezért elmentünk egy külön változót a RewriteRule-ban is. A két változó típus nem zavarják meg egymást, jól működnek együtt. A különbség a kettő között csak az, hogy amíg a Rule-os eredményét $ jellel hívjuk meg, addig a Cond-osat % jellel. Ilyenkor a cím a címre irányítódik át. Azonban még mielőtt kipróbálnák az alábbi parancsokat, fontos tudniuk, hogy ilyenkor a htaccess önmagában nem elég, megfelelően be kell állítaniuk az aldomain DNS rekordját. RewriteCond %{HTTP_HOST} ^(.*)\.cyberzero\.hu [NC] RewriteRule ^(.*)$ [L] A korábbiakban megígértem, hogy megosztok egy trükköt a jelszó fájl teljes elérési útjával kapcsolatban. Ehhez egy kicsit jobban elő kell vegyük a RewriteBase-t. Első esetünkben tegyük fel, hogy az átirányításunknak nincs alapja, tehát nincs RewriteBase parancs. Most a főkönyvtárban lévő index1.php -t szeretnénk átirányítani az admin mappában található index2.php -re. Ilyenkor a második részben teljes útvonalat kell megadjunk: /admin/index2.php. RewriteRule ^index1.php$ /admin/index2.php [R,L] Most tegyük fel, hogy a főkönyvtárunk szolgál az átirányítás bázisául és a főkönyvtárban szereplő index1.php -t szeretnénk átirányítani a szintén főkönyvtárban lévő index2.php -re. RewriteBase / RewriteRule ^index1.php$ index2.php [R,L] Harmadik esetünkben az admin alkönyvtárban lévő index1.php -t szeretnénk átirányítani, ugyanabban az alkönyvtárban lévő index2.php -re, úgy hogy az átirányítás bázisa az /admin. RewriteBase /admin RewriteRule ^index1.php$ index2.php [R,L]

19 És akkor jöjjön a trükk. Mi van akkor, ha nem létező fájlokkal játsszuk el ugyanezt, úgy, hogy nem adunk meg az átirányításnak bázist. Jelen példánkban az index3000.php -t irányítanánk át az index4000.php -re. Azonban mivel ezek nem léteznek, a webszerver 403-as, vagy 404-es hibát dob. RewriteRule ^index3000.php$ index4000.php [R,L] Nem ez az érdekes, hanem amit a címsorban látunk. Próbáljuk betölteni a -t. A htaccess átirányítana az index4000.php -re, de nem tud, mivel nem létezik. És ekkor bekerül a következő szépség a címsorba: Ilyenkor máris megvan a kívánt teljes elérési út. Jelen esetben a C:/xampp/htdocs/ cím. Figyeljünk oda, hogy ilyen hibát sohase hagyjunk egy éles weboldalon, hiszen ez nagyon megkönnyíti a hacker-ek dolgát. Ezt a hibát is gyorsan távolítsuk el! Ilyen trükkökből a htaccess számtalan lehetőséget rejt magában. Például vegyük szemügyre az alábbi átirányítást. Ez a parancskombináció a -t átirányítja a -re. A -t átirányítja a -re. Rewritebase / RewriteRule ^index\.php$ index2.php

20 Azonban, ha azt szeretnénk, hogy a paraméterek ne irányítódjanak át, akkor a megoldás egy aprócska kis kérdőjel a RewriteRule végére. Így mind a mind a esetében a paraméterek nélküli -re irányít. Rewritebase / RewriteRule ^index\.php$ index2.php? Korábban használtunk egy [L] flag-et, anélkül, hogy megmagyaráztuk volna. A korábbi példákban ugyan semmi jelentősége nem volt, de most kitérünk a viselkedésére. Fontos, hogy az átirányítási szabályokból ha egyszerre többet is alkalmazunk, akkor az átírások nem állnak le az első alkalmazott szabály után, hanem a szabályok végéig végrehajtódnak. Ez nem mindig célszerű. Az ilyen esetekben alkalmazzuk az [L] flag-et, ami azt jelzi, hogyha a vele egy sorban lévő szabály lefutott, akkor az volt az utolsó, és a többi nem kerül végrehajtásra. Az R flag-hez hasonló az F és a G flag is, amikről még jó, ha fogalmunk van. Az F a letiltott tartalmak jelzésére szolgál, használatakor a szerver 403-as hibaüzenetet dob. Jól jön például a letölthető exe kiterjesztésű fájlok tiltásához. RewriteRule \.exe - [F] A G flag pedig a megszűnt tartalmat jelenti, melynek használatakor a szerver 410-es üzenetet dob. Jól jön egy megszűnt oldal jelölése esetén. RewriteRule cyberzero.tk/letoltesek/ - [G] Az előző két példában célként a jelet adtuk meg. Ez azt jelenti, hogy az előtte levő mintára egyező weboldalakat, nem egy másik oldalra, hanem önmagukra irányítjuk. Ezt az opciót akkor is alkalmazhatjuk, ha azt szeretnénk, hogy egy oldal kivétel legyen az átirányítási szabályok alól. Például hozzunk létre egy index99, egy index_99, egy index100 és egy index_100.php -t, majd mindegyikbe a fájlnevét írjuk be. Most hozzunk létre egy olyan szabályt, ami bármilyen index -el kezdődő és a végén tetszőleges számjegyet tartalmazó.php fájlt átír az aláhúzásjeles változatára. Tehát például a -t a -re. Tegyük fel, hogy azt szeretnénk, hogy az index100.php ez alól kivételt képezzen. Ennek érdekében tegyünk be az átirányítási szabályok legelejére egy önmagára irányító [L] flag-es szabályt. Így az index100.php esetén, megfelel az első szabálynak, és mivel [L] flag-es, ezért a többi szabály nem vonatkozik rá és az önmagára irányítás miatt nem történik vele semmi, de az index99.php esetén ugyanúgy átír az index_99.php -ra. Rewritebase / RewriteRule ^index100\.php - [L] RewriteRule ^index([0-9]*)\.php$ index_$1.php?

21 index100.php: index99.php:

22 A feltételes átirányítással lehetőségünk van olyanra, hogy megvizsgáljuk egy könyvtárról, vagy egy fájlról, hogy az ténylegesen létezik-e. Ennek a létezésének a vizsgálatára %{REQUEST_FILENAME} feltétel használható. Fájl esetén a -f, mappa esetén a -d kapcsolókkal. Az alábbi példában a! jel a feltétel ellentétének vizsgálatára való. Az alábbi parancsok hatására a feltétel szerint, ha NEM létezik a kérésnek megfelelő fájl és mappa sem, akkor átír egy kezdő oldalra, az index.php -re. Például a nem létező oldalt átírja a -re, de minden mást, ami létező, azt nem módosítja. Rewritebase / RewriteCond %{REQUEST_FILENAME}!-f RewriteCond %{REQUEST_FILENAME}!-d RewriteRule ^.*$ /index.php [L] Most akkor vegyünk át pár alap htaccess beállítást, amik bármikor jól jöhetnek. Ezek mind az alábbi sorokkal kezdődnek. Megadjuk, hogy először az index.php -t próbálja megnyitni a webszerver, majd ha ezt nem találja, akkor az index.html -t. Megtiltjuk a könyvtárak kilistázását és engedélyezzük a szimbolikus linkek követését. Bekapcsoljuk az átirányítást és az alapját a weboldal gyökérkönyvtárára állítjuk. DirectoryIndex index.php index.html Options -Indexes RewriteBase /

23 Ha egy régi oldalt át szeretnénk írni egy újra (paraméterek nélkül): Rewriterule ^regioldal\.php$ ujoldal.php [L] Ha egy régi oldalt át szeretnénk irányítani egy újra (paraméterek nélkül): Rewriterule ^regioldal\.php$ ujoldal.php [R=301,L] Ha egy régi oldalt át szeretnénk írni egy újra egy konkrét paraméterével: RewriteCond %{QUERY_STRING} ^id=1$[nc] RewriteRule ^regioldal\.php$ ujoldal.php [L] Ha egy régi paraméteres oldalt át szeretnénk írni egy újra a paraméterei nélkül: RewriteCond %{QUERY_STRING} ^id=1$ [NC] RewriteRule ^regioldal\.php$ ujoldal.php? [L] Ha egy régi paraméteres oldalt át szeretnénk írni egy kibővített paraméterekkel rendelkező újra: RewriteCond %{QUERY_STRING} ^id=1$ [NC] RewriteRule ^regioldal\.php$ ujoldal.php?id=1&type=2 [L] Az utóbbi problémára a másik lehetőség a [QSA] flag használata, amely a paraméter szöveg hozzáírásáért felelős: RewriteCond %{QUERY_STRING} ^id=1$ [NC] RewriteRule ^regioldal\.php$ ujoldal.php?type=2 [QSA,L] Ha minden weboldalt át szeretnénk irányítani egy szintén a szerveren levő másik weboldal főoldalára: Rewriterule.* [R=301,L] Ha csak egy konkrét weboldalt szeretnénk átirányítani egy szintén a szerveren levő másik weboldal főoldalára: RewriteCond %{HTTP_HOST} ^regiweblap\.hu$ [NC] Rewriterule.* [R=301,L] Ha minden weboldalt át szeretnénk irányítani egy szintén a szerveren lévő másik weboldalra változatlan link szerkezettel: Rewriterule (.*) [R=301,L] Ha csak egy konkrét weboldalt szeretnénk átirányítani egy szintén a szerveren levő másik weboldalra változatlan link szerkezettel: RewriteCond %{HTTP_HOST} ^regiweblap\.hu$ [NC] Rewriterule (.*) [R=301,L]

24 Egy weblap www nélküli változatát szeretnénk átirányítani a www-s változatára: RewriteCond %{HTTP_HOST} ^weblap\.hu [NC] RewriteRule ^(.*)$ [R=301] Egy weblap www-s változatát szeretnénk átirányítani a www nélküli változatára: RewriteCond %{HTTP_HOST} ^ [NC] RewriteRule ^(.*)$ [R=301] Ha egy megszűnt weboldal egy alkönyvtárát átirányítanánk a főoldalra: RewriteRule ^alkonyvtar/.* /? [R=301,L] Ha egy megszűnt weboldal egy alkönyvtárát átirányítanánk egy másik alkönyvtárra: RewriteRule ^alkonyvtar/.* /alkonyvtar2/? [R=301,L] Ha egy megszűnt weboldal egy alkönyvtárát átirányítanánk egy másik alkönyvtárra változatlan link szerkezettel: RewriteRule ^alkonyvtar1/(.*) /alkonyvtar2/$1 [R=301,L] Ha egy megszűnt weboldalt át szeretnénk irányítani egy konkrét paraméterével: RewriteCond %{QUERY_STRING} id[nc] RewriteRule ^regioldal\.php$ ujoldal.php [L] Ha egy megszűnt weboldalt át szeretnénk irányítani az új keresőbarát szerkezetű weboldalunkra, például a regioldal.php?id=1 -t az új ujkonyvar/1/ -re: RewriteCond %{QUERY_STRING} id=(.*) [NC] RewriteRule ^regioldal\.php$ /ujkonyvtar/%1/? [L] A keresőbarát url-ek kialakításához kell még pár plusz sor az alábbi 5 alapsoron kívül: DirectoryIndex index.php index.html Options -Indexes RewriteBase /

25 Ilyen esetben az index.php-ket önmagukra irjuk át, tehát ők kivételek. Az összes többi nem létező fájlt és mappát szintén az index.php-ra írjuk át. Az összes többi létező fájlt és mappát nem írjuk át semmire, meghagyjuk önmagának. Ha ezeket a parancsokat nem vennénk fel pluszban, akkor a képeket, css és js fájlokat is átírná, ami nem kívánt eredményhez vezetne. RewriteRule ^index\.php$ - [L] RewriteCond %{REQUEST_FILENAME}!-f RewriteCond %{REQUEST_FILENAME}!-d RewriteRule. /index.php [L] Egy szintű weboldalak keresőbaráttá alakítása: RewriteRule ^(.+)/?$ index.php?url=$1 [L] Legfeljebb 4 szintű weboldalak keresőbaráttá alakítása: RewriteRule ^(.+)/(.+)/(.+)/ (.+)/?$ index.php?p1=$1&p2=$2&p3=$3&p4=$4 [L] RewriteRule ^(.+)/(.+)/(.+)/?$ index.php?p1=$1&p2=$2&p3=$3 [L] RewriteRule ^(.+)/(.+)/?$ index.php?p1=$1&p2=$2 [L] RewriteRule ^(.+)/?$ index.php?p1=$1 [L] A fentebbi kódban p1-től p4-ig vannak a paraméterek, azaz a weboldal szintjei. Ezeket, az általam már korábban leírt, php kód átalakításával, könnyedén le lehet kezelni. Ha tetszőlegesen sok weboldal szintre szeretnénk átalakítani ezt a kódot, akkor a paramétereket nem tudjuk átadni rendesen. Ilyenkor az alábbi htacces parancsok alkalmazása mellett a paramétereket php-ben kell kiolvasnunk a $_SERVER['REQUEST_URI'] globális változó segítségével: RewriteRule. /index.php [L] Ha a fentebbi keresőbarát url-ekre átíró kódokat önmagukban szeretnénk használni, anélkül, hogy a létező könyvtárak és fájlok átírását tiltanánk, akkor a fentebb már említett plusz négy sorból a RewriteRule ^index\.php$ - [L] sort tartsuk meg. Tehát az átírások eleje ez legyen: DirectoryIndex index.php index.html Options -Indexes RewriteBase / RewriteRule ^index\.php$ - [L] Ha meg szeretnénk tiltani, hogy képeinket egy másik weboldal használja, és helyette egy vicces képet jelenítenénk meg számukra: RewriteCond %{HTTP_REFERER}!^$ RewriteCond %{HTTP_REFERER}!^ [NC] RewriteRule.*\.(jpg jpeg gif png)$ [R,NC]

26 Tehát, ha a ránk hivatkozó oldal nem üres és nem mi vagyunk, akkor a jpg, jpeg, gif és png kiterjesztésű képek helyett a vicces.jpg-t szolgálja ki a weboldaluknak. Sajnos ezt a ránk hivatkozó oldal kikerülheti, ha a hivatkozó oldal-t meghamisítja és üres url-t mutat. Ha minden aldomain-ünk egy szerveren szeretnénk tárolni különböző könyvtárak alatt (az aldomain-ek DNS rekordjait is ennek megfelelően kell beállítani), átírással: RewriteCond %{HTTP_HOST} ^(.*)\.oldalunk\.hu [NC] RewriteRule ^(.*)$ [L] Ha minden aldomain-ünk egy szerveren szeretnénk tárolni különböző könyvtárak alatt (az aldomain-ek DNS rekordjait is ennek megfelelően kell beállítani), átirányítással: RewriteCond %{HTTP_HOST} ^(.*)\.oldalunk\.hu [NC] RewriteRule ^(.*)$ [R=301,L] Az index.php konkrét elérésének letiltása átirányítással, például az oldalunk.hu/index.php -t ha valaki beüti a böngésző címsorába, akkor irányítsa át az oldalunk.hu/ -ra: RewriteCond %{THE_REQUEST} index\.php RewriteRule ^index\.php/?$ [R=301,L]