2020 Volledige handleiding tot .HAKKE – Van die basiese beginsels tot gevorderde leer

openbaarmaking: U ondersteuning help om die webwerf aan die gang te hou! Ons verdien ‘n verwysingsfooi vir sommige van die dienste wat ons op hierdie bladsy aanbeveel.


Met die gebruik van die .htaccess-lêer kan u baie aspekte van die Apache-webbediener (en sy vele variante) beheer. Hieronder leer u alles wat u nodig het om op te stel, stel spesiale foutbladsye op, lêergidse om wagwoorde te beskerm, herlei en nog baie meer.

Contents

Hoe om hierdie gids te gebruik

Hierdie gids is gebou om te dien as ‘n omvattende bron vir die gebruik van .htaccess. As u heeltemal nuut is met die gebruik van .htaccess – wil u dalk met die eerste hoofstuk “.htaccess Basics” hieronder begin.

As u op soek is na spesifieke kodemonsters of tutoriale, kyk na die navigasie aan die regterkant van hierdie bladsy om direk na onderafdelings op hierdie bladsy te spring.

.htaccess Basics

Laat ons vertroud raak met ‘n paar fundamentele faktore voordat ons opdragte uitvoer.

Wat is .htaccess?

Die .htaccess-lêer is ‘n konfigurasielêer wat beheer hoe ‘n webbediener op verskillende versoeke reageer. Dit word ondersteun deur verskeie webbedieners, waaronder die gewilde Apache-webbediener wat deur die meeste kommersiële aanbieders van webhosting gebruik word.

.htaccess-lêers werk op die vlak van ‘n gids, waardeur hulle die globale konfigurasie-instellings van .htaccess-riglyne hoër in die gidsboom kan ignoreer..

Hoe .htaccess gebruik word?

Sommige algemene gebruike vir .htaccess sluit die herlei van URL’s in, wat wagwoordbeskerming vir webwerwe (of webwerfbladsye) moontlik maak; vertoon van aangepaste foutbladsye (soos 404 bladsye); en die bevordering van SEO deur ‘n konstante agterlynbalk-beleid.

In laasgenoemde geval kan die webmeester kies om óf ‘n sleepstrokie aan die einde van elke URL op ‘n webwerf te vereis, al dan nie.

Waarom word dit genoem .htaccess?

.htaccess staan ​​vir “hiperteks-toegang.” Die naam is afgelei van die oorspronklike gebruik van die instrument, wat was om gebruikers se toegang tot sekere lêers per gids te beheer.

Met behulp van ‘n subversameling van Apache se http.conf-instellingsriglyne, .htaccess het ‘n stelseladministrateur die toegang tot individuele kaarte tot gebruikers beperk met ‘n naam en wagwoord wat in ‘n gepaardgaande .htpasswd-lêer gespesifiseer is..

Terwyl .htaccess-lêers steeds hiervoor gebruik word, word dit ook gebruik vir ‘n aantal ander dinge wat ons in hierdie handleiding sal dek..

Waar is die .htaccess-lêer?

In teorie kan elke lêergids (gids) op u bediener een hê. Oor die algemeen is daar egter een in u webwortmap – dit is die lêergids wat al die inhoud van u webwerf bevat, en wat gewoonlik so genoem word soos public_html of www.

As u ‘n enkele gids het wat veelvuldige subgidse vir die webwerf bevat, sal daar gewoonlik ‘n .htaccess-lêer in die hoofwortel (public_html) -gids wees en ook een in elke subgids (/ sitename).

Waarom kan ek nie my .htaccess-lêer vind nie?

Op die meeste lêerstelsels is lêernaam wat met ‘n punt (.) Begin, versteekte lêers. Dit beteken dat hulle nie standaard sigbaar is nie.

Maar dit is nie moeilik om by hulle uit te kom nie. U FTP-kliënt of lêerbestuurder moet ‘n instelling hê vir “wys verborge lêers.” Dit sal op verskillende plekke in verskillende programme voorkom, maar is gewoonlik in ‘Voorkeure’, ‘Instellings’ of ‘Gidsopsies.’ Soms vind u dit in die “View” -menu.

Wat as ek nie ‘n .htaccess-lêer het nie?

Maak eers seker dat u “wys verborge lêers” (of die ekwivalent daarvan) aangeskakel het, sodat u seker kan wees dat u nie een het nie. .Htaccess-lêers word dikwels outomaties geskep, dus u het gewoonlik een. Maar dit is nie altyd die geval nie.

As u regtig nie een het nie, kan u maklik een skep:

  • Begin ‘n nuwe lêer in ‘n gewone teksredigeerder.
  • Stoor dit in ASCII-formaat (nie UTF-8 of iets anders nie) as .htaccess.
    • Maak seker dat dit nie htaccess.txt of so iets is nie. Die lêer moet slegs die naam .htaccess bevat sonder enige addisionele lêeruitbreiding.
  • Laai dit na die toepaslike gids via FTP of u blaaier-gebaseerde lêerbestuurder.

Fout met hantering

Die gebruik van .htaccess-lêers om foutdokumente te spesifiseer is baie eenvoudig, een van die eenvoudigste dinge wat u met hierdie funksie kan doen.

Wat is ‘n foutkode?

Wanneer ‘n versoek aan ‘n webbediener gerig word, probeer dit om op daardie versoek te reageer, gewoonlik deur ‘n dokument af te lewer (in die geval van HTML-bladsye), of deur toegang tot ‘n toepassing te kry en die uitvoer terug te gee (in die geval van Content Management Systems en ander webprogramme).

As iets hiermee verkeerd gaan, word ‘n fout gegenereer. Verskillende soorte foute het verskillende foutkodes. U ken waarskynlik die 404-fout wat teruggestuur word as die dokument nie op die bediener gevind kan word nie.

Daar is baie ander foutkodes waarmee ‘n bediener kan reageer.

Kliëntversoekfoute

  • 400 – Slegte versoek
  • 401 – Magtiging vereis
  • 402 – Betaling benodig (nog nie gebruik nie)
  • 403 verbied
  • 404 nie gevind
  • 405 – Metode word nie toegelaat nie
  • 406 – Nie aanvaarbaar nie (kodering)
  • 407 – Proxy-verifikasie word vereis
  • 408 – Uitstel van die versoek
  • 409 – Botsende versoek
  • 410 – Verby
  • 411 – Inhoudlengte benodig
  • 412 – Voorvereiste misluk
  • 413 – Versoek entiteit te lank
  • 414 – Versoek URI te lank
  • 415 – Ondersteunde mediatipe.

Bedienerfoute

  • 500 Interne Bediener Fout
  • 501 – Nie geïmplementeer nie
  • 502 – Bad Gateway
  • 503 Diens Onbeskikbaar
  • 504 – Gateway-tydsduur
  • 505 – HTTP-weergawe word nie ondersteun nie.

Standaard fouthantering

As u geen tipe fouthantering spesifiseer nie, sal die bediener eenvoudig die boodskap na die blaaier terugstuur, en die blaaier sal ‘n generiese foutboodskap aan die gebruiker vertoon. Dit is gewoonlik nie ideaal nie.

Spesifiseer foutdokumente

Skep ‘n HTML-dokument vir elke foutkode wat u wil hanteer. U kan hierdie name noem wat u wil, maar dit is nuttig om hulle iets te noem wat u sal help om te onthou waarvoor hulle gaan, soos nie-gevind.html of eenvoudig 404.html.

Spesifiseer dan in die .htaccess-lêer watter dokument om met elke tipe fout te gebruik.

ErrorDocument 400 /errors/bad-request.html
ErrorDocument 401 /errors/auth-reqd.html
ErrorDocument 403 /errors/forbid.html
ErrorDocument 404 /errors/not-found.html
ErrorDocument 500 /errors/server-err.html

Let op dat elke richtlijn op sy eie lyn geplaas word.

En dit is dit. Baie eenvoudig.

alternatiewe na .htaccess vir fouthantering

