Kezdő útmutató a .htaccess számára a tervezők és fejlesztők számára

A webkiszolgáló testreszabására szolgáló számos különböző eszköz közül a .htaccess config fájl hatalmas eszköz. tudsz gyorsan visszaállíthatja a dokumentumtípusokat, elemző motorokat, URL átirányításokat, és számos más fontos funkciót. Azok a webmesterek, akik nem túl technikai jellegűek, esetleg nem kerülhetnek a saját .htaccess fájljának kezelésére. De a téma maga is lenyűgöző és érdemes néhány vizsgálatot.

Ehhez a cikkhez szeretnék bemutatni a webmesterek és a webfejlesztők célzottabb koncepcióit. Bárki, aki saját webhelyüket az Apache szerveren biztosan meg akarja érteni, hogyan kell kezelni a .htaccess fájlt. Azt sok testreszabhatóságot biztosít és az bármilyen web-nyelven dolgozhat PHP-től Ruby-hoz.

A hozzászólás alján hozzáadtam néhány külső weblapot segítsen az újonnan érkezőknek dinamikusan létrehozni .htaccess fájljukat.

Miért használjon .htaccess fájlt?

Ez egy nagy kérdés, és talán el kell kezdeni válaszolva “mi az .htaccess fájl”? Ez egy nagyon különleges konfigurációs fájl, amelyet az Apache webszerver használ. A .htaccess fájl meg tudja mondani a webszervert hogyan lehet bemutatni az információ különböző formáit és hogyan kezeljük a különböző HTTP kérések fejlécét.

Tényleg ez egy eszköz decentralizálás webszerver beállításainak megszervezése. Egy fizikai kiszolgáló 50 különböző webhelyet tartalmazhat saját .htaccess fájljával. Sok hatalmat ad a webmestereknek, ami egyébként lehetetlen lenne. De miért kellene ezt használni?

A legnagyobb ok a biztonság. tudsz zárjon ki bizonyos könyvtárakat, vagy védje meg őket. Ez nagyszerű a magánprojektek vagy új tartalomkezelő rendszerek számára, ahol egy kis extra biztonságot szeretne. Vannak azonban olyan gyakori feladatok is, mint a 404 hibaüzenetek átirányítása egy adott weboldalra. Ez csak egy sor kódot vesz igénybe és ez jelentősen befolyásolhatja, hogy a látogatók hogyan reagálnak a hiányzó oldalakra.

Őszintén szólva nem sokat mondhatok, hogy meggyőzzem másokat arról, hogy egy .htaccess fájl megérthető. Amint meglátja, hogy az akcióban van, akkor felismerheti mindazokat az értékeket, amelyek e kis konfigurációs fájlból származnak. Azt is remélem, hogy a cikk többi része bemutathat néhány betekintő témát, amellyel a webmesterek a .htaccess konfigurációjának fényében is megjelenhetnek.

Hozzáférés engedélyezése / megtagadása

Lehetőség van a potenciális spam látogatók felismerésére és megtagadni őket a webhelyére. Ez egy kicsit szélsőséges lehet, de ha tudod, hogy egy személy vagy emberek csoportja célzott a webhelyeden, néhány lehetőség közül választhatsz. Kiválaszthat egy domain-átirányítást, hogy megtagadja vagy tiltja a látogatókat egy IP-cím alapján.

a megrendelés engedélyezése, megtagadja a megtagadást a 255.0.0.0-tól a 123.45.6. engedje meg mindent

Ezek a mintakódok átmásolódtak a Htaccess Guide-ból, mivel ezek a tökéletes sablon az indításhoz. Megjegyzés: a második IP-cím hiányzik a 4. egész szám. Ez a kódblokk az első IP-t (255.0.0.0) és minden IP-t célozza meg a 123,45,6,0-255 tartományban, majd engedélyezze az összes többi forgalmat. A webmesterek nem használhatják ezt olyan gyakran, mint más technikák, de hasznos megérteni.

