Algaja juhend .htaccess'i jaoks disaineritele ja arendajatele

Paljude erinevate veebiserveri kohandamise vahendite hulgas on .htaccess config fail tohutu vara. Sa saad kiiresti lähtestada dokumenditüübid, analüsivad mootorid, URL-i ümbersuunamised, ja paljud teised olulised omadused. Veebimeistrid, kes ei ole väga tehnilised, ei pruugi oma .htaccess-faili haldamise eripära sattuda. Kuid teema ise on põnev ja väärt uurimist.

Selle artikli puhul tahan tutvustada mõningaid sihipärasemaid kontseptsioone veebimeistrite ja veebiarendajate jaoks. Igaüks, kes on oma veebisaidi avamine Apache serveris kindlasti tahan mõista, kuidas oma .htaccess-faili hallata. See pakub nii palju kohandatavust ja see võib töötada kõikides veebikeeltes PHP-lt Ruby-le.

Selle ametikoha allosas olen lisanud mõned välised veebikõned aidata uustulnukatel oma .htaccess-faile dünaamiliselt luua.

Miks kasutada .htaccess-faili?

See on suur küsimus ja võib-olla peaksime alustama vastamisega “mis on .htaccess-fail”? See on väga eriline konfiguratsioonifail, mida kasutab Apache veebiserver. .Htaccess-fail võib veebiserverile öelda kuidas esitada erinevaid teabevorme ja kuidas käsitleda erinevaid HTTP-päringute päiseid.

See on tõesti vahend detsentraliseerimine veebiserveri seadete korraldamiseks. Üks füüsiline server võib omada 50 erinevat veebisaiti, millel on oma .htaccess-fail. See annab veebimeistritele palju võimu, mis muidu oleks võimatu. Aga miks peaksite seda kasutama?

Suurim põhjus on turvalisus. Sa saad lukustage teatud kataloogid või tehke need parooliga kaitstud. See on suurepärane eraprojektide või uute sisuhaldussüsteemide jaoks, kus soovite veidi lisatagatist. Kuid on ka tavalisi ülesandeid, nagu 404 veateadete suunamine teatud veebilehele. See võtab ainult ühe koodirea see võib oluliselt mõjutada seda, kuidas külastajad puuduvatele lehekülgedele reageerivad.

Tõepoolest ei saa palju öelda, et veenda teisi, et .htaccess-fail on mõistetav. Kui näete seda tegevuses, siis saate ära tunda kogu selle väikese konfiguratsioonifaili väärtuse. Samuti loodan, et see artikkel võib esitada mõningaid ülevaatlikke teemasid, et tuua veebihaldurid arvesse .htaccess-konfiguratsiooni haldamisel.

Luba / keelata juurdepääs

Võimalik on tuvastada võimalikud rämpsposti külastajad ja keelata neile juurdepääs teie veebisaidile. See võib olla natuke äärmuslik, aga kui te teate, et inimene või inimeste rühm on teie veebisaidile suunatud, on mõned võimalused, millest valida. IP-aadressi külastajate keelamiseks või keelamiseks võite valida domeeni suunamise.

lubada, keelata eitada alates 255.0.0.0 eitada alates 123.45.6. lubage kõigilt 

Need näidiskoodid kopeeriti Htaccess Guideist, kuna need on ideaalsed mallid alustamiseks. Pange tähele, et 2. IP-aadressil puudub 4. täisarv. See koodiplokk on suunatud esimesele IP-le (255.0.0.0) ja iga IP-le vahemikus 123,45,6,0-255, seejärel lubage kogu muu liiklus. Veebimeistrid ei pruugi seda kasutada nii sageli kui muud tehnikat, kuid on kasulik mõista.

Kataloogide loendi keelamine

On aegu, kui teil on avatud kataloog, mis on seadistatud, et lubada vaikimisi sirvimist. See tähendab, et kasutajad saavad vaadata kõiki sisemises kataloogistruktuuris loetletud faile, nagu kausta kaust. Mõned veebimeistrid ei soovi kataloogide loendit lubada ja õnneks on koodilõik üsna lihtne meeles pidada.

Valikud -Näited 

Olen näinud, et see vastus esitati Stacki ülevoolul lugematuid kordi ja see võib olla üks lihtsamaid meeldetuletussätteid..

On võimalik tegelikult luua kõik .htaccess-failid mõlemas kataloogis seega võib-olla üks neist on kaitstud parooliga, kuid teised ei ole. Ja te saate seda ikka veel hoida Valikud -Näited et külastajad ei saaks oma veebisaiti / pilte / kausta sirvida.

Paroolikaitse

Teie kataloogide kaitsmine parooliga on väga tavaline Teie veebisaidi jaoks oluliste haldusvaldkondade ja muude kaustade tagamine. Mõnikord tahad pakkuda ainult väikestele inimestele juurdepääsu. Muudel juhtudel on paroolid, mis takistavad häkkeritel juurdepääsu teie veebisaidi halduspaneelile. Kuid mõlemal juhul on see väga tõhus lahendus terve rea probleemidele.