Die meeste Content Management Systems (CMS) soos WordPress en Drupal, en die meeste webapps, sal hul eie manier hê om die meeste van hierdie foutkodes te hanteer..

Wagwoordbeskerming met .htaccess

Die oorspronklike doel van .htaccess-lêers was om toegang tot sekere kaarte op ‘n per gebruiker-basis te beperk (vandaar die naam, hiperteks-toegang). Ons sal dus eers daarna kyk.

.htpasswd

Gebruikersname en wagwoorde vir die .htaccess-stelsel word in ‘n lêernaam .htpasswd gestoor.

Dit word op ‘n enkele reël in die vorm gestoor:

gebruikersnaam: encryptedpassword

byvoorbeeld:

johnsmith: F418zSM0k6tGI

Dit is belangrik om te besef dat die wagwoord wat in die lêer gestoor is, nie die werklike wagwoord is wat gebruik word om aan te meld nie. Dit is eerder ‘n kriptografiese aspek van die wagwoord.

Dit beteken dat die wagwoord deur ‘n koderingsalgoritme uitgevoer is, en dat die resultaat geberg word. As ‘n gebruiker aanmeld, word die gewone tekswagwoord ingevoer en deur dieselfde algoritme uitgevoer. As die invoer dieselfde is, stem die wagwoorde ooreen en kry die gebruiker toegang.

Deur wagwoorde op hierdie manier te stoor, word dit veiliger – as iemand toegang tot u .htpasswd-lêer sou kry, sou hulle net die gevorderde wagwoorde sien, nie die oorspronklike dokumente nie. En daar is geen manier om die oorspronklikes uit die hash te rekonstrueer nie – dit is ‘n eenrigting-kodering.

Verskeie verskillende hash-algoritmes kan gebruik word:

  • Veilige algoritmes – gebruik een van hierdie
    • bcrypt – Dit is die veiligste, maar ook die traagste om te bereken. Dit word ondersteun deur Apache en Nginx.
    • md5 – Dit is die standaard hashing-algoritme wat deur huidige weergawes van Apache gebruik word. Dit word nie deur Nginx ondersteun nie.
  • Onsekere algoritmes – gebruik nie
    • crypt () – Dit was vroeër die standaard hashing-funksie, maar dit is nie baie veilig nie.
    • SHA en gesoute SHA.

Skep gebruikersname en wagwoorde op die opdragreël

U kan ‘n .htpasswd-lêer skep en u gebruikersnaam-wagwoordpare daar direk byvoeg vanaf die opdragreël of SSH-terminale.

Die opdrag vir die hantering van die .htpasswd-lêer is eenvoudig htpasswd.

Om ‘n nuwe .htpasswd-lêer te skep, gebruik u die opdrag met die -c-opsie (vir skep) en tik dan die pad na die gids (nie die URL nie, die werklike pad op die bediener). U kan ook ‘n gebruiker insluit wat u wil byvoeg.

> htpasswd -c /usr/local/etc/.htpasswd johnsmith

Dit skep ‘n nuwe .htpasswd-lêer in die / etc / gids en voeg ‘n rekord by vir ‘n gebruiker genaamd johnsmith. U sal gevra word om ‘n wagwoord wat ook gestoor sal word met behulp van die md5-kodering.

As daar reeds ‘n .htpasswd-lêer op die gespesifiseerde plek is, word ‘n nuwe een nie geskep nie – die nuwe gebruiker word eenvoudig bygevoeg tot die bestaande lêer.

As u die bcrypt-hashing-algoritme verkies, gebruik die -b-opsie.

Wagwoordshas sonder die opdragreël

As u nie gemaklik voel om die opdragreël of SSH-terminale te gebruik nie (of as u om die een of ander rede nie toegang daartoe het nie), kan u eenvoudig ‘n .htpasswd-lêer skep en dit met ‘n gewone teksredigeerder invul en dit oplaai. via FTP of lêerbestuurder.

Maar dan sal u op een of ander manier u wagwoorde moet kodeer, aangesien die htpasswd-opdrag dit vir u versorg het.

Daar is baie .htpasswd-enkripsiehulpprogramme aanlyn beskikbaar. Die beste een is waarskynlik die htpasswd-kragopwekker by Aspirine.org.

Dit gee u ‘n aantal opsies om algoritme en wagwoordsterkte te haas. U kan die afvoer van daar af eenvoudig in u .htpasswd-lêer kopieer en plak.

Waar om u .htpasswd-lêer te bewaar

U hoef nie ‘n aparte .htpasswd-lêer vir elke .htaccess-lêer te hê nie. Eintlik moet jy dit nie doen nie. In die meeste normale omstandighede moet u een hê vir u hele webhostingrekening of hoofbedienergids.

Die .htpasswd-lêer moet nie in ‘n openbaar toeganklike gids wees nie – nie public_html of www of in enige ander subgids nie. Dit moet bokant dié wees, in ‘n vouer wat slegs vanaf die bediener self toeganklik is.

Hoe om .htpasswd te gebruik met .htaccess

Elke gids kan sy eie .htaccess-lêer hê, met hul eie stel gebruikers wat toegang daartoe het.

As u wil hê dat iemand (insluitend nie-aangemelde gebruikers) toegang tot die gids en lêers het, doen eenvoudig niks – dit is die standaard.

Om toegang te beperk, moet u die volgende by die .htaccess-lêer voeg:

AuthUserFile /usr/local/etc/.htpasswd
AuthName "Naam van veilige gebied"
AuthType Basies

geldige gebruiker benodig

Die eerste reël spesifiseer die pad en lêernaam in u lys van gebruikersname en wagwoorde. Die tweede reël spesifiseer ‘n naam vir die beveiligde gebied. Dit kan alles wees wat jy wil hê. Die derde reël spesifiseer ‘Basiese’ verifikasie, wat u gewoonlik nodig het.

Die tag spesifiseer wat beperk word (in hierdie geval, die vermoë om na enige lêer in die gids GET of POST). Binne die paar etikette is ‘n lys van wie toegang tot lêers mag hê.

In die bostaande voorbeeld kan enige geldige gebruiker toegang tot lêers kry. As u toegang tot ‘n spesifieke gebruiker of ‘n paar gebruikers wil beperk, kan u dit noem.

AuthUserFile /usr/local/etc/.htpasswd
AuthName "Naam van veilige gebied"
AuthType Basies

benodig johnsmith
gebruiker janedoe benodig

U kan ook gebruikers in groepe plaas en toegang op groepe toestaan. Dit word gedoen deur ‘n ander lêer by te voeg wat die groepe spesifiseer.

Die groeplêer, wat (byvoorbeeld) .htgroups genoem kan word, lyk soos volg:

admin: johnsmith janedoe
personeel: jackdoe cindysmith

Dan kan u dit in u .htaccess-lêer spesifiseer:

AuthUserFile /usr/local/etc/.htpasswd
AuthGroupFile /usr/local/etc/.htgroup
AuthName "Admin Area"
AuthType Basies

groepadministrasie benodig

Alternatiewe vir .htpasswd

Deur .htaccess en .htpasswd te gebruik om toegang tot sekere lêers op u bediener te beperk, is dit net sinvol as u baie statiese lêers het. Die funksie is ontwikkel toe webwerwe gewoonlik ‘n versameling HTML-dokumente en verwante bronne was.

As u ‘n inhoudbestuurstelsel (CMS) soos WordPress of Drupal gebruik, kan u die ingeboude gebruikersbestuurfunksies gebruik om toegang tot inhoud te beperk of toe te staan..

Aktivering van bedienerkant sluit (SSI) in

Kom ons leer wat bedienerkant insluit en hoe u dit kan gebruik.

Wat bevat bedienerkant??

SSI, of Server Side Includes, is ‘n ligte skriptaal wat hoofsaaklik gebruik word om HTML-dokumente in ander HTML-dokumente in te sluit. Dit maak dit maklik om gewone elemente soos kop-, voet-, sidebalk en spyskaarte te hergebruik. U kan dit as ‘n voorloper van vandag se tematuur- en inhoudbestuurstelsels beskou.


