Depistarea regulilor de depanare, sau puțin în legătură cu viața intimă a mod_rewrite

RewriteEngine a fost întotdeauna un subiect destul de stresant pentru mine. Abia de curând mi-am descoperit brusc că totul sa împotmolit într-un fel și a devenit mai mult sau mai puțin clar. Din moment ce sunt o persoană obișnuită, sunt sigur că situația de eroare a configurării serverului de web "nu" a ajuns doar pe mine și grăbesc să împărtășesc experiența mea.

Sa dovedit a fi ceva între manualul de utilizare a modulului mod_rewrite și un fel de ghid pentru configurarea serverului web utilizând fișierul .htaccess. În trecere, aș dori să mă concentrez asupra unor momente deosebit de dificile sau nereușite.

Datele inițiale pentru experimente

• Toate experimentele sunt efectuate pe gazda locală.
  
• Serverul de lampă este instalat
  
• Versiunea Apache: 2.4.9 (build pentru Unix)
  
• Folderul / opt / lampp / htdocs / bbb / _engine conține un site experimentat pe motor.bbb.ru domeniu. Dosarul specificat este root (DocumentRoot).
  
• În directorul rădăcină al site-ului există doar o pagină ind.php.
  
• Site-ul are un folder / opt / lampp / htdocs / bbb / _engine / local.
  
• Acesta conține un fișier script ind1.php
  

Configurarea gazdelor virtuale

Pentru a face mai ușor de lucru, depanare și nu vă deranjează nervii de unde nu puteți face acest lucru, este bine să configurați gazde virtuale în termeni de conveniență. Luați în considerare cele mai simple setări, ceea ce va facilita foarte mult viața noastră.

Jurnale personalizate

Puține persoane de pe serverul local au un singur domeniu. Există de obicei o mulțime de domenii. Ar fi frumos să separăm jurnalele de domeniu și de zi, astfel încât să nu crească prea mult. Acest lucru se face prin secțiunea de setări a serverului nostru.

Pentru jurnalul de erori de pe domeniul nostru, adăugați următoarele două linii.

Primul specifică numele jurnalului de erori pentru serverul virtual și determină începerea noului jurnal la fiecare 86400 secunde. Rotatelogs este un program care este în general inclus în serverul de web Apache și sper că l-ați instalat prea.

A doua linie specifică formatul fiecărei linii a jurnalului de erori. Detalii se găsesc în documentația pentru serverul Apache. Totul este destul de clar acolo. În contextul acestui articol, este important să rețineți pur și simplu că formatul este personalizabil.

Pentru jurnalul de acces, includ numai o linie pe site-ul meu. Formatul șirului "implicit" îmi convine de obicei.

În ambele cazuri, acordați atenție căilor spre programele serverului web și la jurnale. Trebuie să instalați căile care există pe computerul dvs.

Cele mai generale informații despre cum funcționează totul

în fișierul .htaccess. care va gestiona acest dosar. În plus, avem sub această linie și alte directive și mai multe reguli de rescriere.

Să presupunem că serverul primește o adresă URL la intrare. RewriteEngine începe să verifice această adresă URL folosind regulile. El o face de sus în jos în ordine. Dacă adresa URL de intrare nu satisface nicio regulă, atunci se numește "trece". De exemplu, să presupunem că avem un fișier index.php în dosarul rădăcină. Dacă intrarea uri "/index.php" nu satisface nici o regulă, atunci vom vedea rezultatul acestui script în browser.

Dacă avem următoarea regulă

atunci, evident, această regulă pentru ury "index.php" va funcționa. În acest caz, URI va fi rescris la "" și un nou URI "/" va fi trimis la intrarea serverului. Și întregul proces de aplicare a regulilor va merge din nou. Numai dacă uri "/" nu respectă niciuna dintre regulile noastre, vom vedea ce vrem. Și dacă satisface, va fi rescris din nou și totul va fi repetat din nou.

Cum funcționează steagul [L]

Probabil, acest steag introduce o mulțime de neînțelegeri. Prezența drapelului previne Uri de intrare de test pe următoarele reguli pentru el, în cazul în care această regulă a lucrat. Asta e tot. Adică, dacă ne Uri «index.php» a fost testat (de obicei, a lucrat pentru el), apoi din cauza prezenței drapelului [L] întrerupem toate controalele ulterioare, și serverul de web produce imediat rescrierea «index.php» -> „“ și primește uri de intrare „/“ ([INTERNĂ REDIRECT]), și se repetă de la început, cu prima regulă. În cazul în care acest indicator nu este prezent, atunci rescrierea este încă în desfășurare și de verificare continuă cu următoarea regulă. Dar ury va fi deja schimbat, și anume "/".

Înțelegerea acestui proces împiedică imediat multe redirecționări ciclice.

Dar lasă-mă, dacă în scris mai sus, înseamnă că, dacă nu utilizați pavilion [L], vom economisi timp, iar pagina va fi deschis în curând? Întâlnim steagul [L] și trebuie să treacă din nou prin toate regulile, fără excepție, și dacă nu pune steagul [L], atunci vom face pe regula de rescriere declanșat, va merge la sfârșitul tuturor normelor și în acest scop?