Paroolikaitse kohta on mugav juhend, mis kirjeldab olulisi koodilõikeid. Sa pead luua paroolifail, mis salvestab kasutajanime / parooli. Nii saab Apache kontrollida, mida kasutaja sisestab, et näha, kas neile tuleks anda juurdepääs. Ja märkige, kuidas peate oma kasutajanime ja parooli jaoks proovi looma.

Soovitan kasutada seda htpasswordi generaatorit, et saaksite natuke aega salvestada. Süntaks on alati täiuslik ja parooli ise ei pea krüptima. Ja teine ​​suurepärane võimalus on kaitsta kogu kataloogi nimekirja. Seda näidet näeme CSS-trikkide koodilõigu galeriis.

AuthType Basic AuthName "See ala on kaitstud parooliga" AuthUserFile /full/path/to/.htpasswd Nõuab kehtivat kasutajat 

Turvalisus WordPressile

Selle paroolikaitse idee õigeks kasutamiseks paneme paika reaalse näite. See keerulisem koodilõik on sundida kasutaja autentimist WordPress wp-login.php failile. Leiad esialgse allika kohta Ask Apache, millel on palju teisi WordPressi kaitsepiire.

 Tellimuse keelamine, luba keelata kõikidest rahuloludest Kõik authName "Protected by AskApache" AuthUserFile /web/askapache.com/.htpasswda1 AuthType Basic Nõuab kehtivat kasutajat  

Ja kui te järgite neid .htaccess-reegleid, võib see aidata ka administraatori kaitset parooliga. Tavaliselt on wp-login.php fail hakkab saama enim tabamust inimestelt, kes üritavad jõuda oma süsteemi. Niisiis oleks isegi ülaltoodud näidiskoodid rohkem kui piisavalt lisatagatist teie WordPressi veebisaidile.

HTTP URL-i ümberkirjutamise reeglid

URL-ide ümberkirjutamine on ilmselt üks kõige tavalisemaid .htaccess-failide kasutusviise. WordPressi vaikeseaded võivad tegelikult olla genereeri .htaccess-fail otse halduspaneelilt. See võimaldab luua päris URL-e, millel ei ole .php? P = 1 struktuuri.

Ma tahan vaadata seda ümberkirjutamise näidet kuidas värskendada kriipsude rõhuasetusi sellest alates sisaldab palju tähtsamaid elemente.

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

RewriteEngine ja RewriteBase kõige rohkem saab neid täpseid väärtusi seada. Aga teil on vaja RewriteEngine'i sisse lülitada, et midagi muud tööd teha. Internetis on palju juhendeid, mis selgitavad, kuidas mod_rewrite ja teie hostingu pakkuja võimaldada.

Pange tähele, et süntaks järgib RewriteRules tipus. Need reeglid on harjunud sobitada juhtumitega, mis saadetakse HTTP-päringuna. Neile vastab RewriteRule, mis antud juhul suunab kõike domeeni d.com. Lõplikke sulgusid nagu [R = 301, L] nimetatakse ümberkirjutamise lipudeks, mis on olulised, kuid rohkem arenenud teema.

Mod_rewrite süntaks on kindlasti natuke segane, kuid mitte hirmutada! Teised näited võivad väljavõtteid palju lihtsamalt vaadata.

Kui just alustate, siis pean soovitama seda mod_rewrite webappi, mis aitab teil luua tegelikke URL-e kasutades koodiproove. See on geniaalne tööriist, sest saate vaadata süntaksis erinevaid elemente, et näha, mida nad reegli reeglites tegelikult teevad. Siin on veel üks suur õpetus koos lihtsama näitega õppimiseks:

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

Ärge proovige neid korraga üle koormata. See võttis aega rohkem kui 3-4 kuud, et tõesti mõista, kuidas URL-e ümber kirjutada [0-9a-zA-Z] + ja sarnaste mustritega. Jätkake harjutamist ja õigeaegselt luban, et sa saad sellised asjad nagu see on terve mõistus.

Koodilõigud veebimeistritele

Ma armastan lihtsalt kasutatavaid fragmente ja tahan kokku panna selle väikese kogumi asjakohaseid .htaccess-koode veebimeistritele. Kõik need ideed sobivad hästi oma .htaccess-faili koos teiste koodiplokkidega. Enamik neist väljavõtetest on suurepärased kiirete probleemide või paranduste lahendamine veebiserveri keskkonnas. Kujutage ette täiuslikku Apache'i seadistust täiesti uutele veebimeistritele, kes lihtsalt alustavad võrku.

DirectoryIndexi seadistamine

DirectoryIndexi käsku kasutatakse tavaliselt ühes reas. Te võite Apache'ile öelda, milliseid dokumente tuleks esialgu käsitleda “peamine” dokument. Vaikimisi on see sihtige selliseid objekte nagu index.html, index.php, index.asp ja muud indeksfailid. Kuid kasutades seda koodilõiget, mida olen allpool kopeerinud, on teil võimalus teha see juurdokument kõik teile meeldivaks.

DirectoryIndex index.html index.cgi index.php 

Dokumentide järjekord peaks algama kõige tähtsamast ja liikuma läbi kõige tähtsamate ridade. Nii et kui meil pole HTML- või CGI-faili, siis läheb see varukoopia index.php. Ja sa võiksid isegi neid faile nimetada home.php või someotherfile.php ja see on kõik kehtiv süntaks.

Force WWW või mitte-WWW alamdomeen

Google ei saa teie veebisaidi domeeni mõlemat versiooni kasutada, kui te seda ei täpsusta www.domain.com või lihtsalt domain.com. Minu kogemus on see parim vali üks neist ja seada see ainsaks valikuks kaudu .htaccess. Seejärel ei indekseeri Google erinevaid URL-e, millel on mõni viide WWW alamdomeenile, samas kui teised ei.

# Force WWW alamdomeen RewriteEngine On RewriteCond% HTTP_HOST ^ domain.com [NC] RewriteRule ^ (. *) $ Http://www.domain.com/$1 [L, R = 301] # Ei alamdomeeni ümberkirjeldadaTagasi uuesti HTTP_HOST! ^ Domain.com $ [NC] RewriteRule ^ (. *) $ Http://domain.com/$1 [L, R = 301] 

See koodilõik pärineb arhiivist CSS-Tricks, mis pakub väga mugavat lahendust. Sa peaksid uuendama domeeni, et see oleks teie veebisaidi jaoks vajalik. Vastasel juhul tekib probleeme ja märkate kohe! Aga ma toetan väga ühte neist kahest võimalusest ja see on minu ülesannete nimekirja ülaosas pärast uue veebisaidi käivitamist.

Meediumifailide allalaadimine

Teine üsna oluline fragment võimaldab teatud meediatüüpe sundida brauseris kuvamise asemel alla laadida. Kohe saan mõelda PDF-dokumentidele ja MP3-helifailidele, mida võib esitada allalaaditavas vormis, aga kuidas sa seda teed veenduge, et need on allalaaditavad? Leidsin sarnase artikli, mis avaldati Htaccess Guide'is ja mis kirjeldab seda koodilõiget.

AddType rakendus / octet-stream .zip .mp3 .mp4 

Võite selle rea lõpus lisada veel rohkem failitüüpe. Kõik meediumivormingud, mis kasutavad oktet-stream MIME tüüpi, on allalaaditavad. Selle kaudu .htaccess'i kaudu sundimine on väga otsene tee, et tagada, et inimesed ei saa neid faile brauseris vaadata.

Kohandatud veateated

Üks viimane viimane tükk, mida ma soovin lisada, on kohandatud vigade dokumentide täielik mall. Tavaliselt on need numbrikoodid näha ainult serveri lõpus. Kuid on palju neid vea dokumente, mida peaksite tundma. Võib olla mõned näited 403/404 vead ja 301 ümbersuunamine.

See veakoodi mall algab 100-st ja liigub 500-le veale. Pange tähele, et ilmselt ei vaja neid kõiki. Vaja on ainult kõige tavalisemaid vigu ja vajadusel mõningaid varjatud fragmente.

Kui te koodi ei tunne, siis vaadake seda paremini Wikipedias, et paremini mõista.

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 ErrorDocument 407 / 407_PROXY_AUTHENTICATION_REQUIRED ErrorDocument 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 Webappid

• Htaccess Builder
• .htaccess-suunamise generaator
• .htaccessEditor - .htaccess-faili loomine
• Mod Rewrite Generator poolt GenerateIt.net

Muud kasulikud ressursid

• .htaccess Httpd Wikis
• Ametlik Apache htaccess dokumentatsioon
• Küsi Apache Blog - Htaccess Arhiiv
• Ultimate Guide to htaccess ja mod_rewrite
• Kõik, mida sa kunagi tahad teada Mod_Rewrite reeglitest, kuid kartsid küsida

Lõplikud mõtted

On palju lugematuid ressursse .htaccess-failide üle. Minu seotud artiklid ja veebisaitid on suurepärane koht alustamiseks. Kuid jätkake uute ideede praktiseerimist ja ärge kartke koodi väljavõtete testimine. Nii kaua kui teil on varukoopia siis saate proovida midagi, mis sulle meeldib ja see on lõbus õppimise kogemus.

Kui teil on muid ideid või soovitusi .htaccess'i haldamise kohta, siis palun jaga meiega allpool olevas arutelupiirkonnas.