SSI het ook voorwaardelike riglyne (as, anders, ens.) En veranderlikes, wat dit ‘n volledige, indien ietwat moeilik gebruikbare, skrifstaal maak. (Tipies, enige projek wat meer ingewikkeld is as ‘n handjievol ingesluit, sal veroorsaak dat ‘n ontwikkelaar ‘n meer robuuste taal soos PHP of Perl kies.)

Aktiveer SSI

By sommige webhosting-bedieners sal Server Side Includes standaard ingeskakel wees. Indien nie, kan u dit met u .htaccess-lêer inskakel, soos volg:

AddType-teks / html .shtml
AddHandler-bediener-ontleed .shtml
Opsies indekse FollowSymLinks sluit in

Dit behoort SSI moontlik te maak vir alle lêers met die .shtml-uitbreiding.

SSI op .html-lêers

As u SSI-ontleding op .html-lêers wil aktiveer, kan u ‘n richtlijn byvoeg om dit te bereik:

AddHandler-bediener-ontleed .html

Die voordeel hiervan is dat u SSI kan gebruik sonder om die wêreld te laat weet dat u dit gebruik. As u implementerings in die toekoms verander, kan u u .html-lêeruitbreidings behou.

Die nadeel hiervan is dat elke HTML-lêer met SSI ontleed word. As u baie .html-lêers het wat nie eintlik SSI-parsing nodig het nie, kan dit baie onnodige bedienerkoste bevat, wat u laaityd van die bladsy vertraag en die SVE-bronne opgebruik.

SSI op u indeksbladsy

As u nie alle .html-lêers wil ontleed nie, maar u wel wil gebruik van SSI op u indeksblad (tuisblad), moet u dit in u .htaccess-lêer spesifiseer.

Dit is omdat die webbediener op soek is na die indeksbladsy van ‘n gids, en dit soek na index.html, tensy u dit anders sê.

As u nie .html-lêers ontleed nie, sal u die indeksbladsy moet kry om die naam index.shtml te hê om te kan werk, en u bediener weet nie om daarvoor te soek nie.

Om dit te aktiveer, voeg eenvoudig die volgende by:

DirectoryIndex index.shtml index.html

Hiermee word die webbediener gewaarsku dat die index.shtml-lêer die belangrikste indekslêer vir die gids is. Die tweede parameter, index.html, is ‘n rugsteun, in die geval dat index.shtml nie gevind kan word nie.

IP-swartlys en IP-witlys

U kan .htaccess gebruik om gebruikers van ‘n spesifieke IP-adres (swartlys) te blokkeer. Dit is nuttig as u individuele gebruikers van spesifieke IP-adresse geïdentifiseer het wat probleme veroorsaak het.

U kan ook die omgekeerde doen en almal blokkeer, behalwe besoekers van ‘n spesifieke IP-adres (witlys). Dit is nuttig as u toegang tot slegs goedgekeurde gebruikers moet beperk.

Swartlys volgens IP

Gebruik die volgende richtlijn met die toepaslike IP-adresse om spesifieke IP-adresse te blokkeer:

bevel toelaat, ontken
ontken van 111.22.3.4
ontken van 789.56.4.
toelaat van almal

In die eerste reël word bepaal dat die toelatingsvoorskrifte eers geëvalueer word voordat die opdragte ontken word. Dit beteken dat toelaatbaarheid van almal die verstekstaat sal wees, en dan word slegs diegene wat ooreenstem met die voorskrifte vir ontkenning geweier.

As dit omgekeer word om te ontken, toe te laat, dan sal die laaste ding wat geëvalueer word, die toelating van alle richtings wees, wat almal sal toelaat, en die ontkennings verwerp..

Let op die derde reël wat van 789.56.4 ontken is. – dit is nie ‘n volledige IP-adres nie. Dit sal alle IP-adresse binne daardie blok weier (enige een wat met 789.56.4 begin).

U kan soveel IP-adresse insluit as wat u wil, een op elke reël, met ‘n weiering uit die richtlijn.

Witlys volgens IP

Die keersy van swartlys is witlys – beperk almal behalwe dié wat u spesifiseer.

Soos u kan raai, moet die bestelrigting omgeskakel word, sodat almal eers geweier word, maar dan word sekere adresse toegelaat.

orde ontken, toelaat
ontken van almal
toelaat vanaf 111.22.3.4
toelaat vanaf 789.56.4.

Blokkeringsaksies

.htaccess kan gebruik word om gebruikers per domein of verwyser te blokkeer. En u kan dit gebruik om bots en skrapers te blokkeer. Kom ons kyk hoe.

Hoe u gebruikers volgens domein kan blokkeer

U kan ook gebruikers blokkeer of toelaat op grond van ‘n domeinnaam. Dit kan help om mense te blokkeer, selfs al beweeg hulle van IP-adres na IP-adres.

Dit sal egter nie werk teen mense wat hul omgekeerde DNS-adres-kartering kan beheer nie.

bevel toelaat, ontken
ontken van voorbeeld.com
toelaat van almal

Dit werk ook vir subdomeine – in die vorige voorbeeld sal besoekers van xyz.example.com ook geblokkeer word.

Hoe om gebruikers deur verwyser te blokkeer

‘N Verwyser is die webwerf wat ‘n skakel na u webwerf bevat. As iemand ‘n skakel na ‘n bladsy op u webwerf volg, verwys die webwerf waarvandaan hulle verwys.

Dit werk egter nie net vir klikbare hiperskakels na u webwerf nie.

Bladsye op enige plek op die internet kan direk na u prente skakel (‘hotlinking’) – u bandbreedte gebruik, en moontlik u kopieregskending oortree, sonder om u voordeel in terme van verkeer te bied. Hulle kan ook ‘n hotlink na u CSS-lêers, JS-skripte of ander bronne hê.

Die meeste eienaars van die webwerf is goed daarmee as hulle net ‘n bietjie gebeur, maar soms kan hierdie soort ding misbruik word.

Boonop is werklike hiperskakels wat in die teks geklik kan word, problematies, soos wanneer dit van vyandige webwerwe afkomstig is.

Om een ​​van hierdie redes wil u dalk versoeke wat van spesifieke verwysers kom, blokkeer.

Om dit te kan doen, benodig u die mod_rewrite-module. Dit is standaard by die meeste webgashere ingeskakel, maar as dit nie (of nie seker is nie), kan u dit gewoonlik net by u gasheeronderneming vra. (As hulle dit nie kan of wil inskakel nie, wil jy dalk aan ‘n nuwe gasheer dink.)

Die .htaccess-riglyne wat verwysingsgebaseerde blokkering bewerkstellig, berus op die mod_rewrite-enjin.

Die kode om deur verwyser te blokkeer, lyk soos volg:

Herskryf enjin aan
RewriteCond% ^ http: //.*example.com [NC, OR]
Herskryf Cond% ^ http: //.*anotherexample.com [NC, OR]
Herskryf Cond% ^ http: //.*onemoreexample.com [NC]
RewriteRule. * – [F]

Dit is ‘n bietjie lastig, so laat dit deur.

Die eerste reël, RewriteEngine on, waarsku die ontleder dat ‘n reeks riglyne wat verband hou met herskryf, kom.

Die volgende drie reëls blokkeer elk ‘n verwysende domein. Die deel wat u vir u eie gebruik moet verander, is die domeinnaam (voorbeeld) en uitbreiding (.com).

Die agterkant-streep voor die .com is ‘n ontsnappingskarakter. Die patroonbypassing wat in die domeinnaam gebruik word, is ‘n reëlmatige uitdrukking, en die punt beteken iets in RegEx, dus moet dit “ontsnap” word met die agterkant-streep.

Die NC tussen hakies spesifiseer dat die wedstryd nie hoofletters moet wees nie. Die OR is ‘n letterlike ‘of’, en beteken dat daar ander reëls kom. (Dit is – as die URL hierdie een is, hierdie of hierdie een, volg hierdie herskryfreël.)

Die laaste reël is die werklike herskryfreël. Die [F] beteken “Verbode.” Versoeke met ‘n verwyser wat ooreenstem met dié in die lys, sal misluk en lewer ‘n 403 verbode fout.

Bots en webskrapers blokkeer

Een van die meer irriterende aspekte van die bestuur van ‘n webwerf is om te ontdek dat u bandwydte opgevreet word deur nie-menslike besoekers – bots, crawlers, web scrapers.

Dit is programme wat ontwerp is om inligting uit u webwerf te trek, gewoonlik met die doel om dit weer te publiseer as deel van ‘n lae-graad SEO-operasie.

Daar is natuurlik wettige bots – soos dié van groot soekenjins. Maar die res is soos plae wat net aan u hulpbronne verdwyn en hoegenaamd geen waarde aan u lewer nie.

Daar word etlike honderd bots geïdentifiseer. U sal nooit almal kan blokkeer nie, maar u kan die aktiwiteit tot ‘n dowwe gebrul hou deur soveel as moontlik te blokkeer..

Daar is ‘n nuttige stel herskryfreëls wat meer as 400 bekende bots wat deur AskApache saamgestel is, blokkeer.

Spesifiseer ‘n standaardlêer vir ‘n gids

As daar ‘n versoek aan ‘n webbediener gedoen word vir ‘n URL wat nie ‘n lêernaam spesifiseer nie, is die aanname in die meeste webbedieners ingebou dat die URL na ‘n gids verwys.

Dus, as u http://example.com versoek, sal Apache (en die meeste ander webbedieners) in die wortelgids na die domein (gewoonlik / public_html of iets dergeliks, maar miskien / voorbeeld-com) kyk vir die standaard lêer.

Die standaardlêer word standaard index.html genoem. Dit gaan terug na die begin van die internet toe ‘n webwerf slegs ‘n versameling dokumente was, en die “tuisblad” was gewoonlik ‘n indeks van daardie dokumente..

Maar u wil dalk nie hê dat index.html die standaard bladsy is nie. U kan byvoorbeeld ‘n ander lêertipe benodig, soos index.shtml, index.xml of index.php.

Of u dink miskien nie u tuisblad as ‘n “indeks” nie en wil dit iets anders noem, soos home.html of main.html.

Stel die standaard gids bladsy in

.Met htaccess kan u die standaard bladsy vir ‘n gids maklik instel:

DirectoryIndex [lêernaam hier]

As u wil hê dat u standaard tuis moet wees.html is dit so maklik soos:

DirectoryIndex home.html

Stel verskeie standaardbladsye in

U kan ook meer as een DirectoryIndex spesifiseer:

DirectoryIndex index.php index.shtml index.html

Die manier waarop dit werk, is dat die webbediener eers na die eerste een kyk. As dit dit nie kan vind nie, dan kyk dit na die tweede een, ensovoorts.

Waarom sou u dit wil doen? U weet sekerlik watter lêer u as standaardblad wil gebruik, reg?

Onthou dat .htaccess sy eie gids en elke subgids beïnvloed totdat dit deur ‘n meer plaaslike lêer omseil word. Dit beteken dat ‘n .htaccess-lêer in u stamgids instruksies vir baie subgidse kan verskaf, en elkeen kan sy eie standaard bladsynaam hê.

As u hierdie reëls in ‘n enkele .htaccess-lêer in die wortel kan plaas, beteken dit dat u nie alle ander riglyne in die lêer hoef te dupliseer op elke gidsvlak nie.

URL-verwysings en URL-herskryf

Een van die mees algemene gebruike van .htaccess-lêers is URL-aanwysings.

URL-aanwysings moet gebruik word wanneer die URL vir ‘n dokument of bron verander het. Dit is veral nuttig as u u webwerf herorganiseer of domeinnaam verander het.

301 teen 302 herlei

Vanuit ‘n blaaier se oogpunt is daar twee soorte aansture, 301 en 302. (Hierdie nommers verwys na die foutkode wat deur die webbediener gegenereer word.)

301 beteken “permanent verplaas”, terwyl 302 “tydelik verskuif” beteken. In die meeste gevalle wil u 301 gebruik. Dit behou alle SEO-aandele wat die oorspronklike URL gehad het, deur dit na die nuwe bladsy deur te gee.

Dit sal ook veroorsaak dat die meeste blaaiers hul boekmerke opdateer. Die meeste blaaiers sal ook die ou-tot-nuwe kartering kas, sodat hulle bloot die nuwe URL aanvra wanneer ‘n skakel of gebruiker probeer om toegang tot die oorspronklike te verkry. As die URL permanent verander het, is dit die gewenste resultate.

Daar is baie min rede om 302 aansture te gebruik, aangesien daar gewoonlik baie min rede is om ‘n URL tydelik te verander. Die verandering van ‘n URL ooit is ongewens, maar is soms nodig. Dit is ‘n slegte idee om dit tydelik te verander met die plan om dit later te verander, en dit kan byna altyd vermy word.

Al die voorbeelde in hierdie afdeling gebruik die 301 herleiding.

Herlei teen Herskryf

Daar is twee verskillende maniere om ‘n URL te verander met .htaccess-riglyne – die Redirect-opdrag en die mod_rewrite-enjin.

Die Redirect-opdrag stuur eintlik ‘n herleidingsboodskap na die blaaier om te sê watter URL u moet soek.

Gewoonlik “vertaal” die mod_rewrite-instrument een URL (die een wat in ‘n versoek voorsien word) na iets wat die lêerstelsel of CMS sal verstaan, en hanteer dan die versoek asof die vertaalde URL die versoekte URL is..

As hierdie manier gebruik word, kom die webblaaier nie agter dat iets gebeur het nie – dit ontvang net die inhoud waarvoor hy gevra het.

Die mod_rewrite-instrument kan ook gebruik word om 301 herleidings te produseer wat op dieselfde manier as die Redirect-opdrag werk, maar met meer opsies vir reëls – mod_rewrite kan ingewikkelde patroonaanpassings en herskrifinstruksies hê, wat Redirect nie kan benut nie.

Basiese herleiding

Om een ​​bladsy na ‘n ander URL te herlei, is die kode:

Herlei 301 /relative-url.html http://example.com/full-url.html

Hierdie enkele reëlopdrag bestaan ​​uit vier dele, elk geskei met ‘n enkele spasie:

  • Die herlei-opdrag
  • Die tipe herleiding (301 – Permanent verskuif)
  • Die relatiewe URL van die oorspronklike bladsy
  • Die volledige en volledige URL van die nuwe bladsy.

Die relatiewe URL is relatief tot die gids wat die .htaccess-lêer bevat, wat gewoonlik die webwortel is, of die wortel van die domein.

As http://example.com/blog.php dus na http://blog.example.com verskuif is, sou die kode die volgende wees:

Herlei 301 /blog.php http://blog.example.com

Herleiding van ‘n groot gedeelte van u webwerf

As u u gidsstruktuur rondgeskuif het, maar u bladsyname dieselfde gehou het, wil u moontlik alle versoeke vir ‘n sekere gids na die nuwe een herlei.

Herlei 301 / old-map http://example.com/new-directory

Herleiding van ‘n hele werf

Wat as u hele webwerf na ‘n nuwe URL verhuis? maklik.

Herlei 301 / http://newurl.com

Herlei www na nie-www

In toenemende mate beweeg webwerwe weg van die www-subdomein.

Dit was nog nooit regtig nodig nie, maar dit was ‘n voorsprong vanaf die dae toe die meeste mense wat ‘n webwerf bestuur het, ‘n bediener gebruik om baie van hul eie dokumente te stoor, en die www- of ‘world wide web’-gids is gebruik vir inhoud wat hulle wou hê deel met ander.

Sommige mense gebruik dit deesdae, en ander doen dit nie. Ongelukkig tik sommige gebruikers steeds outomaties www. voor elke URL buite gewoonte. As u nie www gebruik nie, wil u seker maak dat hierdie versoeke op die regte plek beland.

Om dit te kan doen, moet u die mod_rewrite-module gebruik, wat waarskynlik reeds op u webgasheer geïnstalleer is.

Opsies + VolgSimbole
Herskryf enjin aan
RewriteCond% ^ www.example.com [NC]
RewriteRule ^ (. *) $ Http://example.org/$1 [R = 301, NC]

Wees versigtig!

Baie ander .htaccess- en mod_rewrite-gidse bied ‘n variasie van die volgende kode om dit te bereik:

Opsies + VolgSimbole
Herskryf enjin aan
RewriteCond%! ^ Example.com [NC]
RewriteRule ^ (. *) $ Http://example.org/$1 [R = 301, NC]

Sien u die probleem daarmee?

Dit herlei alle subdomeine na die primêre domein. Dus nie net www.example.com nie, maar ook blog.example.com en admin.example.com en nog iets anders. Dit is waarskynlik nie die gedrag wat u wil hê nie.

Verwys na www

Maar wat as u die www-subdomein gebruik??

U moet waarskynlik ‘n herleiding opstel om seker te maak dat mense kom waarheen hulle probeer. Veral noudat minder mense waarskynlik outomaties die www bygevoeg het aan die begin van URL’s.

U moet net die bostaande kode omkeer.

Herskryf enjin aan
RewriteCond% ^ example.com [NC]
RewriteRule ^ (. *) Http://www.website.com/$1 [R = 301, NC]

Moet ek 404-foute na die tuisblad herlei??

Verskeie gidse oor .htaccess-aanwysings bevat instruksies om 404-foute na die tuisblad te herlei.

Dit is ‘n goeie voorbeeld van die feit dat jy nie iets moet doen as jy iets kan doen nie.

Dit is ‘n aaklige idee om 404-foute na die tuisblad van die webwerf te herlei. Dit verwar besoekers wat nie kan agterkom waarom hulle die voorblad van ‘n webwerf sien nie in plaas van ‘n behoorlike 404-foutbladsy.

Alle webwerwe moet ‘n 404-bladsy hê wat aan die gebruiker duidelik is dat die inhoud nie gevind kan word nie en ideaal gesproke ‘n aantal soekfunksies bied om die gebruiker te help om te soek waarna hy gesoek het..

Waarom .htaccess gebruik in plaas van alternatiewe?

U kan herleiding in PHP-lêers instel, of met enige ander tipe skrip aan die serverkant. U kan dit ook opstel in u inhoudbestuurstelsel (wat basies dieselfde ding is).

Maar .htaccess is gewoonlik die vinnigste tipe herleiding. Met PHP-gebaseerde aansture, of ander skrip-tale op die bedienerkant, moet die volledige versoek voltooi word, en die skrip eintlik geïnterpreteer word voordat ‘n herleidingsboodskap na die blaaier gestuur word.

Met .htaccess-aansture reageer die bediener direk op die versoek met die herlei-boodskap. Dit is baie vinniger.

U moet egter daarop let: sommige inhoudbestuurstelsels bestuur eintlik aansture deur die .htaccess programmatig op te dateer. WordPress het byvoorbeeld omleidingsproppe wat op hierdie manier werk. (En die mooi URL-stelsel van WP doen dit ook.)

Dit gee u die prestasie van die gebruik van .htaccess direk, terwyl u ook die gerief van bestuur binne u aansoek gee.

Verberg u .htaccess-lêer: veiligheidsoorwegings

Daar is geen rede dat iemand u .htaccess-lêer van die web af kan sien nie.

Daar is ook enkele groot redes waarom u beslis nie wil hê dat mense u .htaccess-lêer moet sien nie.

Die grootste probleem is dat as u ‘n .htpasswd-lêer gebruik, word die ligging in die .htaccess-lêer uitgespel. As u weet waar u dit vind, is dit makliker om te vind.

Boonop wil u as ‘n algemene reël nie die publiek inligting gee oor u implementering nie.

Herskryf reëls, gidsinstellings, sekuriteit – al die dinge waarvoor u .htaccess gebruik – dit is ‘n goeie sekuriteitspraktyk om al hierdie agter die skerms op u webbediener te verberg. Hoe meer ‘n hacker oor u stelsel kan leer, hoe makliker is dit om dit in die gedrang te bring.

Dit is baie maklik om u .htaccess-lêer vir die publiek te verberg. Voeg net die volgende kode by:

bevel toelaat, ontken
ontken van almal

Aktiveer MIME-tipes

MIME-tipes is lêertipes. Hulle word MIME-soorte genoem vanweë hul oorspronklike assosiasie met e-pos (MIME staan ​​vir “Multipurpose Internet Mail Extensions”). Dit word nie net “lêertipes” genoem nie, want MIME impliseer ‘n spesifieke formaat om die lêertipe te spesifiseer.

As u ooit ‘n HTML-dokument geskryf het, het u waarskynlik ‘n MIME-tipe gespesifiseer, selfs as u dit nie weet nie:

Die tipe attribuut verwys na ‘n spesifieke MIME-tipe.

MIME tik op u bediener

Soms vind u dat u webbediener nie opgestel is om ‘n spesifieke soort lêer te lewer nie. Dit werk net nie – versoeke vir die lêer misluk eenvoudig.

In die meeste gevalle kan u hierdie probleem oplos deur die MIME-tipe by te voeg tot u .htaccess-lêer.

AddType teks / richtext rtx

Hierdie richtlijn bestaan ​​uit drie dele, elk geskei deur ‘n ruimte:

  • Die kommando AddType
  • Die MIME-tipe
  • Die lêeruitbreiding.

As u verskillende lêeruitbreidings met dieselfde MIME-tipe wil assosieer, kan u dit op ‘n enkele reël doen.

AddType image / jpeg jpeg jpg jpe JPG

Forseer aflaai deur MIME-tipe

As u wil hê dat alle skakels na spesifieke lêertipes as aflaaie moet begin, in plaas daarvan om in die blaaier oop te maak, doen u dit met die MIME-tipe toepassing / oktetstroom, soos volg:

AddType-toepassing / octet-stream pdf

U kan weer verskeie lêeruitbreidings met ‘n enkele tipe spesifiseer:

AddType-toepassing / octet-stream pdf doc docx rtf

Lys met lêeruitbreidings en MIME-soorte

Hier is ‘n nie-volledige lys van lêerformate en gepaardgaande MIME-tipes.

As u u eie webwerf bestuur, en u weet in watter lêertipes u bronne publiseer, is dit nie nodig om die hele lys in u .htaccess-lêer te plak nie..

As u egter ‘n webwerf bestuur waarop baie ander mense bydraes lewer en die inhoud daarvan publiseer, wil u dalk ‘n groot aantal lêertipes op hierdie manier toelaat om seker te maak dat niemand ‘n slegte ervaring het nie.

Dit is veral die geval as u ‘n webwerf bestuur waar mense spesifiek baie lêers wil deel, byvoorbeeld ‘n werf vir deling van lêers, ‘n projekbestuurstoepassing (waar baie lêers dikwels aan die projek gekoppel sal word), of ‘n webprogram wat hanteer e-pos.