Am verificat. Nu funcționează. În absența steaguri [L], modulul, cum era de așteptat, pentru a înlocui Uri declanșat de regulă, merge pe toate regulile rămase până la sfârșit, atunci produce [INTERNĂ REDIRECT] și încă se execută în acest Uri toate regulile din nou. Asta este ceea ce am scris despre cele de mai sus. Această regulă pare să nu aibă nicio excepție.

Concluzie: întotdeauna, când se declanșează regula RewriteRule, apare [INTERNAL REDIRECT] și toate regulile sunt reaplicate. Această a doua trecere începe fie imediat după aplicarea regulii cu pavilionul [L], fie după terminarea tuturor regulilor, dacă lucrăm fără steaguri [L]. Situația de "transmitere" a adresei URL și se numește "trece prin" poate apărea numai dacă nu a fost aplicată nicio regulă. Steagul [L] poate reduce timpul de procesare pentru uri și ar trebui utilizat ori de câte ori este posibil.

Ce este RewriteBase?

Această instrucțiune, după părerea mea, este pur și simplu un titular de înregistrări în termeni de neînțelegere! I-aș da un premiu pentru asta! Având în vedere acest lucru, am două povestiri despre această fiară - scurtă și lungă. O scurtă poveste pentru cei care nu vor să se descurce cu această instrucțiune. Pentru cei interesați.

Poveste scurtă

Dacă faceți o rescriere relativ simplă a URL-urilor cu fișiere .htaccess, atunci recomandăm întotdeauna să procedați după cum urmează.

• Nu utilizați directiva descrisă în general.
  
• În toate regulile de rescriere, adresa URL țintă ar trebui să înceapă întotdeauna cu un slash (o indicație că URI este specificat în raport cu rădăcina site-ului)
  

Poveste lungă

La rescriere, vor apărea următoarele procese:

• Rootul documentului: / opt / lampp / htdocs / bbb / _engine
  
• Fișierul .htaccess se află în același loc în Document Root
  

• Serviciul de rescriere va duce calea fișierului solicitat la calea sa în sistemul de fișiere, și anume opt / lampp / htdocs / bbb / _engine / ind.php
  
• Se va elimina din acesta prefixul opt / lampp / htdocs / bbb / _engine / (coincide cu calea către dosarul în care este .htaccess este.)
  
• Va aplica regulile de rescriere folosind linia "ind.php"
  

• Cerem url engine.bbb.ru/local/ind1.php
  
• Serviciul de rescriere va duce calea fișierului solicitat la calea sa în sistemul de fișiere, și anume opt / lampp / htdocs / bbb / _engine / local / ind1.php
  
• Îndepărtați prefixul opt / lampp / htdocs / bbb / _engine /
  
• Va aplica regulile de rescriere folosind șirul "local / ind.php"
  

• Cerem url engine.bbb.ru/local/ind1.php
  
• Serviciul de rescriere va duce calea fișierului solicitat la calea sa în sistemul de fișiere, și anume opt / lampp / htdocs / bbb / _engine / local / ind1.php
  
• Acesta va elimina prefixul opt / lampp / htdocs / bbb / _engine / local / (aceasta este calea către dosarul în care se află fișierul .htaccess din directorul / local)
  
• Va aplica regulile de rescriere folosind linia "ind1.php"
  

Ce afectează directiva RewriteBase?

Este foarte important să rețineți că adresa URL specifică directiva RewriteBase! Nu se poate specifica acolo "local /" Va exista o eroare! Puteți utiliza numai "/ local".

În /opt/lampp/htdocs/bbb/_engine/local/.htaccess l-am specificat

Cerem url engine.bbb.ru/local/

Acesta va funcționa! Și trecerea la url /local/ind1.php

va funcționa, de asemenea, dar tranziția se va face pe ur /ind1.php. Fișierul nu a fost găsit! Nu avem această ura (relativă la rădăcina site-ului)!

Concluzia 1: Adresa URL pe care o specificăm în RewriteBase este adăugată ca prefix la adresa URI țintă în cazul în care este relativă, adică nu există o slash la început.

Concluzia 2: Dacă nu vom folosi niciodată reguli țintă relative în reguli, atunci directiva RewriteBase nu este necesară!

Concluzia 3: Dacă folosim "RewriteBase /", atunci când regula este declanșată

Va fi o încercare de a trece la ur /ind1.php. Folosim doar "/" ca prefix.

Avem următoarele reguli RewriteEngine în fișierul .htaccess:

Dacă RewriteBase este o adresă URL, atunci să instalați

Nu, nu este. Nu trece. Eroare "Argumentul RewriteBase: nu este o adresă URL validă". E ciudat, nu-i așa? Dar nu renunțăm! Schimbați RewriteBase!

