Pradedančiųjų vadovas .htaccess programuotojams ir kūrėjams

Tarp daugelio įvairių žiniatinklio serverio pritaikymo įrankių .htaccess config failas yra didžiulis turtas. Tu gali greitai iš naujo nustatyti dokumentų tipus, analizuojant variklius, URL peradresavimus, ir daug kitų svarbių funkcijų. Žiniatinklio valdytojai, kurie nėra labai techniniai, negali patekti į savo .htaccess failo tvarkymo specifiką. Tačiau pati tema yra įdomi ir verta.

Šiame straipsnyje noriu pristatyti kai kurias tikslingesnes žiniatinklio valdytojų ir žiniatinklio kūrėjų koncepcijas. Kiekvienas, kas yra paleisti savo svetainę „Apache“ serveryje tikrai norėsite suprasti, kaip tvarkyti savo .htaccess failą. Tai suteikia tiek daug pritaikomumo ir tai gali dirbti visomis interneto kalbomis nuo PHP iki Ruby.

Šio įrašo apačioje pridėjau kai kurių išorinių žiniatinklio įrašų padėti naujokams dinamiškai kurti savo .htaccess failus.

Kodėl naudoti .htaccess failą?

Tai puikus klausimas ir galbūt turėtume pradėti atsakydami “kas yra .htaccess failas”? Tai labai specialus konfigūracijos failas, naudojamas „Apache“ žiniatinklio serveryje. .Htaccess failas gali pasakyti interneto serveriui kaip pateikti įvairias informacijos formas ir kaip tvarkyti įvairias HTTP užklausų antraštes.

Tikrai tai yra priemonė decentralizacija tvarkyti žiniatinklio serverio nustatymus. Vienas fizinis serveris gali turėti 50 skirtingų svetainių, turinčių savo .htaccess failą. Ji suteikia daug galios žiniatinklio valdytojams, kurie priešingu atveju būtų neįmanomi. Bet kodėl turėtumėte jį naudoti?

Didžiausia priežastis yra saugumas. Tu gali užrakinti tam tikrus katalogus arba apsaugoti juos slaptažodžiu. Tai puikiai tinka privatiems projektams ar naujoms turinio valdymo sistemoms, kur norite šiek tiek papildomo saugumo. Tačiau yra ir įprastų užduočių, pavyzdžiui, 404 klaidų pranešimų nukreipimas į tam tikrą tinklalapį. Tai trunka tik vieną eilutę ir tai gali smarkiai paveikti lankytojų reagavimą į trūkstamus puslapius.

Tiesą sakant, nemanau, kad galiu įtikinti kitus, kad .htaccess failas yra vertas. Kai pamatysite jį, galite atpažinti visą vertę, kuri gaunama iš šio mažo konfigūracijos failo. Taip pat tikiuosi, kad šio straipsnio likusi dalis gali parodyti keletą įžvalgų temų, kad žiniatinklio valdytojai galėtų valdyti .htaccess konfigūraciją.

Leisti / uždrausti prieigą

Galima atpažinti galimus šlamšto lankytojus ir neleisti jiems patekti į jūsų svetainę. Tai gali būti šiek tiek kraštutinė, tačiau jei žinote, kad asmuo ar žmonių grupė nukreipė jūsų svetainę, yra keletas pasirinkimo galimybių. Galite pasirinkti domeno persiuntimą, norėdami neleisti arba uždrausti lankytojams pagal IP adresą.

leisti, paneigti nuo 255.0.0.0 neigti nuo 123.45.6. leisti iš visų 

Šie pavyzdiniai kodai buvo nukopijuoti iš „Htaccess Guide“, nes jie yra puikus šablonas pradėti. Atkreipkite dėmesį, kad antrojo IP adreso trūksta 4-ajame sveikame skaičiumi. Šis kodų blokas bus nukreiptas į pirmąjį IP (255.0.0.0) ir kiekvieną IP per 123,45,6,0-255 diapazoną, tada leisti visus kitus srautus. Žiniatinklio valdytojai tai negali naudoti taip dažnai, kaip ir kiti būdai, bet tai naudinga suprasti.

Neleisti katalogų sąrašo