A címjegyzéklista megakadályozása

Vannak idők, amikor egy nyitott könyvtár van beállítva, hogy alapértelmezés szerint engedélyezze a böngészést. Ez azt jelenti, hogy a felhasználók megtekinthetik a belső címtárstruktúrában felsorolt összes fájlt, például a képek mappáját. Egyes webmesterek nem szeretnék engedélyezni a címjegyzéket, és szerencsére a kódrészlet nagyon könnyen emlékezhető.

Beállítások -Indexes

Láttam, hogy ez a válasz számtalan alkalommal jelent meg a Stack Overflow-ban, és ez lehet az egyik legegyszerűbb .htaccess-szabály, amire emlékszem.

Lehetséges, hogy valójában hozzon létre több .htaccess fájlt ezeken a könyvtárakon belül így talán egyikük jelszóval védett, de a többiek nem. És még mindig megtarthatod Beállítások -Indexes hogy a látogatók nem böngészhetnek a webhelyén / képeken / mappán.

Jelszó védelem

A jelszavak védelme a könyvtárakhoz nagyon gyakori eljárás biztosítsák az adminisztrációs területek és más mappák biztosítását a webhelyéhez. Néha csak egy kis csoporthoz akar hozzáférni. Más esetekben a jelszavak megakadályozzák a hackerek hozzáférését a webhely adminisztrációs paneljéhez. De mindkettő nagyon hatékony megoldást jelent számos problémára.

Van egy praktikus útmutató a jelszavas védelemről, amely felvázolja a fontos kódrészleteket. Szükséged lesz létrehoz egy jelszófájlt, amely a felhasználónév / jelszó hitelesítő adatait tárolja. Így ellenőrizheti az Apache a felhasználó által bevitt adatokkal szemben, hogy megnézze, meg kell-e adni a hozzáférést. És vegye figyelembe, hogy hogyan kell létrehoznia egy mintát a felhasználónevéhez és a jelszavához.

Ezt a htpassword generátort javasolnám, hogy egy kicsit időt takarítson meg. A szintaxis mindig tökéletes lesz, és nem kell titkosítania a jelszót. És a másik nagyszerű lehetőség, hogy a jelszót egy teljes könyvtárlistára védjük. Ezt a példát a CSS-Tricks kódrészletek galériájában láthatjuk.

AuthType Basic AuthName "Ez a terület jelszóval védett" AuthUserFile /full/path/to/.htpasswd Érvényes felhasználóra van szükség

Biztonság a WordPress számára

Ahhoz, hogy ezt a jelszavas védelmi ötletet jó hasznára tegyük, mutassunk meg egy valós példát. Ez a bonyolultabb kódrészlet lesz kényszerítse a felhasználói hitelesítést bárki számára, aki hozzáfér a WordPress wp-login.php fájlhoz. Megtalálja az eredeti forrást a Ask Apache-on, amely számos más WordPress védelmi részletet tartalmaz.

 Rendelés megtagadása, Letiltás tiltása az All Satisfy-ről Bármely AuthName "Protected By AskApache" segítségével AuthUserFile /web/askapache.com/.htpasswda1 AuthType alapkövetelmény érvényes felhasználóra van szükség

És ha követni fogja ezeket a .htaccess szabályokat, akkor segíthet a jelszó védelmében is. Jellemzően a wp-login.php A fájl meg fogja kapni a legtöbb találatot azoktól az emberektől, akik megpróbálják elérni a rendszerükbe. Tehát csak a fenti mintakódok lennének több mint elég hozzáadott biztonság a WordPress webhelyéhez.

HTTP URL átírási szabályok

Az URL-ek újraírása valószínűleg az .htaccess fájlok egyik leggyakoribb alkalmazása. A WordPress alapértelmezett telepítések valójában készítsen .htaccess fájlt közvetlenül az adminisztrációs panelről. Ezzel olyan szép URL-eket hozhat létre, amelyek nem rendelkeznek a .php? P = 1 struktúrával.

