Un ghid pentru incepatori pentru .htaccess pentru designeri si dezvoltatori

Printre numeroasele instrumente diverse pentru personalizarea serverului dvs. web, fișierul .htaccess config este un avantaj extraordinar. Poti repetați rapid tipurile de documente, motoarele de parsing, redirecționările adreselor URL, și multe alte caracteristici cruciale. Webmasterii care nu sunt foarte tehnici nu pot intra în specificul gestionării propriului fișier .htaccess. Dar subiectul în sine este fascinant și merită o investigație.

Pentru acest articol vreau să prezint câteva dintre conceptele mai intenționate pentru webmasteri și dezvoltatori web. Oricine este lansând propriul site pe un server Apache vor dori cu siguranță să înțeleagă cum să gestioneze fișierul .htaccess. Aceasta oferă atât de mult personalizabilitate si el poate funcționa în toate limbile web de la PHP la Ruby.

În partea de jos a acestui post am adăugat unele webapps externe la ajutați noii veniți să genereze dinamic fișierele lor .htaccess.

De ce să utilizați un fișier .htaccess?

Aceasta este o mare întrebare și poate ar trebui să începem prin a răspunde “ceea ce este un fișier .htaccess”? Este un fișier de configurare foarte special folosit de serverul web Apache. Un fișier .htaccess poate să spună serverului web cum să prezentați diferite forme de informații și cum să gestionați diferite antete de cerere HTTP.

Într-adevăr este un mijloc de descentralizare pentru a organiza setările serverului web. Un server fizic poate conține 50 de site-uri diferite, fiecare având propriul fișier .htaccess. Oferă multă putere webmasterilor, ceea ce altfel ar fi imposibil. Dar de ce ar trebui să folosiți unul?

Cel mai important motiv este securitatea. Poti blocați anumite directoare sau le protejați prin parolă. Acest lucru este excelent pentru proiecte private sau pentru noi sisteme de management al conținutului, unde doriți o mică siguranță suplimentară. Dar există și sarcini comune cum ar fi redirecționarea mesajelor de eroare 404 la o anumită pagină Web. Aceasta are nevoie doar de o singură linie de cod și poate avea un impact dramatic asupra modului în care vizitatorii reacționează la paginile care lipsesc.

Cu adevărat nu există prea multe lucruri pe care le pot spune pentru a convinge pe alții că un fișier .htaccess este în valoare de înțelegere. După ce îl vedeți în acțiune, puteți recunoaște toată valoarea care provine din acest fișier de configurare mic. De asemenea, sper ca restul acestui articol să prezinte câteva subiecte insightful pentru a aduce webmasteri în lumina administrării unei configurații .htaccess.

Permiteți / refuzați accesul

Este posibil să recunoașteți potențialii vizitatori de spam și să le refuzați accesul la site-ul dvs. web. Acest lucru poate fi un pic extremă, însă dacă știți că o persoană sau un grup de persoane au vizat site-ul dvs., există câteva opțiuni de a alege. Puteți alege o recomandare de domeniu pentru a refuza sau a interzice vizitatorii printr-o adresă IP.

ordonați permite, respinge refuzul de la 255.0.0.0 deny de la 123.45.6. permiteți tuturor

Aceste coduri de probă au fost copiate de la Ghidul Htaccess deoarece acestea reprezintă modelul perfect pentru a începe. Observați că a doua adresă IP nu are cel de-al patrulea întreg. Acest bloc de cod va viza primul IP (255.0.0.0) și fiecare IP în intervalul 123.45.6.0-255, apoi permiteți tot traficul. Webmasterii nu pot folosi acest lucru la fel de frecvent ca și alte tehnici, dar este util să înțelegeți.

Împiedicați înregistrarea în director

Vor fi momente când aveți un director deschis care este configurați pentru a permite navigarea în mod implicit. Aceasta înseamnă că utilizatorii pot vizualiza toate fișierele listate într-o structură internă de directoare, cum ar fi folderul cu imagini. Unii webmasteri nu doresc să permită înregistrarea directoarelor și, din fericire, fragmentul de cod este destul de ușor de reținut.

Opțiuni -Index

Am văzut acest răspuns prezentat nenumărate ori pe parcursul stivei și poate fi una dintre cele mai ușoare reguli .htaccess de reținut.

Este posibil de fapt creați mai multe fișiere .htaccess în interiorul fiecăruia dintre aceste directoare astfel încât poate una dintre ele este protejată prin parolă, dar celelalte nu sunt. Și puteți păstra în continuare Opțiuni -Index astfel încât vizitatorii să nu poată naviga prin site-ul dvs. / images / folder.

Protecție cu parolă

Protecția parolelor este o procedură foarte comună pentru protejarea parolelor securizarea zonelor de administrare și a altor dosare esențiale pentru site-ul dvs. web. Uneori, veți dori doar să oferiți acces la un grup mic de persoane. Parolele de altădată sunt pentru a împiedica accesul hackerilor la panoul de administrare a site-ului. Dar oricum este o soluție foarte puternică pentru un număr întreg de probleme.

Există un ghid la îndemână cu privire la protecția prin parolă care conturează fragmentele de cod importante. Va trebui sa generați un fișier de parolă care stochează numele de utilizator / parola. Acesta este modul în care Apache poate verifica ceea ce utilizatorul introduce pentru a vedea dacă ar trebui să li se acorde acces. Observați cum va trebui să generați un eșantion pentru numele de utilizator și parola.

Aș recomanda folosirea acestui generator de htpassword pentru a vă putea salva un pic de timp. Sintaxa va ieși întotdeauna perfectă și nu este nevoie să criptați singur parola. Iar cealaltă opțiune grozavă este protejarea prin parolă a unei liste a întregului director. Putem vedea acest exemplu în galeria de fragmente de cod CSS-Tricks.

AuthType Basic AuthName "Această zonă este protejată prin parolă" AuthUserFile /full/path/to/.htpasswd Aveți nevoie de utilizator valid

Securitate pentru WordPress

Pentru a pune această idee de protecție a parolei la o bună utilizare, să afișăm un exemplu din lumea reală. Acest fragment de cod mai complicat va forțați autentificarea utilizatorului pentru oricine care accesează fișierul WordPress wp-login.php. Veți găsi sursa originală pe Ask Apache, care are numeroase alte fragmente de protecție WordPress.

 Ordonare Deny, Permiteți Deny de la toate Satisfaceți orice AuthName "Protected By AskApache" AuthUserFile /web/askapache.com/.htpasswda1 AuthType Basic Necesită valid user

Și dacă urmează să urmați aceste reguli .htaccess, aceasta ar putea ajuta, de asemenea, la protecția prin parolă a zonei admin. În mod tipic wp-login.php fișierul va primi cele mai multe hit-uri de la oamenii care încearcă să brute forța lor de intrare în sistemul dumneavoastră. Deci chiar și codurile eșantionului de mai sus ar fi mai mult decât suficientă securitate adăugată pentru site-ul dvs. WordPress.

Reguli de rescriere a adreselor HTTP

Rescrierea adreselor URL este probabil una dintre cele mai frecvente utilizări pentru fișierele .htaccess. Instalațiile WordPress implicite pot de fapt generați un fișier .htaccess chiar de la panoul de administrare. Acest lucru vă permite să creați URL-uri destul de care nu au structura .php? P = 1.

Vreau să mă uit la exemplul ăsta de rescriere cum să actualizați sublinierile la liniuțe De cand conține multe dintre cele mai importante elemente.

Opțiuni + FollowSymLinks RewriteEngine RewriteBase / RewriteRule! \. (Html | php) $ - [S = 4] RewriteRule ^ ([^ _] *) _ ([^ _] *) _ [^ _] *) _ (. *) $ $ 1- $ 2- $ 3- $ 4- $ 5 [E = uscor: Da] RewriteRule ^ ([^ _] *) _ ] *) _ (. *) $ $ 1- $ 2- $ 3- $ 4 [E = uscor: Da] RewriteRule ^ ([^ _] *) _ $ 3 [E = uscor: Da] RewriteRule ^ ([^ _] *) _ (. *) $ $ 1- $ 2 [ //d.com/$1 [R = 301, L]

RewriteEngine și RewriteBase pot fi întotdeauna setate la aceste valori exacte. Dar aveți nevoie de RewriteEngine pornit pentru ca altceva să funcționeze. Există o mulțime de ghiduri online care explică cum să activați mod_rewrite și furnizorul dvs. de găzduire vă poate ajuta, de asemenea.

Observați că sintaxa urmează un model de RewriteRules în vârf. Aceste reguli sunt obișnuite se potrivesc cu cazurile trimise ca o solicitare HTTP. Acestea sunt răspuns de un RewriteRule care în acest caz redirecționează totul către domeniu d.com. Parantezele de final, cum ar fi [R = 301, L], se numesc steaguri de rescriere importante, dar mai mult de un subiect avansat.

Sintaxa mod_rewrite este cu siguranță o mică confuzie, dar nu fi intimidată! Fragmentele pot arăta mult mai ușor în alte exemple.

Când trebuie doar să începi, trebuie să recomand acest mod_rewrite webapp care vă ajută să generați eșantioane de cod folosind adrese URL reale. Acesta este un instrument genial pentru că puteți căuta diferite elemente din sintaxă pentru a vedea ce fac de fapt în regulile de revizuire. Iată un alt tutorial excelent, cu un exemplu mai simplu de studiu:

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

Nu încercați să vă supraîncărcați pe toate acestea odată. Mi-a luat bine peste 3-4 luni pentru a începe cu adevărat să înțeleg cum să rescrieți URL-urile cu [0-9a-zA-Z] + și modele similare. Continuă să practici și, în timp, îți promit că vei primi chestiile astea ca și cunoștințele obișnuite.

Fragmente de cod pentru webmasteri

Îmi place fragmente ușor de folosit și vreau să pun împreună această mică colecție de coduri .htaccess pertinente pentru webmasteri. Fiecare dintre aceste idei se poate potrivi frumos în propriul fișier .htaccess împreună cu alte blocuri de coduri. Cele mai multe dintre aceste fragmente sunt excelente rezolvarea problemelor rapide sau remedierile în mediul serverului dvs. web. Imaginați-vă că configurația perfectă Apache pentru webmasteri noi este doar începută online.

Setarea DirectoryIndex

Comanda pentru DirectoryIndex este folosită de obicei într-o singură linie. Puteți spune lui Apache ce documente ar trebui tratate inițial ca “principal” document. Implicit, acest lucru se va întâmpla elemente-țintă, cum ar fi index.html, index.php, index.asp și alte fișiere index. Dar folosind acest fragment de cod pe care l-am copiat mai jos, aveți posibilitatea de a face acest document rădăcină orice doriți.

IndexIndex index.html index.cgi index.php

Ordinea documentelor ar trebui să înceapă cu cele mai importante și să treacă prin rânduri la cele mai puțin importante. Deci, dacă nu avem un fișier HTML sau CGI, atunci vom reveni la rezervă index.php. Și puteți chiar să numiți aceste fișiere home.php sau someotherfile.php și este o sintaxă validă.

Force WWW sau subdomeniu non-WWW

Google poate lucra cu ambele versiuni ale domeniului site-ului dvs. dacă nu specificați www.domain.com sau doar domain.com. Din experiența mea este cea mai bună practică alegeți una dintre acestea și setați-o ca singura alegere prin .htaccess. Apoi Google nu va indexa diferite adrese URL cu unele îndreptate către subdomeniul WWW în timp ce altele nu.

# Subdomeniu forțat pe WWW RewriteEngine pe RewriteCond% HTTP_HOST ^ domain.com [NC] RewriteRule ^ (. *) $ Http://www.domain.com/$1 [L, R = 301] # Subdomeniu RewriteEngine Pe RewriteCond% HTTP_HOST! ^ Domeniu.com $ [NC] RewriteRule ^ (. *) $ Http://domain.com/$1 [L, R = 301]

Acest fragment de cod provine dintr-o arhivă CSS-Tricks și oferă o soluție foarte utilă. Ar trebui să actualizați domeniul pentru a fi ceea ce aveți nevoie pentru propriul dvs. site web. În caz contrar, vor apărea probleme și veți observa imediat! Dar susțin foarte mult forțarea uneia dintre aceste două opțiuni și este în fruntea listei mele de sarcini după lansarea unui nou site web.

Descărcați fișiere media force

Un alt fragment destul de important permite forțarea anumitor tipuri de suporturi media descărcați în loc să fie afișat în browser. Imediat mă pot gândi la documente PDF și fișiere audio MP3 care pot fi prezentate într-un format care poate fi descărcat, dar cum faceți asigurați-vă că sunt descărcabile? Am găsit un articol similar publicat pe Ghidul Htaccess care descrie acest fragment de cod.

Aplicația AddType / octet-stream .zip .mp3 .mp4

Simțiți-vă liber să includeți și mai multe fișiere la sfârșitul acestei linii. Toate formatele media care utilizează tipul MIME de tip octet vor fi descărcate. Forțând acest lucru .htaccess este o cale foarte directă pentru a vă asigura că oamenii nu văd aceste fișiere în browser.

Documente de eroare personalizate

O ultimă piesă finală pe care vreau să o adaug este un șablon complet al documentelor de eroare personalizate. De obicei, aceste coduri de număr se văd numai la sfârșitul serverului. Dar există o mulțime de documente de eroare pe care ar trebui să le cunoașteți. Câteva exemple ar putea fi Erori 403/404 si 301 redirecționare.

Acest șablon de cod de eroare începe la 100 și se mută în sus în 500 de erori. Rețineți că, evident, nu aveți nevoie de toate acestea. Numai cele mai frecvente erori ar fi necesare și, eventual, câteva fragmente obscure dacă simțiți nevoia.

Dacă nu recunoașteți un cod, căutați-l pe Wikipedia pentru a înțelege mai bine.

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 Document de eroare 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

Webapps-urile online .htaccess

Htaccess Builder
.generator de redirecționare htaccess
.htaccessEditor - Creați un fișier .htaccess
Mod Rescrie Generator de către GenerateIt.net

Alte resurse utile

.htaccess în Httpd Wiki
Documentația oficială Apache htaccess
Intreaba Apache Blog - Arhiva Htaccess
Ultimate Ghid pentru htaccess și mod_rewrite
Tot ce ați vrut să știți despre regulile Mod_Rewrite, dar s-au temut să întrebați

Gândurile finale

Există atât de multe resurse nenumărate care discută online fișierele .htaccess. Articolele și aplicațiile mele legate sunt un loc minunat pentru a începe. Dar continuă să practice idei noi și să nu vă fie frică testarea fragmentelor de cod. Atata timp cat aveți un fișier de rezervă atunci puteți testa orice vă place și este o experiență de învățare distractivă.

Dacă aveți alte idei sau sugestii despre managementul .htaccess, vă rugăm să ne comunicați în zona de discuții post mai jos.