AddType-toepassing / macbinhex-40 hqx
AddType-toepassing / netalive net
AddType-toepassing / netalivelink nel
AddType-toepassing / octet-stream bin exe
AddType-toepassing / oda oda
AddType-toepassing / pdf pdf
AddType-toepassing / postscript ai eps ps
AddType-toepassing / rtf rtf
AddType-toepassing / x-bcpio bcpio
AddType-toepassing / x-cpio cpio
AddType-toepassing / x-csh csh
AddType-toepassing / x-direkteur dcr
AddType-toepassing / x-direkteur dir
AddType-toepassing / x-direkteur dxr
AddType-toepassing / x-dvi dvi
AddType-toepassing / x-gtar gtar
AddType-toepassing / x-hdf hdf
AddType-toepassing / x-httpd-cgi cgi
AddType-toepassing / x-latex-latex
AddType-toepassing / x-mif mif
AddType-toepassing / x-netcdf nc cdf
AddType-toepassing / x-onlive sds
AddType-toepassing / x-sh sh
AddType-toepassing / x-shar shar
AddType-toepassing / x-sv4cpio sv4cpio
AddType-toepassing / x-sv4crc sv4crc
AddType-toepassing / x-teer-teer
AddType-toepassing / x-tcl tcl
AddType-toepassing / x-tex tex
AddType-toepassing / x-texinfo texinfo texi
AddType-toepassing / x-troff t tr roff
AddType-toepassing / x-troff-man-man
AddType-toepassing / x-troff-me me
AddType-toepassing / x-troff-ms ms
AddType-toepassing / x-ustar ustar
AddType-toepassing / x-wais-bron src
AddType-toepassing / zip-rits
AddType klank / basiese au snd
AddType klank / x-aiff aif aiff aifc
AddType klank / x-midi middel
AddType klank / x-pn-realaudio-ram
AddType klank / x-wav wav
AddType-beeld / gif gif GIF
AddType-beeld / ief ief
AddType image / jpeg jpeg jpg jpe JPG
AddType-beeld / tiff tiff tif
AddType-beeld / x-cmu-raster ras
AddType image / x-portable-anymap pnm
AddType-beeld / x-draagbare bitmap-pbm
AddType-beeld / x-draagbare-graymap pgm
AddType-beeld / x-draagbare pixmap ppm
AddType-beeld / x-rgb rgb
AddType-beeld / x-xbitmap xbm
AddType-beeld / x-xpixmap xpm
AddType-beeld / x-xwindowdump xwd
AddType-teks / html html htm
AddType-teks / gewone txt
AddType teks / richtext rtx
AddType teks / tab-geskei-waardes tsv
AddType-teks / x-bediener-ontleed-html shtml sht
AddType-teks / x-setext etx
AddType video / mpeg mpeg mpg mpe
AddType video / quicktime qt mov
AddType video / x-msvideo avi
AddType video / x-sgi-filmprent
AddType x-world / x-vrml wrl

Blokkeer hotlinking

Hotlinking is die praktyk om te skakel na hulpbronne van ander domeine in plaas daarvan om die inhoud na u eie bediener op te laai en dit self te bedien.

Gestel jy vind ‘n beeld op ‘n webwerf waarvan jy regtig hou, en dat jy dit op jou webwerf wil gebruik. As u kopieregprobleme vir die oomblik ignoreer, kan u die prent aflaai, dit op u webwerf oplaai en dit soos normaal op u bladsy insluit..


Maar as u lui was, of bandbreedte probeer bespaar, of nie weet hoe om ‘n lêer op te laai nie, kan u dit direk in die oorspronklike lêer insluit.

Dit is ‘n hotlink. Dit gebeur ook met CSS- en JS-lêers, maar beelde is die algemeenste.

Sommige webwerwe / leërskare gee nie om as u dit doen nie – u kan prente van Wikipedia af koppel sonder dat iemand hulle ontstel. En sommige webwerwe moedig dit in die een of ander vorm aan.

Byvoorbeeld, JQuery bied hul JS-biblioteke via ‘n CDN (Content Delivery Network) aan, sodat u direk daarheen kan skakel sonder om dit op te laai en dit vanaf u eie bediener te bedien..

Baie webgasheer beskou hotlinking as ‘n vorm van bandwydte en diefstal van bronne.

Om seker te wees, as u ‘n relatiewe klein webwerf bestuur, kan u nie bekostig om daagliks duisende of tienduisende versoeke te rig vir hulpbronne wat niks met werklike besoekers aan u webwerf te doen het nie..

As u ‘n probleem het met hotlinking, kan u dit deaktiveer met ‘n paar mod_rewrite-reëls wat by u .htaccess-lêer gevoeg is..

Herskryf enjin aan
Herskryf Cond%! ^ $
Herskryf Cond%! ^ Http: // (www.)? Example.com /.*$ [NC]
RewriteRule. (Gif | jpg | jpeg | png | js | css) $ – [F]

Verander die voorbeeld.com in die derde reël na u werklike domeinnaam. Dit sal enige versoeke wat nie van u domein af kom nie, kry en kyk of dit ooreenstem met een van die gespesifiseerde lêeruitbreidings in die vierde reël. As daar ‘n wedstryd is, misluk die versoek.

As u ander lêeruitbreidings wil byvoeg, kan u die laaste reël eenvoudig wysig.

Bediening van alternatiewe inhoud

As u die wêreld wil laat weet waarom hul hotlinking skielik opgehou het om te werk, kan u hotlink-beelde vervang met ‘n spesiale afbeelding met ‘n boodskap soos: “Ons haat hotlinking!” of “oorspronklike inhoud beskikbaar op http://example.com”.

In plaas daarvan om die versoek te laat slaag, verwys u dit bloot na die ‘spesiale’ beeld:

Herskryf enjin aan
Herskryf Cond%! ^ $
Herskryf Cond%! ^ Http: // (www.)? Example.com /.*$ [NC]
RewriteRule. (Gif | jpg) $ http://www.example.com/no-hotlinking.jpg [R, L]

As u regtig met mense wil mors, kan u JavaScript- of CSS-lêers herlei na spesiale alternatiewe wat ongelukkige gevolge vir die hotlinker kan hê. Dit word egter nie aanbeveel nie.

Herskryf enjin aan
Herskryf Cond%! ^ $
Herskryf Cond%! ^ Http: // (www.)? Example.com /.*$ [NC]
RewriteRule. (Js) $ http://www.example.com/break-everything.js [R, L]

Herskryf enjin aan
Herskryf Cond%! ^ $
Herskryf Cond%! ^ Http: // (www.)? Example.com /.*$ [NC]
RewriteRule. (Css) $ http://www.example.com/super-ugly.css [R, L]

Deaktiveer of aktiveer indeks

Wat gebeur as u ‘n gids vol dokumente of ander bronne het, geen index.html-lêer en geen standaard-gidsbladsy gespesifiseer in die .htaccess-lêer?

In baie gevalle is die resultaat ‘n generiese gidslys van al die lêers in die gids.

Dit is reg. As u ‘n gids in u gasheergids het met die etiket / prente, en dit het geen index.html-bladsy nie, kan iemand ‘n lys van al die prente op u bladsy sien as u na http://yousite.com/images navigeer. werf.

Dit is die standaardgedrag van die meeste webbedieners, en dit is sinvol uit die oogpunt van die oorspronklike opvatting van ‘n webwerf as bloot ‘n plek om dokumente te bewaar en te deel. Maar dit is nie die gewenste gedrag vir die meeste webwerwe nie.

Deaktiveer indekse

Baie webhosting-rekeninge sal dit al deaktiveer as deel van hul wêreldwye opset. Maar nie almal doen dit nie.

As u outomaties gegenereerde gidslyste moet deaktiveer, is dit maklik:

Opsies-Indeks

Aktiveer indekse

As u webbediener indekse as deel van die globale konfigurasie gedeaktiveer het, maar u wel wil hê, kan u dit aktiveer met die omgekeerde van die bogenoemde opdrag.

Opsies + indekse

Versteek sommige lêers in die indeks

As u gidslyste wil vertoon, maar sekere lêertipes in die lys wil wegsteek, kan u dit ook doen.

IndeksIgnoreer * .gif * .jpg

Die * is ‘n wildkaartskaar. Die bogenoemde richtlijn verberg alle lêers met ‘n .gif- of .jpg-uitbreiding. As u meer spesifiek wil wees, kan u:

IndexIgnoreer secret-image.jpg

Aktiveer CGI oral

CGI, of Common Gateway Interface, is ‘n metode wat aan die kant van die server dien om nie-HTML-skripte (soos Perl of SSI) op webblaaie in te sluit..

Tipies word CGI-skripte gestoor in ‘n lêergids / cgi-bin. Die webbediener is opgestel om ‘n bron in ‘n gids as ‘n skrip eerder as ‘n bladsy te behandel.

Die probleem hiermee is tweeledig: URL’s wat CGI-hulpbronne verwys, moet / cgi-bin / daarin hê, wat implementeringsbesonderhede in u URL plaas – ‘n teenpatroon wat om verskillende redes vermy moet word.

‘N Komplekse webwerf het miskien ‘n beter organisasiestruktuur nodig as om net ‘n ton skrifte in ‘n enkele / cgi-bin-lêergids vas te lê.

As u wil hê dat u webbediener CGI-skripte ontleed, ongeag waar dit in u gidsstruktuur voorkom, voeg u die volgende by u .htaccess-lêer:

AddHandler cgi-script .cgi
Opsies + ExecCGI

As u ander lêeruitbreidings het wat u as CGI-skripte wil verwerk, kan u dit in die eerste reël byvoeg.

Skripte as bronkode

U plaas meestal skripte in u webgids, want u wil hê dat hulle as skripte uitgevoer moet word.

Maar soms is dit nie wat u wil hê nie. Soms wil u die bronkode aan openbare besoekers vertoon, in plaas daarvan om die skrip uit te voer.

Dit kan die geval wees as u ‘n lêerdelingdiens of ‘n kode-bewaarplek bedryf, en u wil hê dat mense die bronkode moet sien en dit kan aflaai, maar die skrifte is eintlik deel van u funksies van u webwerf.

Dit kan in u .htaccess-lêer gedoen word deur die skriphanteraar vir sekere lêertipes te verwyder en dit met ‘n hanteerder vir teks te vervang..

VerwyderHandler cgi-script .pl .cgi .php .py
AddType-teks / gewone .pl .cgi .php .py

Alternatiewelik, soos u voorheen genoem het, kan u lêers met hierdie extensinos dwing om outomaties afgelaai te word, eerder as om dit te vertoon.

VerwyderHandler cgi-script .pl .cgi .php .py
AddType-toepassing / octet-stream .pl .cgi .php .py

Wees egter versigtig met een van hierdie dinge. As u net wil hê dat sommige lêers op hierdie manier vertoon moet word, maar steeds die skrifte vir die res van u webwerf gebruik, sal u slegte tyd hê as u die richtlijn in die .htaccess-lêer van u webwortel plaas..

‘N Beter praktyk sou wees om al sulke “slegs-vertoon” -skripte in ‘n enkele gids te plaas, en dan die richtlijn in ‘n .htaccess-lêer daar in daardie lêergids te plaas..

Stel PHP-instellings op

Soms moet u die instellings van PHP aanpas. Die regte manier om dit te doen is in ‘n lêer genaamd php.ini.

Ongelukkig laat nie alle webhostingondernemings hul kliënte toe om die php.ini-lêer te wysig nie. Dit geld veral vir gedeelde aanbieders van gasheer, waar ‘n enkele PHP-installasie moontlik honderde webwerwe bevat.

Gelukkig is daar ‘n oplossing – u kan php.ini-reëls in u .htaccess-lêer insluit.

Die sintaksis lyk soos volg:

php_value [instellingsnaam] [waarde]

Dus, as u die maksimum oplaaigrootte (‘n algemene probleem) moet vergroot, is dit so maklik soos:

php_value upload_max_filesize 10M

Nie alle PHP-instellings kan in .htaccess-lêers gespesifiseer word nie. U kan byvoorbeeld nie klassifikasies op hierdie manier deaktiveer nie.

Raadpleeg die amptelike php.ini-riglyne vir ‘n volledige lys van alle instellings vir php.ini.

Hoe om toegang tot u PHP te voorkom, sluit lêers in

Daar is verskillende maniere om ongemagtigde toegang tot u PHP-lêers te voorkom.

Eerstens kan u dit in ‘n gids plaas en u .htaccess-lêer instel om alle toegang tot die gids te weier (dit wil sê, Weier van almal as u die Apache HTTP-bediener gebruik). As iemand probeer om toegang tot die lêer te verkry, sal hulle ‘n HTTP 403 verbied reaksie.

Alternatiewelik kan u hierdie lêers buite die gids stoor waaruit u webwerf-lêers bedien word. Dit wil sê, as u webbediener lêers in / SRV / huis, u kan u insluitingslêers onder plaas / SRV / huis / sluit. Dit maak die lêers ontoeganklik via URL’s, alhoewel u toegang daartoe kan verkry en gebruik soos volg: sluit ‘PATH_TO_YOUR_FILE’ in

Laastens kan u ‘n URL-konstant definieer vir die lêers wat u toeganklik wil hê:

definieer (‘WEBSITE_URL’, ‘http://example.com’);

Sluit dan die volgende tjek in vir die lêers waarna u nie toegang wil hê nie:

if (! gedefinieerd (‘WEBSITE_URL’)) {
header ($ _ bediener ["SERVER_PROTOCOL"] . "403 verbied");
verlaat;
}

Hoe u toegang tot u PHP-ini-lêers kan voorkom

Die manier om ongemagtigde toegang tot u ini-lêers te voorkom, is om u .htaccess-lêer te wysig om toegang tot die ini-lêers te weier (dit wil sê, Weier alles as u Apache gebruik).

Hoe om die tydsone van u bediener in te stel

U kan die tydsone van u bediener instel deur dit in u .htaccess-lêer te spesifiseer. Om dit te kan doen, moet u die volgende reël byvoeg:

php_value date.timezone ‘Streek / sone’

Maak seker dat u Streek / Sone vervang met die tydsone wat u verkies.

Stoor u lêer. U kan u veranderinge toets deur ‘n PHP-toetslêer te skep wat die volgende bevat in dieselfde gids as die .htaccess-lêer:

<?php phpinfo (); ?>

Laai die lêer in u blaaier en soek die naam van die richtlijn – die kolom Plaaslike waarde moet u nuwe tydsone-instelling vertoon.

Wanneer u nie .htaccess moet gebruik nie

As u u .htaccess-lêer vir die eerste keer redigeer, kan u ‘n skielike gevoel kry van geweldige mag oor u webhosting-omgewing. U voel skielik soos ‘n sysadmin.

Ongelukkig kan hierdie krag op u kop gaan, en u kan uself bevind op die .htaccess-lêer op maniere wat nie die beste is nie.

As u iets moet doen wat lyk soos ‘n soort soort werk, is daar basies twee situasies waar u die opdrag êrens anders moet plaas.

Verder stroomop

Waar moontlik, is dit beter dat die soorte aanwysings wat u in ‘n .htaccess-lêer kan plaas, in die httpd.conf-lêer geplaas word, wat ‘n konfigurasie-instellingslêer vir die hele bediener is..

Net so hoort PHP-instellings meer behoorlik in die php.ini-lêer, en die meeste ander tale het soortgelyke konfigurasie-instellingslêers.

As u riglyne verder stroomop plaas, in die httpd.conf, php.ini of ander taalspesifieke konfigurasielêer, kan hierdie instellings ‘ingebak’ word op die ontleding van die webbediener. Met .htaccess moet die riglyne gekontroleer en geïnterpreteer word met elke enkele versoek.

As u ‘n webwerf met ‘n lae verkeer het met slegs ‘n handvol .htaccess-riglyne, is dit nie ‘n groot saak nie. Maar as u baie verkeer het, en baie riglyne, kan die prestasievertraging regtig optel.

Ongelukkig laat baie gedeelde hostingverskaffers nie toe dat kliënte toegang tot die httpd.conf- of php.ini-lêers verkry nie, wat gebruikers dwing om op die stadiger .htaccess-lêer te vertrou..

Dit bied ‘n dubbele boete in vergelyking met pasgemaakte VPS-konfigurasies, omdat gedeelde hosting gewoonlik oor die algemeen baie min is. Dit is een van die redes waarom ‘n webwerf met gerespekteerde verkeer waarskynlik op ‘n VPS-plan moet wees in plaas van ‘n gedeelde gasheerplan.

Verder stroomaf

As u ‘n goeie Content Management System (CMS), soos WordPress of Drupal, gebruik, kan sommige van die dinge wat u in ‘n .htaccess-lêer kan doen – soos omlê-URL’s of IP-adresse blokkeer – gedoen word binne die toepassing..

Dikwels werk dit in samewerking met die .htaccess-lêer, met die toepassing wat riglyne programmaties byvoeg.

As dit beskikbaar is, is dit gewoonlik die beste om hierdie take van binne die toepassing af te handel, eerder as om die .htaccess-lêer self te redigeer. U sal minder foute en onversoenbare voorskrifte gebruik as u ‘n goed-getoetste open source-inprop gebruik.

Probleemoplossing

Dit kan wonderlik wees om met u .htaccess-lêer rond te skakel – maar dit kan ook daartoe lei dat u bediener aangryp en 500 interne bedienerfoutboodskappe begin aflewer..

Hier is ‘n paar idees om jou daarmee te help.

Doen een ding op ‘n slag

Dit moet vanselfsprekend wees, maar ongelukkig is dit ‘n les wat baie van ons oor en oor moet leer.

Doen een ding. Toets dit dan. Doen dan ‘n ander ding. Toets dit.

As u verskillende dinge op een slag doen en dan iets misluk, sal u nie weet watter richtlijn die probleem veroorsaak nie.

Rugsteun u lêer voor elke aksie

As u slegs een ding op ‘n slag doen, moet u u lêer stoor tussen elke ding wat u probeer. U gestoorde argief moet herstel kan word. Dit is nie Microsoft Word waar u kan ongedaan maak nie; u het ‘n gestoorde kopie van u lêer nodig.

U moet altyd die nuutste werkweergawe beskikbaar hê as u iets mors. Altyd, altyd, altyd die vermoë om na ‘n werkende weergawe te herstel.

Dit is die maklikste as u ‘n soort bronbestuurstelsel soos git het. U kan na elke verandering pleeg en terugrol as u probleme ondervind.

Kontroleer die foutlêers

As u wel ‘n probleem ondervind en dit moeilik vind om dit uit te vind, kyk dan na u Apache-foute. Dit bied dikwels waardevolle inligting oor waar om te soek.

Gebruik ontwikkelaarsforums om hulp te kry

Ontwikkelaarforums en Q&’N Webwerf soos StackOverflow is van onskatbare waarde vir selfs die mees ervare ontwikkelaars en sysadmins. En moenie Google vergeet nie. Dikwels is die verskil tussen ‘n slegte webmeester en ‘n groot mens nie om die antwoord te ken nie, om te weet waar om die antwoord te vind.

Algemene. Probleme met toegang

Soms het jy ‘n tikfout gemaak. Soms het u ‘n esoteriese en verwarrende probleem wat veroorsaak word deur die samevloeiing van onvoorspelbare faktore.

Die meeste probleme, en die frustrerendste probleme, is die probleme in die middel – die eenvoudige, alledaagse probleme wat maklik is om op te los as u net van hulle weet.

Hier is ‘n paar daarvan.

Slegte lêernaam

Daar is net een manier om .htaccess te spel – dit moet met die punt begin, en dit moet in kleinletters wees.

Dit lyk dom, maar as u .htaccess-lêer nie doen wat u verwag nie, moet dit die eerste ding wees wat u nagaan.

.htaccess Gestremd of Gedeeltelik gestremd

Sommige gedeelde gasheerverskaffers skakel .htaccess heeltemal uit. Ander laat dit toe, maar beperk sekere voorskrifte om nie gebruik te word nie – dit word net geïgnoreer as dit ingesluit is.

Net so, selfs op VPS-planne of op u eie toegewyde bedieners, kan .htaccess dalk gedeaktiveer word.

As u toegang tot die httpd.conf-lêer of ander bedienerinstellings het, kan u dit self kontroleer. As u die opdrag AllowOverride None vind, vind u die skuldige. Vervang dit met AllowOverride All.

As u nie toegang tot u httpd.conf-lêer het nie (omdat u byvoorbeeld gedeelde hosting aanbied), moet u moontlik die tegniese ondersteuning van u gasheerfirma kontak en kyk of hulle dit vir u kan inskakel, of u voorstelle kan aanbied om te doen wat u op ‘n ander manier probeer doen.

Botsende of verbode voorskrifte

As u meer kaarte vir geneste het, is dit moontlik vir elkeen om sy eie .htaccess-lêer te hê. Elke .htaccess-lêer vanaf die wortel, deur elke geneste gids, is van toepassing – dit word in volgorde gelees en daal af in die gidsboek.

As u iets in u rootdirectory opstel, en iets in die subgids dan onderstreep, sal die richtlijn in die .htaccess-lêer naaste aan die versoekte lêer voorrang geniet.

Kyk ook na ons mod-herskryf-cheat sheet!

.htaccess Algemene vrae

  • Wat is die .htaccess-lêer in SEO?

    Die .htaccess-lêer kan gebruik word om SEO-verwante take soos aansture uit te voer. Aansture kan gebruik word om 404-foutboodskappe te vermy en om soekenjinsoekers te laat weet watter bladsye hulle moet indekseer. U kan ook HTTP-opskrifte instel om die laaisnelheid van bladsye te verbeter, wat u soekenjinranglys kan verhoog.

    Boonop kan u .htaccess gebruik om ‘n konstante agterlynbalk te implementeer. Dit, gekombineer met www- en HTTPS-reëls, kan u help om duplikaatinhoud te vermy, wat deur Google gepenaliseer kan word.

  • Hoe kan ek ‘n .htaccess-lêer in WordPress skep??

    Gebruik ‘n kode om ‘n .htaccess-lêer in WordPress te skep:

    # BEGIN WordPress

    Herskryf enjin aan
    RewriteBase /
    RewriteRule ^ index \ .php $ – [L]
    Herskryf Cond% {REQUEST_FILENAME}! -F
    Herskryf Cond% {REQUEST_FILENAME}! -D
    Herskryf reël. /index.php [L]

    # EINDE WordPress

    Let daarop dat wanneer u WordPress installeer, die .htaccess-lêer outomaties geskep word. ‘N Foutiewe inprop kan egter ‘n .htaccess-lêer beskadig, wat tot gevolg moet hê dat die lêer weer geskep moet word.

  • Waarom kan ek my .htaccess-lêer nie sien nie??

    As u u .htaccess-lêer nie kan sien nie, is dit omdat dit nie bestaan ​​nie of dat dit verborge is. Om u FTP-kliënt te dwing om hierdie lêers te wys, moet u u kliëntinstellings verander (d.w.s. in FileZilla, gaan na bediener > Dwing om verborge lêers te wys). As u hierdie verandering aangebring het en u steeds nie .htaccess sien nie, moet u dit weer skep.

  • Hoeveel .htaccess lêers moet ek hê?

    Die meeste webwerwe het nie meer as een .htaccess-lêer nodig nie. Dit is omdat die .htaccess-lêers u in staat stel om veranderings aan die bedieneropstelling op ‘n per-gids-basis aan te bring. By die aanbieding van meerdere werwe of komplekse toepassings kan sommige webmeesters meer as een lêer per webwerf gebruik om gevorderde funksies uit te voer..

  • Waar is .htaccess in die cPanel?

    Meld u aan by u cPanel-rekening om die .htaccess-lêer te sien. Gaan dan na lêers > Lêer bestuurder. As u gevra word om die gids te kies, kies Webwortel en maak seker dat Wys verborge lêers is nagegaan. U moet nou u .htaccess-lêer in cPanel kan besigtig.

  • Wat is die gebruik van die .htaccess-lêer in CodeIgniter??

    Die .htaccess-lêer kan in samewerking met CodeIgniter gebruik word om URL’e vir soekenjins te skep. CodeIgniter URL’s bevat standaard die index.php-lêer. Deur gebruik te maak van .htaccess, kan u die standaard index.php-lêer uitvee, sodat dit nie in al u URL’s van u aansoek verskyn nie..

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map