Szeretném megnézni ezt az átírási példát hogyan lehet frissíteni az aláhúzásokat a kötőjelekre azóta sok fontos elemet tartalmaz.

Opciók + FollowSymLinks RewriteEngine On RewriteBase / RewriteRule! (Html | php) $ - [S = 4] RewriteRule ^ ([^ _] *) _ ([^ _] *) _ ([^ _] *) _ ( [^ _] *) _ (. *) $ $ 1- $ 2- $ 3- $ 4- $ 5 [E = uscor: Igen] RewriteRule ^ ([^ _] *) _ ([^ _] *) _ ([^ _ ] *) _ (. *) $ $ 1- $ 2- $ 3- $ 4 [E = uscor: Igen] RewriteRule ^ ([^ _] *) _ ([^ _] *) _ (. *) $ $ 1- $ 2- $ 3 [E = uscor: Igen] RewriteRule ^ ([^ _] *) _ (. *) $ $ 1- $ 2 [E = uscor: Igen] RewriteCond% ENV: uscor ^ Igen $ RewriteRule (. *) Http: //d.com/$1 [R = 301, L]

RewriteEngine és RewriteBase leginkább ezekre a pontos értékekre lehet beállítani. De szükség van a RewriteEngine-re, hogy bármi mást dolgozzon. Rengeteg útmutató van online, amely elmagyarázza, hogyan lehet engedélyezni a mod_rewrite és a tárhely szolgáltatóját.

Figyeljük meg, hogy a szintaxis a következőt követi: RewriteRules a csúcson. Ezek a szabályok szoktak egyezik meg a HTTP-kérésként elküldött esetekkel. Ezekre egy RewriteRule válaszol, amely ebben az esetben mindent átirányít a tartományra d.com. A végső zárójelek, mint a [R = 301, L], átíró jelzők, amelyek fontosak, de inkább egy fejlett téma.

A mod_rewrite szintaxis egy kicsit zavaró, de nem megfélemlíteni! A töredékek sokkal könnyebbek lehetnek más példákban.

Amikor csak elkezdtem, ajánlom ezt a mod_rewrite weblapot, amely segít a kódminták létrehozásában valódi URL-ek használatával. Ez egy ragyogó eszköz, mert különféle elemeket kereshet a szintaxisban, hogy lássa, mit csinálnak a Rewrite szabályokban. Itt van egy másik nagyszerű bemutató egy egyszerűbb példával a tanuláshoz:

RewriteRule ^ dir / ([0-9] +) /? $ /Index.php?id=$1 [L]

Ne próbálja meg egyszerre túlterhelni magát ezeken. Több mint 3-4 hónapig tartott, hogy megértsem, hogyan írhatom át az URL-eket [0-9a-zA-Z] + és hasonló mintákkal. Tartsd tovább a gyakorlatot, és időben megígérem, hogy megkapod ezt a cuccot, mint a józan ész.

Kódrészletek a webmesterek számára

Szeretem a könnyen használható töredékeket, és szeretném összeállítani ezt a kis, megfelelő webhelygazdáknak .htaccess-kódot. Mindezek az ötletek jól illeszkedhetnek a saját .htaccess fájlba, más kódblokkokkal együtt. A legtöbb ilyen részlet nagyszerű Gyors problémák vagy javítások megoldása webszerver környezetben. Képzeld el, hogy a tökéletes Apache telepítés az új webmesterek számára éppen most kezdődik.

DirectoryIndex beállítása

A DirectoryIndex parancsot általában egy sorban használják. Megmondhatja az Apache-nak, hogy mely dokumentumokat kell először kezelni “fő-” dokumentum. Alapértelmezés szerint ez lesz célpontok, például index.html, index.php, index.asp és egyéb indexfájlok. De ezt a kódrészletet, amelyet az alábbiakban másoltam, meg tudod csinálni, hogy ezt a gyökérdokumentumot tetszeni fogod.

