En nybegynners guide til .htaccess for designere og utviklere
Blant de mange forskjellige verktøyene for å tilpasse webserveren, er .htaccess config-filen et enormt aktivum. Du kan raskt tilbakestille dokumenttyper, parsing motorer, omadressering av nettadresser, og mange andre viktige funksjoner. Webmastere som ikke er veldig tekniske, kan ikke komme inn i detaljene for å administrere din egen .htaccess-fil. Men selve emnet er fascinerende og verdt en undersøkelse.
For denne artikkelen vil jeg presentere noen av de mer målrettede konseptene for webansvarlige og webutviklere. Noen som er lanserer sitt eget nettsted på en Apache server vil definitivt ønske å forstå hvordan man skal administrere .htaccess-filen. Den gir så mye tilpassbarhet og det kan fungere på tvers av alle web språk fra PHP til Ruby.
På bunnen av dette innlegget har jeg lagt til noen eksterne webapps til hjelpe nykommere å generere sine .htaccess-filer dynamisk.
Hvorfor bruke en .htaccess-fil?
Dette er et flott spørsmål, og kanskje bør vi begynne å svare “Hva er en .htaccess-fil”? Det er en veldig spesiell konfigurasjonsfil som brukes av Apache webserveren. En .htaccess-fil kan fortelle webserveren hvordan presenterer du ulike former for informasjon og hvordan du håndterer ulike HTTP-forespørsler.
Egentlig er det et middel til desentralisering å organisere webserverinnstillinger. En fysisk server kan ha 50 forskjellige nettsteder hver med sin egen .htaccess-fil. Det gir mye makt til webmastere, noe som ellers ville være umulig. Men hvorfor skal du bruke en?
Den største grunnen er sikkerhet. Du kan låse ut bestemte kataloger eller gjøre dem passordbeskyttet. Dette er flott for private prosjekter eller nye Content Management Systems hvor du vil ha litt ekstra sikkerhet. Men det er også vanlige oppgaver som omdirigering av 404 feilmeldinger til en bestemt nettside. Dette tar bare en enkelt linje med kode og det kan dramatisk påvirke hvordan besøkende reagerer på manglende sider.
Sannferdig er det ikke mye jeg kan si for å overbevise andre om at en .htaccess-fil er verdt å forstå. Når du ser det i aksjon så kan du gjenkjenne all verdien som kommer fra denne lille konfigurasjonsfilen. Også jeg håper resten av denne artikkelen kan presentere noen innsiktsfulle emner for å bringe webmastere inn i lyset av å administrere en .htaccess-konfigurasjon.
Tillat / nekte tilgang
Det er mulig å gjenkjenne potensielle spam-besøkende og nekte dem tilgang til nettstedet ditt. Dette kan være litt ekstremt, men hvis du vet at en person eller gruppe mennesker har blitt målrettet mot nettstedet ditt, er det noen alternativer å velge mellom. Du kan velge en domenehenvisning for å nekte eller forbye besøkende med en IP-adresse.
ordre tillat, nektet nekte fra 255.0.0.0 nekte fra 123.45.6. tillat fra alle
Disse prøvekoder ble kopiert fra Htaccess Guide, da de er den perfekte malen for å komme i gang. Legg merke til at den andre IP-adressen mangler det fjerde heltallet. Denne kodeblokken vil målrette mot den første IP-adressen (255.0.0.0) og hver IP innenfor området 123.45.6.0-255, så tillat all annen trafikk. Webmastere kan ikke bruke dette så ofte som andre teknikker, men det er nyttig å forstå.
Forhindre katalogoppføring
Det blir tider når du har en åpen katalog som er satt opp for å tillate surfing som standard. Dette betyr at brukere kan se alle filene som er oppført i en intern katalogstruktur, som bildemappen. Noen webmastere vil ikke tillate katalogoppføring og heldigvis er kodestykket ganske enkelt å huske.
Alternativer -Indexes
Jeg har sett dette svaret presentert utallige ganger gjennom Stack Overflow, og det kan være en av de enkleste .htaccess-reglene for å huske.
Det er mulig å faktisk opprett flere .htaccess-filer i hver av disse katalogene så kanskje en av dem er passordbeskyttet, men de andre er ikke. Og du kan fortsatt beholde Alternativer -Indexes slik at besøkende ikke kan bla gjennom nettstedet ditt / bilder / mapper.
Passordbeskyttelse
Passordbeskytter katalogene dine er en veldig vanlig prosedyre for Sikring av administrasjonsområder og andre mapper som er avgjørende for nettstedet ditt. Noen ganger vil du bare ha tilgang til en liten gruppe mennesker. Andre ganger er passord for å forhindre hackere i å få tilgang til nettstedet ditt administrasjon panel. Men uansett er det en veldig kraftig løsning på et stort antall problemer.
Det er en praktisk guide til passordbeskyttelse som skisserer de viktige kodestykket. Du må generer en passordfil som lagrer brukernavn / passord. Slik kan Apache kontrollere hva brukeren skriver inn for å se om de skal få tilgang. Og legg merke til hvordan du må generere en prøve for ditt brukernavn og passord.
Jeg vil anbefale å bruke denne htpassword generator slik at du kan spare litt tid. Syntaxen vil alltid komme ut perfekt, og du trenger ikke å kryptere passordet selv. Og det andre gode alternativet er å passordbeskytte en hel katalogoppføring. Vi kan se dette eksemplet i CSS-Tricks Code Snippets Gallery.
AuthType Basic AuthName "Dette området er passordbeskyttet" AuthUserFile /full/path/to/.htpasswd Krev gyldig bruker
Sikkerhet for WordPress
For å gi denne ideen om passordbeskyttelse til en god bruk, la oss vise et virkelige eksempel. Denne mer kompliserte kodestykket vil tvinge brukerautentisering for alle som har tilgang til WordPress wp-login.php-filen. Du finner den opprinnelige kilden på Ask Apache, som har mange andre WordPress-beskyttelsesbiter.
Ordre Avvis, tillat nekte fra alle tilfredsstille alle AuthName "Beskyttet av AskApache" AuthUserFile /web/askapache.com/.htpasswda1 AuthType Basic Krev gyldig bruker
Og hvis du skal følge disse .htaccess-reglene, kan det også bidra til å passordbeskytte administrasjonsområdet. Vanligvis wp-login.php filen kommer til å få mest mulig treff fra folk som forsøker å brute, tvinge seg inn i systemet ditt. Så selv bare eksempler koder ovenfor ville være mer enn nok ekstra sikkerhet for ditt WordPress-nettsted.
HTTP-URL omskrivningsregler
Omskrivning av nettadresser er trolig en av de vanligste bruksområder for .htaccess-filer. WordPress standard installasjoner kan faktisk generer en .htaccess-fil rett fra administrasjonspanelet. Dette lar deg lage flotte nettadresser som ikke har strukturen .php? P = 1.
Jeg vil se på dette omskrivningseksemplet på hvordan å oppdatere underskrifter til bindestreker siden det inneholder mange av de viktigste elementene.
Alternativer + FølgSymLinks OmskrivelseEngine På RewriteBase / RewriteRule! \. (Html | php) $ - [S = 4] RewriteRule ^ ([^ _] *) _ ([^ _] *) _ ([^ _] *) _ [^ _] *) _ (. *) $ $ 1- $ 2- $ 3- $ 4- $ 5 [E = uscor: Ja] RewriteRule ^ ([^ _] *) _ ([^ _] *) _ ] *) _ (. *) $ $ 1- $ 2- $ 3- $ 4 [E = uscor: Ja] RewriteRule ^ ([^ _] *) _ ([^ _] *) _ (. *) $ $ 1- $ 2- $ 3 [E = uscor: Ja] RewriteRule ^ ([^ _] *) _ (. *) $ $ 1- $ 2 [E = uscor: Ja] RewriteCond% ENV: uscor ^ Ja $ RewriteRule (. *) Http: //d.com/$1 [R = 301, L]
RewriteEngine og RewriteBase kan mest alltid settes til disse eksakte verdiene. Men du trenger RewriteEngine slått på for noe annet å jobbe. Det er mange guider online som forklarer hvordan du aktiverer mod_rewrite, og din hostingleverandør kan også hjelpe.
Legg merke til at syntaksen følger et mønster på RewriteRules på toppen. Disse reglene er vant til samsvarer med saker som sendes som en HTTP-forespørsel. Disse blir besvart av en RewriteRule som i dette tilfellet omdirigerer alt til domenet d.com. Endebrakettene som [R = 301, L] kalles omskrivningsflagger som er viktige, men mer av et avansert emne.
Mod_rewrite-syntaxen er definitivt litt forvirrende, men vær ikke skremt! Utdragene kan se mye lettere ut i andre eksempler.
Når jeg bare begynner, må jeg anbefale denne mod_rewrite webapp som hjelper deg med å generere kodeprøver ved hjelp av ekte nettadresser. Dette er et glimrende verktøy fordi du kan slå opp ulike elementer i syntaksen for å se hva de egentlig gjør i omskrivningsreglene. Her er en annen flott opplæring med et enklere eksempel å studere:
RewriteRule ^ dir / ([0-9] +) /? $ /Index.php?id=$1 [L]
Ikke prøv å overbelaste deg selv på disse på en gang. Det tok meg bra i løpet av 3-4 måneder å virkelig begynne å forstå hvordan man skriver om nettadresser med [0-9a-zA-Z] + og lignende mønstre. Fortsett å praktisere og med tiden lover jeg at du vil få slike ting som det er fellesfornuftskunnskap.
Kodeutdrag for webmastere
Jeg elsker brukervennlige utdrag og jeg vil sette sammen denne lille samlingen av relevante .htaccess-koder for webmastere. Hver av disse ideene kan passe pent inn i din egen .htaccess-fil sammen med andre kodeblokker. De fleste av disse utdragene er gode for løse raske problemer eller rettelser i webservermiljøet ditt. Tenk deg det perfekte Apache-oppsettet for helt nye webansvarlige, bare startet online.
Innstilling DirectoryIndex
Kommandoen for DirectoryIndex brukes vanligvis i en enkelt linje. Du kan fortelle Apache hvilke dokumenter som først skal behandles som “hoved-” dokument. Som standard vil dette målgjenstander som index.html, index.php, index.asp og andre indeksfiler. Men ved hjelp av denne kodestykket som jeg har kopiert nedenfor, har du muligheten til å gjøre dette rotdokumentet noe du liker.
DirectoryIndex index.html index.cgi index.php
Ordren av dokumenter skal starte med det viktigste og bevege seg gjennom rekkene til minst viktige. Så hvis vi ikke har en HTML- eller CGI-fil, vil fallbacken gå til index.php. Og du kan også nevne disse filene home.php eller someotherfile.php og det er alt gyldig syntaks.
Force WWW eller Non-WWW Subdomain
Google kan arbeide med begge versjoner av nettsteddomenet ditt hvis du ikke angir www.domain.com eller bare domain.com. Etter min erfaring er det best praksis å velg en av disse og sett den som det eneste valget via .htaccess. Da vil Google ikke indeksere ulike nettadresser, mens noen peker på WWW-underdomenet mens andre ikke gjør det.
# Force WWW Subdomain RewriteEngine På RewriteCond% HTTP_HOST ^ domain.com [NC] RewriteRule ^ (. *) $ Http://www.domain.com/$1 [L, R = 301] # Ingen underdomene RewriteEngine On RewriteCond% HTTP_HOST! ^ Domain.com $ [NC] RewriteRule ^ (. *) $ Http://domene.com/$1 [L, R = 301]
Denne kodestykket kommer fra et CSS-Tricks-arkiv og gir en veldig praktisk løsning. Du bør oppdatere domenet for å være det du trenger for ditt eget nettsted. Ellers vil det være problemer, og du vil legge merke til med en gang! Men jeg støtter sterkt en av disse to alternativene, og det står øverst på listen over oppgaver etter lansering av et nytt nettsted.
Force Media File Downloads
En annen ganske viktig kodebit tillater å tvinge bestemte medietyper til last ned i stedet for å bli vist i nettleseren. Umiddelbart kan jeg tenke på PDF-dokumenter og MP3-lydfiler som kan presenteres i et nedlastbart format, men hvordan gjør du det sørg for at de kan lastes ned? Jeg fant en lignende artikkel publisert på Htaccess Guide som skisserer denne kodestykket.
AddType application / octet-stream .zip .mp3 .mp4
Ta gjerne med enda flere filtyper på slutten av denne linjen. Alle medieformatene som bruker oktet-stream MIME-typen, kan lastes ned. Tvinge dette gjennom .htaccess er en veldig direkte rute for å sikre at folk ikke kan se disse filene i nettleseren.
Egendefinerte feildokumenter
Et siste siste stykke jeg vil legge til er en fullstendig mal av tilpassede feildokumenter. Vanligvis vises disse nummerene bare på serverendensen. Men det er mange av disse feildokumentene som du bør være kjent med. Noen eksempler kan være 403/404 feil og 301 omdirigering.
Denne feilkoden mal starter ved 100 og beveger seg opp i 500 feil. Vær oppmerksom på at du selvsagt ikke trenger alle disse. Bare de vanligste feilene ville være nødvendige, og muligens noen få uklare utdrag hvis du føler behovet.
Hvis du ikke gjenkjenner en kode, bare sett den opp på Wikipedia for å få en bedre forståelse.
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 ErrorDocument 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
Online .htaccess Webapps
- Htaccess Builder
- .htaccess omdirigeringsgenerator
- .htaccessEditor - Lag en .htaccess-fil
- Mod Rewrite Generator av GenerateIt.net
Andre nyttige ressurser
- .htaccess i Httpd Wiki
- Offisiell Apache htaccess-dokumentasjon
- Spør Apache Blog - Htaccess Archives
- Ultimate Guide til htaccess og mod_rewrite
- Alt du noensinne ønsket å vite om Mod_Rewrite Rules, men var redd for å spørre
Siste tanker
Det er så mange utallige ressurser på nettet som diskuterer .htaccess-filer. Mine koblede artikler og webapps er et flott sted å komme i gang. Men fortsett å praktisere nye ideer og ikke vær redd for teste ut kodestykker. Så lenge som du har en backup-fil så kan du teste ut alt du liker og det er en morsom læreropplevelse.
Hvis du har andre ideer eller forslag til .htaccess-administrasjon, vennligst del med oss i diskusjonsområdet nedenfor.