Bus laikai, kai turėsite atvirą katalogą, kuris yra nustatyti, kad pagal nutylėjimą būtų galima naršyti. Tai reiškia, kad vartotojai gali peržiūrėti visus failus, įrašytus į vidinę katalogo struktūrą, pvz., Vaizdų aplanką. Kai kurie žiniatinklio valdytojai nenori leisti katalogų sąrašo ir laimei, kodo fragmentas yra gana lengva prisiminti.

Parinktys -Parodymai 

Mačiau, kad šis atsakymas pateikiamas daug kartų per „Stack Overflow“ ir tai gali būti viena iš paprasčiausių prieigos taisyklių, kurias reikia prisiminti.

Tai galima iš tikrųjų sukurkite kelis .htaccess failus kiekviename iš šių katalogų todėl galbūt vienas iš jų yra apsaugotas slaptažodžiu, o kiti ne. Ir jūs vis tiek galite laikyti Parinktys -Parodymai kad lankytojai negalėtų naršyti jūsų svetainės / vaizdų / aplankų.

Slaptažodžių apsauga

Slaptažodžiu apsaugoti savo katalogus yra labai dažna procedūra užtikrinti, kad administravimo sritys ir kiti aplankai, svarbūs jūsų svetainėje. Kartais jūs tik norėsite pasiūlyti prieigą prie nedidelės žmonių grupės. Kitais atvejais slaptažodžiai neleidžia įsilaužėliams patekti į jūsų svetainės administravimo skydą. Bet bet kuriuo atveju tai yra labai galingas sprendimas daugeliui problemų.

Yra patogus slaptažodžio apsaugos vadovas, kuriame išdėstomi svarbūs kodo fragmentai. Jums reikės generuoti slaptažodžio failą, kuriame saugomi naudotojo vardas / slaptažodis. Taip Apache gali patikrinti, ką vartotojas įveda, kad pamatytų, ar jiems turėtų būti suteikta prieiga. Ir pastebėkite, kaip jums reikės sukurti naudotojo vardo ir slaptažodžio pavyzdį.

Norėčiau rekomenduoti naudoti šį „htpassword“ generatorių, kad galėtumėte sutaupyti šiek tiek laiko. Sintaksė visada išeis tobulai ir jums nereikės šifruoti slaptažodžio. Ir kitas puikus pasirinkimas yra apsaugoti visą katalogo sąrašą. Šį pavyzdį galime pamatyti CSS-Tricks kodo fragmentų galerijoje.

„AuthType Basic AuthName“ „Ši sritis yra apsaugota slaptažodžiu“ AuthUserFile /full/path/to/.htpasswd Reikalingas galiojantis vartotojas 

„WordPress“ saugumas

Norint, kad ši slaptažodžio apsaugos idėja būtų tinkamai naudojama, rodysime realaus pasaulio pavyzdį. Tai bus sudėtingesnis kodo fragmentas priversti naudotojo autentifikavimą visiems, kurie naudojasi WordPress wp-login.php failu. Originalų šaltinį rasite „Ask Apache“, kuriame yra daug kitų „WordPress“ apsaugos fragmentų.

 Užsakymo paneigimas, leisti paneigti iš visų pasitenkinti bet kokiu „AuthName“ „Protected by AskApache“ AuthUserFile /web/askapache.com/.htpasswda1 „AuthType“ pagrindinis reikalavimas  

Ir jei jūs ketinate laikytis šių .htaccess taisyklių, tai taip pat gali padėti apsaugoti slaptą administratoriaus sritį. Paprastai wp-login.php failas bus gauti labiausiai hitai iš žmonių bando brutalus jėga savo kelią į jūsų sistemą. Taigi, net ir tik aukščiau pateikti pavyzdiniai kodai daugiau nei pakankamai papildomo saugumo jūsų „WordPress“ svetainėje.

HTTP URL perrašymo taisyklės

URL perrašymas tikriausiai yra vienas iš dažniausiai naudojamų .htaccess failų. „WordPress“ numatytieji įrenginiai iš tikrųjų gali būti generuoti .htaccess failą tiesiai iš administravimo skydo. Tai leidžia sukurti gana URL, kuriuose nėra .php? P = 1 struktūros.

Noriu pažvelgti į šį perrašymo pavyzdį kaip atnaujinti brūkšnelius Nuo tada, kai tai yra daug svarbiausių elementų.