DirectoryIndex index.html index.cgi index.php

A dokumentumok sorrendjének a legfontosabbakkal kell kezdődnie, és a legkevésbé fontosnak kell lennie. Tehát, ha nincs HTML- vagy CGI-fájlunk, akkor a tartalék lesz index.php. És meg is nevezheted ezeket a fájlokat home.php vagy someotherfile.php és ez minden érvényes szintaxis.

A WWW vagy a nem WWW aldomain kényszerítése

Ha nem adja meg a Google-t, akkor a webhely-domain mindkét verziójával együtt dolgozhat www.domain.com vagy csak domain.com. Tapasztalatom szerint ez a legjobb gyakorlat válasszon egyet, és állítsa be az egyetlen választás keresztül .htaccess. Ezután a Google nem fogja indexelni a különböző URL-eket, amelyek némelyike a WWW aldomainre mutat, míg mások nem.

# Force WWW Subdomain RewriteEngine bekapcsolása RewriteCond% HTTP_HOST ^ domain.com [NC] RewriteRule ^ (. *) $ Http://www.domain.com/$1 [L, R = 301] # Nincs aldomain RewriteEngine RewriteCond% HTTP_HOST! ^ Domain.com $ [NC] RewriteRule ^ (. *) $ Http://domain.com/$1 [L, R = 301]

Ez a kódrészlet egy CSS-Tricks archívumból származik, és nagyon praktikus megoldást nyújt. Frissítenie kell a tartományt, hogy bármi legyen szüksége a saját webhelyére. Ellenkező esetben probléma merül fel, és rögtön észre fogod venni! De nagyon támogatom a két lehetőség egyikét, és az új webhely elindítása után a feladatom listájának tetején van.

Médiafájl-letöltések kényszerítése

Egy másik meglehetősen fontos részlet lehetővé teszi bizonyos médiatípusok kényszerítését letöltés a böngészőben való megjelenítés helyett. Azonnal tudok PDF-dokumentumokat és MP3-audiofájlokat találni, amelyek letölthető formátumban jeleníthetők meg, de hogyan győződjön meg róla, hogy letölthetőek? Hasonló cikket találtam a Htaccess Guide-ban, amely körvonalazza ezt a kódrészletet.

AddType alkalmazás / octet-stream .zip .mp3 .mp4

Nyugodtan vegye fel még több fájlfajtát a sor végén. Az octet-stream MIME típust használó összes médiaformátum letölthető lesz. Ez a .htaccess-en keresztül történő kényszerítés nagyon közvetlen út, amely biztosítja, hogy az emberek nem tudják megtekinteni ezeket a fájlokat a böngészőben.

Egyéni hiba dokumentumok

Az utolsó utolsó darab, amit hozzá szeretnék adni, egy egyéni hibadokumentumok teljes sablonja. Általában ezek a számkódok csak a szerver végén láthatók. De sok ilyen hibadokumentum létezik, amelyeket ismernie kell. Néhány példa lehet 403/404 hiba és a 301 átirányítás.

Ez a hibakód sablon 100-tól kezdődik és 500-ra lép felfelé. Kérjük, vegye figyelembe, hogy nyilvánvalóan nem kell mindezek. Csak a leggyakoribb hibák szükségesek, és esetleg néhány homályos részlet, ha úgy érzi, hogy szükség van rá.

Ha nem ismeri fel a kódot, akkor nézze meg a Wikipédián, hogy jobban megértse.

ErrorDocument 100 / 100_CONTINUE ErrorDocument 101 / 101_SWITCHING_PROTOCOLS ErrorDocument 102 / 102_PROCESSING ErrorDocument 200 / 200_OK ErrorDocument 201 / 201_CREATED ErrorDocument 202 / 202_ACCEPTED ErrorDocument 203 / 203_NON_AUTHORITATIVE ErrorDocument 204 / 204_NO_CONTENT ErrorDocument 205 / 205_RESET_CONTENT ErrorDocument 206 / 206_PARTIAL_CONTENT ErrorDocument 207 / 207_MULTI_STATUS ErrorDocument 300 / 300_MULTIPLE_CHOICES ErrorDocument 301 / 301_MOVED_PERMANENTLY ErrorDocument 302 / 302_MOVED_TEMPORARILY ErrorDocument 303 / 303_SEE_OTHER ErrorDocument 304 / 304_NOT_MODIFIED ErrorDocument 305 / 305_USE_PROXY ErrorDocument 307 / 307_TEMPORARY_REDIRECT ErrorDocument 400 / 400_BAD_REQUEST ErrorDocument 401 / 401_UNAUTHORIZED ErrorDocument 402 / 402_PAYMENT_REQUIRED ErrorDocument 403 / 403_FORBIDDEN ErrorDocument 404 / 404_NOT_FOUND ErrorDocument 405 / 405_METHOD_NOT_ALLOWED ErrorDocument 406 / 406_NOT_ACCEPTABLE 407 / 407_PROXY_AUTHENTICATION_REQUIRED hibaüzenet 408 / 408_REQUEST_TIME_OUT ErrorDocument 409 / 409_CONFLICT ErrorDocument 410 / 410_GONE ErrorDocument 411 / 411_LENGTH_REQUIRED ErrorDocument 412 / 412_PRECONDITION_FAILED ErrorDocument 413 / 413_REQUEST_ENTITY_TOO_LARGE ErrorDocument 414 / 414_REQUEST_URI_TOO_LARGE ErrorDocument 415 / 415_UNSUPPORTED_MEDIA_TYPE ErrorDocument 416 / 416_RANGE_NOT_SATISFIABLE ErrorDocument 417 / 417_EXPECTATION_FAILED ErrorDocument 422 / 422_UNPROCESSABLE_ENTITY ErrorDocument 423 / 423_LOCKED ErrorDocument 424 / 424_FAILED_DEPENDENCY ErrorDocument 426 / 426_UPGRADE_REQUIRED ErrorDocument 500 / 500_INTERNAL_SERVER_ERROR ErrorDocument 501 / 501_NOT_IMPLEMENTED ErrorDocument 502 / 502_BAD_GATEWAY ErrorDocument 503 / 503_SERVICE_UNAVAILABLE ErrorDocument 504 / 504_GATEWAY_TIME_OUT ErrorDocument 505 / 505_VERSION_NOT_SUPPORTED ErrorDocument 506 / 506_VARIANT_ALSO_VARIES ErrorDocument 507 / 507_INSUFFICIENT_STORAGE ErrorDocument 510 / 510_NOT_EXTENDED

Online .htaccess weblapok

Htaccess Builder
.htaccess átirányító generátor
.htaccessEditor - .htaccess fájl létrehozása
Mod Rewrite Generator a GenerateIt.net által

Egyéb hasznos források

.htaccess a Httpd Wikiben
Hivatalos Apache htaccess dokumentáció
Kérdezd meg az Apache Blogot - Htaccess Archives
Ultimate Guide to htaccess és mod_rewrite
Minden, amit valaha is akartál tudni a Mod_Rewrite szabályokról, de attól féltem, hogy kérdezz

Végső gondolatok

Olyan sok számtalan erőforrás van, amely online .htaccess fájlokat tárgyal. A kapcsolódó cikkek és weblapok nagyszerű hely az elindításhoz. De folytassa az új ötletek gyakorlását és ne féljen kódrészletek tesztelése. Amíg van mentési fájlja akkor tesztelhetsz bármit, amit szeretsz, és ez egy szórakoztató tanulási élmény.

Ha van más ötlete vagy javaslata a .htaccess menedzsmentre vonatkozóan, kérjük, ossza meg velünk az alábbi hozzászólási területet.