În acest caz, nu există nici o eroare! Ce avem de-a face cu căile? O mulțime de interesant!
Serverul primește sincer calea / opt / lampp / htdocs / bbb / _engine /. elimină prefixul / opt / lampp / htdocs / bbb / _engine / din acesta și funcționează cu un șir gol ('').
Ne întoarcem după regulă și schimbăm sirul gol în "ind.php"
Citește cu prefixul "//bbb.ru" și du-te la următoarea trecere. Această a doua trecere este echivalentă cu apelarea motor.bbb.ru//bbb.ru/ind.php. că, în ansamblu, nu este deloc ceea ce dorim (a existat o dorință inițială de a trece la alt site). Pe scurt, ideea nu sa justificat. Ca rezultat, avem o eroare 404, ceea ce este logic. Apropo, "//" au fost înlocuite de server în procesul de rescriere la "/". Urmele acestui exemplu sunt date cu mult mai mici.

Cum am obținut toate aceste informații uluitoare despre viața intimă a serverului Apache? Sau, în cele din urmă, despre depanare

Într-adevăr! Cum am putut vedea erorile generate de serviciul de redenumire a adreselor URL? La urma urmei, acesta este exact depanarea! Există o directivă foarte utilă pe care am inserat-o în gazde virtuale pentru domeniul engine.bbb.ru. și anume,

Și ce este "avertizat"? În mod logic, înregistrarea noastră LogLevel înseamnă că pentru toate modulele nivelul de erori este avertizat și numai pentru rescrierea modulului este trace4

Ce obținem ca rezultat al depanării?

Vă prezint următoarea rescriere cu următoarele condiții:

Depanarea este eficientă pentru gazda virtuală pentru care

Dacă domeniul engine.bbb.ru utilizează stiluri externe css, care sunt preluate din domeniul bbb.ru. și problema este în acest caz, atunci nu este nevoie să includeți depanarea în serverul virtual motor.bbb.ru, dar trebuie să îl includeți în serverul virtual bbb.ru. Apoi toate apelurile către domeniul bbb.ru ar trebui să arate în jurnalele de eroare (nu accesați!) Domain bbb.ru. Astfel apelurile la obiectele urmărite nu vor fi în jurnalele de acces la toate!

Și nu puteți folosi o astfel de RewriteEngine atât de stresantă în general?

Puteți trece la utilizarea unui singur script pentru întreg site-ul și faceți tot rescrierea în el. În PHP, acest lucru este mai ușor de făcut, iar depanarea este mult mai ușoară. În plus față de avantajele evidente în ceea ce privește securitatea site-ului, obținem confortul de rescriere fără hassle. Pentru a trece la o astfel de schemă de lucru, htaccess-ul nostru ar trebui să fie ceva de genul:

Și în script-ul dispatch.php vă sfătuiesc cu tărie să nu uitați să interzicați un apel direct la dispatch.php în sine.

Dacă doriți brusc să adoptați această abordare, atunci vă recomand că scriptul dispatch.php să fie numit altceva. Am folosit acest nume doar pentru scopuri de claritate.

Apropo, această abordare este pusă în aplicare destul de activ. Acest lucru ar trebui să fie recunoscător pentru introducerea CNC (adrese URL de înțeles pentru oameni, deși personal pentru mine sunt foarte de neînțeles). Aproape în toate motoarele moderne funcționează deja.

Hacking D-Link DIR-890L
În ultimele 6 luni am fost teribil de ocupat și nu a urmat noua prostiile de la D-Link. Pentru a avea unele distractiv, m-am dus la site-ul lor și am fost întâmpinat de acest coșmar: cel mai nebunesc router D-Link DIR-890L 300 $ Poate cel mai „nebun“ în router este că se execută toate același firmware zabagovannoy, D-Link introduce

Asamblarea automată a pachetelor pentru CMS Joomla!
Înainte de a începe să lucrez la proiectul actual, nu credeam că va trebui să folosesc instrumente pentru a construi automat proiecte. La urma urmei, lucrez exclusiv cu limbi interpretate care nu au nevoie de compilare. Cu toate acestea, după cum sa dovedit, ele pot fi utile atunci când se dezvoltă pe PHP, și mai ales atunci când lucrează cu Joomla!

Versiunea mea de .htaccess
Într-unul din posturile noastre anterioare privind .htaccess tematice pentru începători, aș dori să ofere propria versiune cu diferite tratamente și interdicții, precum și de structurare anumită logică, dar karma a fost în roșu, atunci răspândirea este acum. Atenția dvs. la atenția acordată regulilor de procesare a adreselor URL cu explicații și comentarii "de ce?".

DDOS-bot pe PHP merge pe servere
Astăzi, aproximativ două ore dimineața, când am vrut să dorm, unul dintre prietenii mei mi-a scris pe Skype. Anul trecut l-am ajutat să administreze mai multe servere. La un moment dat, el a scris că interfața de rețea a unuia dintre serverele sale este complet înfundată, judecând după programul lui mrtg. M-am uitat, într-adevăr, nu am putut ajunge nici măcar

Trimiteți-le prietenilor: