Probabil ati auzit cu totii de fisierul .htaccess. Contextul era probabil fie implementarea unei pagini eronate editata ori restrictionarea accesului la anumite directoare prin intermediul parolelor. Fisierul are insa nenumarate roluri.

Cateva idei generale. .htaccess este un simplu fisier ASCII, usor de creat in Notepad ori SimpleText. Probabil sunt destui utilizatori confuzi in privinta numelui fisierului. .htaccess este extensia fisierului si se foloseste exact cum este dat. Nu exista ceva.htaccess sau altceva.htaccess, ci doar .htaccess.

Pentru a crea un astfel de fisier, deschideti un editor de text si salvati o pagina goala sub denumirea .htaccess (sau scrieti un caracter in numele fisierului pentru ca nu toate editoarele vor permite salvarea unei pagini nescrise). Foarte probabil este ca editorul vostru sa ataseze automat extensia default fisierului (spre exemplu Notepad va numi fisierul .htaccess). Trebuie sa stergeti extensia suplimentara .htaccess (sau oricare alta) pentru a putea folosi fisierul. Puteti face asta redenumind fisierul (Click dreapta - Rename | F2). Il puteti redenumi si folosind telnet ori un program de ftp si cazurile respective nu au nevoie de explicatii suplimentare.

Fisierele tip .htaccess trebuie salvate si incarcate in modul ASCII, nu cel BINARY. Exista posibilitatea in care va trebui sa folositi comanda CHMOD sa schimbati caracteristicile fisierului la 644 sau (RW-R--R--). Astfel fisierul poate fi folosit de catre server, dar il impiedica de-a putea fi citit de catre un browser, neputand astfel compromite integritatea paginii. Spre exemplu, daca aveti directoare ce necesita parola pentru-a putea fi accesate pe server, daca un browser poate citi fisierul .htaccess, atunci utilizatorii pot obtine cu usurinta locatia fisierului de autentificare si inversa procesul pentru-a obtine acces partial sau complet la oricare dintre directoarele odata parolate. Exista diferite metode pentru-a impiedica acest lucru, una dintre ele fiind plasarea tuturor fisierelor de autentificare in directorul root, astfel incat ele nu pot fi accesate sub www., cealalta configurand fisierul .htaccess printr-o serie de comenzi ce ar impiedica accesarea sa printr-un browser.

Majoritatea comenzilor din .htaccess sunt destinate folosirii pe un singur rand, asa ca folosind un editor text ce are activata optiunea de 'word-wrap', ar mai putea adauga cateva caractere la final, enervand Apache la nesfarsit, desi saracu' e obisnuit cu malformari intalnite in fisier.

.htaccess este o chestie de Apache, nu una de NT. Exista omologi nu chiar perfecti ca statut pentru serverele NT, desi NT are nenumarate handicapuri privind compatibilitatea cu un astfel de fisier.

Fisierele tip .htaccess afecteaza directorul in care sunt asezate si toate subdirectoarele (un astfel de fisier plasat in directorul root -ceva.com- va afecta ceva.com/continut/, ceva.com/continut/director3 etc.). Este extrem de important sa stim ca acest lucru poate fi impiedicat (daca nu doriti ca fisierul .htaccess sa afecteze anumite subdirectoare, spre exemplu) amplasant un nou fisier .htaccess in interiorul directorului ce nu vreti sa fie afectat de anumite schimbari. Daca cel mai apropiat fisier .htaccess este cel asezat in directorul root atunci el va afecta orice director de pe site.

Inainte sa incepeti sa plasati fisierul oriunde, documentati-va in domeniu, existand sansa ca el, fisierul, sa cauzeze un adevarat cataclism caracterizat de redirectionarea infinite redirectionari catre alte portiuni ale paginii.

De asemenea, exista anumite pagini ce nu accepta folosirea fisierelor .htaccess, deoarece depinzand de rolul care-l au, ele pot incetini un server cu domenii ce au fiecare cate-un .htaccess. Trebuie sa fiti siguri ca va este permisa incarcarea unui fisier ge acest tip inainte de-a incerca folosirea lui. Anumite comenzi din .htaccess pot cauza compromiterea configurarii unui server, asa ca nu intrati la necaz.

Aceasta a fost doar o introducere. Va continua.

Premisă: testmenow.go.ro

Aşa cum am spus mai devreme, .htaccess poate fi folosit pentru implementarea unei pagini eronate editată. Pentru a face acest lucru este necesar să aveţi idee de codurile eronate returnate de server. Nu este nevoie să implementaţi un ErrorDocument pentru toate paginile de eroare. De drept, chiar nu se recomandă. Un ErrorDocument pentru codul 200, de exemplu, va cauza o serie infinită de redirecţionări atunci când pagina accesată există. Mai jos este o listă a posibilelor "coduri de eroare" returnate de server şi capabile de editare cu .htaccess:

Găsiţi aici detalii suplimentare despre aceste erori.

Probabil vei dori crearea unor ErrorDocuments pentru coduri precum 404 şi 500; 404 va oferi posibilitatea de-a manevra cererile către pagini inexistente, iar 500 vă va ajuta cu erorile interioare ale server-ului, indiferent de ce script-uri rulaţi. Preferabil ar fi să iei în calcul şi crearea unui ErrorDocument pentru codurile 401 (atunci când cineva încearcă să acceseze o secţiune protejată a site-ului tău fără a avea drepturile necesare), 403 (atunci când un fişier ce nu poate fi accesat de către un utilizator este cerut) şi 400 (eroare generică pe care utilizatorii o primesc atunci când încearcă să manevreze URL-ul şi script-urile tale).

Pentru a vă putea edita documentele de eroare adăugaţi următoarea comandă în fişierul .htaccess:

• Orice cod 404 va fi redirecţionat către pagina-voastră.com/erori/notfound.html

Poţi numi paginile de eroare cum vrea muşchii tăi (eventual ceva ce v-ar aminti pentru ce este folosită acea pagină) şi le poţi stoca oriunde doreşti, atâta timp cât ele pot fi accesate printr-un URL direct. Slash-ul iniţial din locaţia directorului reprezintă directorul root al paginii. Unii preferă stocarea lor într-un director distinct din motive de administrare şi pentru a preveni indexarea lor printr-un fişier ROBOTS.TXT, dar asta depinde exclusiv de voi.

Dacă vreţi să folosiţi această posibilitate pentru fiecare dintre codurile de eroare de mai sus atunci fişierul .htaccess ar arăta cam aşa:

Puteţi specifica întreaga adresă în defavoarea uneia virtuale (http://pagină.com/erori/notfound.html vs. /erori/notfound.html), dar această setare s-ar putea lovi de standardele anumitor servere.

Vă puteţi folosi chiar de HTML, total opţional.

Personal folosesc posibilitatea de HTML doar din simplitate, dispunând de mai mult control asupra paginilor de eroare atunci când se foloseşte xSSI, CGI sau o combinaţie între cele două. Ţineţi cont că în cazul de faţă codul HTML începe cu o ", dar nu se termină cu una.

Cam asta ar fi despre documentele de eroare. Distrugeţi-vă pagina pentru a vedea cum funcţionează Va urma.

Ai vrut vreodată ca o anumită secţiune a paginii tale, un anumit director poate, să poată fi accesat doar de către anumite persoane? Nu ţi s-a părut frustrant atunci când găurile anumitor operaţiuni permiteau practic oricui cu destule cunoştinţe să poată intra datorita sursei paginii? Vom discuta mai departe despre folosinţa fişierului .htaccess în cazul protejării în spatele unei parole.

Există numeroase metode de-a proteja zone ale paginii tale, unele prin limbaje de programare pentru server (precum ASP, PHP sau PERL) altele rămase la statutul de client, precum JavaScript. .htaccess este una dintre cele mai bune metode de protecţie pe care o puteţi folosi, are însă şi scăpările sale. Dacă nu te simţi confortabil cu folosirea metodei .htaccess, atunci vei găsi online nenumărate alte surse şi .. resurse.

Primul lucru care trebuie făcut este crearea unui fişier numit .htpasswd. Dacă vei avea probleme cu crearea sau redenumirea fişierului, citeşte primul fragment al acestui tutorial. În fişierul .htpasswd vei adăuga username-ul şi parola ta (encryptată, desigur) - într-un format username:parolă -, cont ce va fi folosit de cei cărora le vei permite accesul în zona respectivă.

De exemplu, dacă username-ul este rebel, iar parola aidoma (nu că s-ar recomanda aşa ceva), fişierul .htpasswd ar arăta cam aşa:

Reţineţi că înaintea celor două puncte este username-ul, iar mai apoi parola encryptată. Găsiţi aici un programel ce encryptează fără mare bătaie de cap parole folosindu-se de codul necesar pentru fişierul .htpasswd.

Din motive de securitate n-ar trebui să încărcaţi fişierul .htpasswd într-un director ce poate fi accesat pe web (pagină.com/.htpasswd); el ar trebui plasat mai sus de directorul de principal al paginii. De asemenea, .htpasswd şi .htaccess trebuiesc încărcate ca ASCII, şi nu BINARY.

Şi că tot vorbirăm de .htaccess .. Pentru ca parolarea să aibă efect, adăugaţi următoarele linii în acest fişier:

Prima linie reprezintă adresa completă şi exactă către fişierul .htpasswd. Dacă ai mai instalat script-uri pe server ar trebui să ştii cum trebuie făcut aici. Să nu confundăm această adresă cu o adresă tip URL. Aceasta este o cărare a serverului. De asemenea, ca şi în cazul paginilor de eroare, dacă plasaţi fişierul .htaccess în directorul root atunci el va parola întreaga pagină (Fie vorba-ntre noi .. măcar prefă-te că asta ţi-a fost intenţia iniţială ).

Linia AuthName este numele porţiunii de pagină unde vrem să ajungem şi poate purta orice nume. Ultima linie - require user este comanda unde se cere username-ul celuia ce va avea acces la porţiunea respectivă a paginii. Dacă opţiunea este folosită ca în cazul de mai sus, atunci doar cineva autentificat ca rebel va putea intra. Dacă vrei ca mai mulţi utilizatori să aibă acces la acea porţiune, atunci completează-le conturile de autentificare în fişierul .htpasswd şi înlocuieşte rândul require user din fişierul .htaccess cu require valid-user.

Am folosit AuthType Basic pentru că folosim metoda primordială de autentificare HTTP.

Va urma.

O altă posibilă utilizare a fişierului .htaccess apare la activarea opţiunii SSI (Server Side Includes), abilitate aparent indisponibilă la majoritatea web hosting-urilor. SSI sunt directive ce sunt aşezate în paginile HTML şi sunt evaluate pe server atunci când paginile sunt accesate. Ele permit adăugarea unui conţinut generat dinamic unei pagini HTML existente, fără a fi necesară servirea întregii pagini printr-un program CGI (Common Gateway Interface) ori alte tehnologii dinamice. Ele pot fi modificate prin folosirea unui fişier tip .htaccess. Ca notă de siguranţă, consultaţi-vă cu hosting-ul ce-l folosiţi înainte de-a folosi această metodă; ea poate fi considerată o violare a termenilor de utilizare.

Prima linie indică server-ului că paginile cu extensia .shtml extension (destinate HTML-ului analizat de server) este valid. A doua linie adaugă un agent de control, partea specifică SSI, în toate fişierele cu extensia .shtml. Aceasta indică server-ului că orice pagină cu această extensie ar trebui servită pentru comenzi server side. Ultima linie e acea alambicare tehnică ce ar trebui adăugată

Cam aşa ar trebui să fie şi procedând astfel ar trebui să reuşiţi să activaţi SSI-ul. Dacă vreţi să profitaţi din plin de această jucărie redenumiţi toate paginile în extensia .shtml. Pentru aceasta adăugaţi următorul rând după primul:

Cu grjiă, însă. Aceasta va forţa server-ul să caute prin toate paginile .html comenzi tip SSI, chiar dacă acestea nu sunt prezente în componenţa paginilor. Dacă folosiţi SSI pentru a preveni accesul la anumite zone ale site-ului aceasta va cauza mai mult consum de bandă decât puteţi justifica. SSI încetineşte server-ul pentru că execută operaţiuni suplimentare înainte de a servi pagina, deşi în privire umană timpul suplimentar consumat este aproape transparent. Poate unii ar prefera activarea SSI în paginile .html pentru a preveni compromiterea server-ului, sistemul SSI fiind relativ vulnerabil. În orice situaţie, informaţiile de mai sus ar trebui să fie suficiente.

Dacă vei dori să păstrezi paginile SSI cu extensia .shtml şi vreţi să folosiţi SSI în paginile de index, adăugaţi urmatoarea în fişierul .htaccess:

Aceasta citeşte index.shtml ca pagina default a site-ului, iar dacă nu este găsită redirecţionează către index.shtml. Mai multe detalii despre DirectoryIndex vor apărea pe viitor.

O altă funcţiune a fişierului .htaccess ar fi blocarea unui IP de la accesarea site-ului.

Pentru aceasta, ataşaţi următorul cod, modificând adresele de IP la setările tale, fiecare dintre comenzi aparţinând unui rând distinct:

Puteţi bloca accesul unui singur IP sau puteţi efectua un blocaj pe o anumită clasă de IP-uri. Exemplul de mai sus va bloca accesul către site pentru persoana ce foloseşte IP-ul 123.45.6.7 şi pentru orice IP al clasei 123.45.5 (123.45.5.1, 123.45.5.2, 123.45.5.3 etc.).

Există, evident posibilitatea de a folosi deny from all şi nu ştiu dacă mai e cazul de explicaţii aici. Puteţi, de asemenea, bloca sau permite accesul unui nume de domeniu, în locul unui IP sau a unei clase de IP-uri. De exemplu:

Notă: .hanuancutei.com include www.hanuancutei.com, virtual.hanuancutei.com etc.

Poate unii dintre voi vă întrebaţi ce este un DirectoryIndex. Aceasta este o comandă ce permite specificarea unui fişier ce urmează a fi încărcat ca pagina default atunci când se cere accesarea unei adrese în mod direct, fără menţiunea fişierului dorit din adresa respectivă. De exemplu, de obicei, accesând www.ceva.com, suntem redirecţionaţi la www.ceva.com/index.html. Dacă se vrea un alt nume pentru acel index atunci se foloseşte:

Efectul ar fi considerarea fişier.html ca pagina default sau pagina default pentru directorul în care vă aflaţi. De asemenea, puteţi aplica şi alte fişiere acestei comenzi. Poate veţi dori ca anumite directoare să folosească un script ca pagina default:

Folosirea comenzii de mai sus în fişierul .htaccess va avea următoarele efecte: Când un utilizator accesează www.ceva.com, pagina va căuta fişier.html în directorul root (sau orice alt director, dacă comanda este aplicată în fişierul global .htaccess al paginii) şi, dacă-l va găsi, atunci îl va încărca precum pagina default. Dacă nu va găsi fişier.html, atunci va căuta lndex.cgi; dacă acesta este localizat, el va fi încărcat. Altminteri, va căuta lndex.pl, reprezând întregul proces până va localiza un fişier ce poate fi folosit. Parametrii căutarii sunt aleşi în ordine de la stânga la dreapta.

Nu ştiu vouă de vi s-a întâmplat, dar eu am păţit-o să fac schimbări importante ale paginii, confruntându-mă mai apoi cu problema că utilizatorii nu-şi găseau calea către noile resurse. Există metode diferite de redirecţionare a paginilor, prin http-equiv, javascript sau orice alt limbaj. Folosirea fişierului .htaccess pentru redirecţionare este, însă, cea mai eficientă dintre aceste metode, analizând cantitatea minimală de efort care trebuie depusă pentru a rezolva situaţia.

.htaccess foloseşte redirecţionarea pentru a căuta orice cerere a unei pagini anume (sau a unei locaţii nespecificate, deşi aceasta ar cauza redirecţionări infinite) şi, în cazul în care găseşte rezultatul dorit, atunci lansează pagina nouă:

Această comanda conţine trei părţi, fiind necesar ca toate dintre acestea să se găsească pe acelaşi rând: comanda Redirect, pagina accesată iniţial şi destinaţia redirecţionării în formatul adresei complete. Puteţi, de asemenea, executa o redirecţionare al unui întreg director folosind:

Dacă foloseşti .htaccess pentru protejarea prin parolă, atunci locaţia ce conţine toate informaţiile despre parole este perfect vizibilă prin intermediul fişierului .htaccess. Dacă nu v-aţi setat corespunzător permisiunile sau dacă gazda paginii tale nu este pe cât de sigură ar putea fi, un simplu browser ar putea avea potenţialul de-a vizualiza fişierul .htaccess printr-o interfaţa web standard, compromiţând astfel pagina/server-ul. Aceasta ar fi, în mod evident, un lucru pe care nimeni nu şi-l doreşte. Tocmai de aceea este posibilă o prevenire a vizualizării acestui fişier:

Prima linie specifică numeşte fişierul .htaccess ca singurul asupra căruia comanda va avea efect. Ea poate fi folosită şi pentru alte fişiere, dacă deveniţi îndestul de creativi

Dacă folosiţi acea comandă, persoana care încearcă să acceseze fişierul respectiv va fi redirecţionată către un cod de eroare 403. De asemenea, puteţi seta restricţii asupra fişierului .htaccess prin intermediul CHMOD, ce ar evita redirecţionarea către o eroare, ca o măsură sporită de siguranţă.

Se întâmplă ca server-ul vostru să nu livreze anumite tipuri de fişiere corespunzător, întâmplări frecvente până şi cu fişiere MP3 şi chiar SWF. Destul de simplu de reparat:

AddType specifică faptul că adăugaţi un tip MIME. Aplicaţia este parametrul actual al MIME-ului ce sunteţi pe cale să-l adăugaţi, iar ultima parte a comenzii este extensia default a tipului MIME pe care l-aţi adăugat. În exemplul de mai sus am folosit swf pentru fişierele ShockWave.