Parinktys + sekos nuorodos RewriteEngine Įjungta RewriteBase / RewriteRule! (Html ​​| php) $ - [S = 4] RewriteRule ^ ([^ _] *) _ ([^ _] *) _ ([^ _] *) _ ( [^ _] *) _ (. *) $ $ 1- $ 2- $ 3- $ 4- $ 5 [E = uscor: Taip] RewriteRule ^ ([^ _] *) _ ([^ _] *) _ ([^ _ ] *) _ (. *) $ $ 1- $ 2- $ 3- $ 4 [E = uscor: Taip] RewriteRule ^ ([^ _] *) _ ([^ _] *) _ (. *) $ $ 1- $ 2- $ 3 [E = uscor: Taip] RewriteRule ^ ([^ _] *) _ (. *) $ $ 1- $ 2 [E = uscor: Taip] RewriteCond% ENV: uscor ^ Taip $ RewriteRule (. *) Http: //d.com/$1 [R = 301, L] 

„RewriteEngine“ ir RewriteBase visada gali būti nustatoma pagal šias tiksliąsias vertes. Bet jums reikia įjungti „RewriteEngine“, kad galėtumėte dirbti. Internete yra daug vadovų, paaiškinančių, kaip mod_rewrite ir jūsų prieglobos paslaugų teikėjas gali padėti.

Atkreipkite dėmesį, kad sintaksė seka PerrašytiRules viršuje. Šios taisyklės naudojamos suderinti su atvejais, kurie siunčiami kaip HTTP užklausa. Į šiuos atsakymus atsako „RewriteRule“, kuris šiuo atveju nukreipia viską į domeną d.com. Pabaigos skliaustai, pvz., [R = 301, L], vadinami perrašymo vėliavomis, kurios yra svarbios, bet labiau išplėstinės temos.

Mod_rewrite sintaksė neabejotinai yra šiek tiek paini, bet negali būti bauginama! Kituose pavyzdžiuose fragmentai gali daug lengviau atrodyti.

Kai tik pradėsite, turiu rekomenduoti šį mod_rewrite žiniatinklio įrašą, kuris padeda jums sukurti kodo pavyzdžius naudojant realius URL. Tai puikus įrankis, nes galite ieškoti įvairių sintaksės elementų, kad pamatytumėte, ką jie iš tikrųjų daro perrašymo taisyklėse. Čia yra dar viena puiki pamoka su paprastesniu pavyzdžiu:

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

Negalima iš karto perkrauti sau šių. Tai užtruko gerokai daugiau nei 3-4 mėnesius, kad tikrai pradėjau suprasti, kaip perrašyti URL su [0-9a-zA-Z] + ir panašiais modeliais. Laikykitės praktikos ir laikui bėgant pažadu, kad gausite šią medžiagą, pavyzdžiui, jausmą.

Kodo fragmentai žiniatinklio valdytojams

Aš myliu lengvai naudoti fragmentus ir noriu sujungti šį nedidelį tinkamų administratorių kodų rinkinį. Kiekviena iš šių idėjų puikiai tinka jūsų .htaccess failui kartu su kitais kodų blokais. Dauguma šių fragmentų puikiai tinka sparčių problemų ar pataisymų sprendimas jūsų tinklo serverio aplinkoje. Įsivaizduokite puikų „Apache“ nustatymą naujiems žiniatinklio valdytojams, kurie tik pradeda naudotis internetu.

Nustatymas DirectoryIndex

„DirectoryIndex“ komanda dažniausiai naudojama vienoje eilutėje. Apache galite pasakyti, kokie dokumentai turėtų būti laikomi “pagrindinis” dokumentą. Pagal nutylėjimą tai bus nukreipkite elementus, tokius kaip index.html, index.php, index.asp ir kitus indekso failus. Bet naudodami šį kodo fragmentą, kurį aš nukopijuojau žemiau, turite galimybę padaryti šį pagrindinį dokumentą norimą.

DirectoryIndex index.html index.cgi index.php 

Dokumentų eiliškumas turėtų prasidėti svarbiausiais ir pereiti per mažiausiai svarbius. Taigi, jei neturime HTML ar CGI failo, tuomet atsarginės kopijos bus index.php. Ir netgi galite pavadinti šiuos failus home.php arba someotherfile.php ir tai yra visa galiojanti sintaksė.

Priversti WWW arba ne WWW subdomeną

Jei nenurodysite, „Google“ gali dirbti su abiem svetainės domeno versijomis www.domain.com ar tiesiog domain.com. Mano patirtis yra geriausia praktika pasirinkite vieną iš šių ir nustatykite kaip vienintelį pasirinkimą per .htaccess. Tada „Google“ nepagrinduos įvairių URL su kai kuriais rodančiais WWW subdomeną, o kiti to nedaro.

# Force WWW subdomain RewriteEngine On RewriteCond% HTTP_HOST ^ domain.com [NC] RewriteRule ^ (. *) $ Http://www.domain.com/$1 [L, R = 301] # Nėra subdomeno iš naujo HTTP_HOST! ^ Domain.com $ [NC] RewriteRule ^ (. *) $ Http://domain.com/$1 [L, R = 301] 

Šis kodo fragmentas gaunamas iš CSS-Tricks archyvo ir yra labai patogus sprendimas. Turėtumėte atnaujinti domeną, kad būtumėte tikri, kad jums reikia savo svetainės. Priešingu atveju bus problemų ir tuoj pat pastebėsite! Bet aš labai pritariu tam, kad priverčiau vieną iš šių dviejų variantų ir tai yra mano užduočių sąrašo viršuje, kai pradėsiu naują svetainę.

„Force Media File Downloads“

Kitas gana svarbus fragmentas leidžia priversti tam tikras medijos rūšis atsisiuntimas, o ne rodomas naršyklėje. Nedelsiant galiu galvoti apie PDF dokumentus ir MP3 garso failus, kurie gali būti pateikiami atsisiunčiamu formatu, bet kaip jūs įsitikinkite, kad jie yra parsisiunčiami? Radau panašų straipsnį, paskelbtą „Htaccess Guide“, kuriame apibūdinamas šis kodo fragmentas.

„AddType“ programa / octet-stream .zip .mp3 .mp4 

Šios eilutės pabaigoje galite laisvai įtraukti dar daugiau failų tipų. Visi žiniasklaidos formatai, naudojant „octet-stream MIME“ tipą, bus atsisiųsti. Priversti šią per .htaccess yra labai tiesioginis maršrutas, užtikrinantis, kad žmonės negalėtų peržiūrėti šių failų naršyklėje.

Priskirtų klaidų dokumentai

Paskutinis galutinis kūrinys, kurį noriu pridėti, yra pilnas pasirinktinių klaidų dokumentų šablonas. Paprastai šie kodų kodai matomi tik serverio gale. Tačiau yra daug šių klaidų dokumentų, kuriuos turėtumėte žinoti. Gali būti keletas pavyzdžių 403/404 klaidos ir 301 peradresavimas.

Šis klaidos kodo šablonas prasideda nuo 100 iki 500 klaidų. Atkreipkite dėmesį, kad jums nereikia visų šių. Reikėtų tik dažniausiai pasitaikančių klaidų, o galbūt ir keletas neaiškių fragmentų.

Jei neatpažįstate kodo, tiesiog ieškokite Wikipedia, kad geriau suprastumėte.

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 Klaidos dokumentas 407 / 407_PROXY_AUTHENTICATION_REQUIRED Klaidos dokumentas 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 

Prisijungę .htaccess žiniatinkliai

• „Htaccess Builder“
• .htaccess peradresavimo generatorius
• .htaccessEditor - sukurkite .htaccess failą
• Mod Rewrite Generator GenerateIt.net

Kiti naudingi ištekliai

• .htaccess „Httpd Wiki“
• Oficiali „Apache htaccess“ dokumentacija
• Paklauskite „Apache“ dienoraščio „Htaccess“ archyvų
• Galutinis „htaccess“ ir mod_rewrite vadovas
• Viskas, ką kada nors norėjote žinoti apie „Mod_Rewrite“ taisykles, bet bijojo paklausti

Galutinės mintys

Yra tiek daug daugybė išteklių internete, aptariant .htaccess failus. Mano susieti straipsniai ir žiniatinklio įrašai yra puiki vieta pradėti. Bet laikykitės naujų idėjų ir nebijokite išbandyti kodo fragmentus. Tol, kol turite atsarginį failą tada galite išbandyti viską, kas jums patinka, ir tai yra įdomi mokymosi patirtis.

Jei turite kitų idėjų ar pasiūlymų dėl .htaccess valdymo, pasidalykite su mumis toliau pateikiamoje diskusijų srityje.