» direct naar zoek en menu

Tijdschrift voor webwerkers » Artikel #132

Aan de slag met .htaccess - controle op je server

De structuur, vormgeving en het gedrag (de front-end) van een website komt tot stand door middel van (X)HTML, CSS en JavaScript. Logica en datamanipulatie wordt door de back-end verzorgd, bijvoorbeeld door PHP en MySQL. Dat alles wordt aangestuurd door de webserver, bijvoorbeeld Apache. Ook daar heb je invloed op hoe de zaken geregeld worden. In het geval van Apache — één van ’s werelds populairste webserver-softwarepakketten — kan dat met behulp van een klein bestandje: .htaccess.

.htaccess stelt je in staat om per directory de globale webserverinstellingen aan te passen en naar je hand te zetten. Spammers weren, leesbare URL’s maken, bestanden afschermen of persoonlijke foutmeldingen tonen – het kan allemaal. Enkele praktische voorbeelden.

Beheers je bezoekers

Stel, je bent online een nieuwe site aan het opzetten, maar je wilt er zeker van zijn dat niemand stiekem een kijkje kan nemen terwijl je druk bezig bent. Met behulp van wat regels in je .htaccess kun je de toegang beperken tot alle IP-adressen die wel toegang mogen krijgen:

order deny,allow
# Ik

allow from 1.2.3.4 
# Klant
allow from 4.3.2.1
deny from all

Het tegenovergestelde kan ook: iedereen mag kijken, behalve die paar kwajongens die zich constant misdragen op je site. De zogenaamde IP-ban:

order allow,deny
# Boosdoener

deny from 1.2.3.4 
# Spammer
deny from 1.2.3.5
# Een hele reeks
deny from 2.4.6.
allow from all

Wil je de toegang beperken, maar weet je niet welke IP-adressen toegang mogen hebben? Dan kun je je site ook afschermen achter een wachtwoord. Hiervoor is nog een tweede bestand nodig om de gebruikersnamen en wachtwoorden in op te slaan: .htpasswd. Je kunt online makkelijk inhoud voor .htpasswd aanmaken met behulp van password generators.

# pad naar het .htpasswd bestand

AuthUserFile /var/www/html/private/.htpasswd
# naam van het afgeschermde gebied
AuthName "Beschermd gebied"
AuthType Basic
<Limit GET POST>
 require valid-user
</Limit>

Beheers je bestanden

Welk indexbestand wordt het eerst gelezen wanneer je een directory bekijkt? Eerst index.php en dan index.html, of juist andersom? Bepaal zelf de volgorde:

DirectoryIndex index.html index.php default.html frameset.htm

Je kunt je eigen "pagina niet gevonden"-foutmelding presenteren aan de gebruiker, in plaats van de standaardmelding die door de webserver wordt voorgeschoteld. Maak een persoonlijke 404-pagina en verwijs ernaar in je .htaccess. Dit principe geldt ook voor andere foutmeldingen die van de webserver afkomstig zijn (zie Apache documentatie).

ErrorDocument 403 /fouten/geen-toegang.html
ErrorDocument 404 /fouten/niet-gevonden.html

Wil je niet in elke directory van je site een indexbestand zetten om zo zogenaamde "open dirs" te vermijden? Dat kan. Voeg 1 regel toe aan je .htaccess en alle bezoekers krijgen een 403-melding (toegang verboden), die je zojuist naar je eigen hand hebt gezet met de genoemde regel.

Options All -Indexes

Zou het niet handig zijn om één keer alle verschillende kleuren in je stylesheet te kunnen declareren in de vorm van variabelen? Dat scheelt weer wat acties "zoeken & vervangen" bij wijzigingen. CSS is statisch, dus variabelen aanmaken gaat niet. Je zou CSS-code kunnen genereren met php en die dynamische CSS presenteren aan de gebruiker, maar je zou er ook voor kunnen zorgen dat .css-bestanden zich net zo gedragen als .php-bestanden. In feite verander je stylesheets in .php-bestanden, met alle dynamische mogelijkheden van dien.

AddType application/x-httpd-php .css

Nu kun je php-code gebruiken in je stylesheet. Vergeet dan echter niet bovenin je bestand de juiste headers mee te sturen: header('Content-type: text/css');

Een zeer handige en krachtige module waar Apache gebuik van kan maken is mod_rewrite 1. Hiermee kun je door middel van een set door jou opgestelde regels (met behulp van regular expressions) inkomende URL’s herschrijven en manipuleren. Erg handig voor het leesbaar maken van je URL’s, maar ook voor bescherming tegen leechen: het direct linken van afbeeldingen, filmpjes of andere bestanden.

RewriteEngine on
# Als de referrer niet leeg is...
RewriteCond %{HTTP_REFERER} !^$ [NC]
# ...en de referrer niet afkomstig is van mijndomein.nl...
RewriteCond %{HTTP_REFERER} !^http://mijndomein.nl.*$ [NC]
# ...blokkeer dan het opgevraagde plaatje of filmpje
RewriteRule \.(gif|jpg|png|mpg|mov)$ - [F]

RewriteEngine on zorgt ervoor dat de webserver begrijpt dat de mod_rewrite-module wordt aangesproken. De twee RewriteCond-regels bekijken de herkomst van de opgevraagde URL. Is één van deze twee condities van toepassing, dan wordt de RewriteRule uitgevoerd: als de URL eindigt op één van de opgegeven extensies, geef dan een 403-melding (Forbidden, vandaar de [F]).

Beheers je URL’s

Stel, je bent van domeinnaam veranderd en je wilt je bezoekers doorsluizen van je oude naar je nieuwe domein. Dat zou in HTML kunnen met <meta http-equiv="refresh" content="1;url=http://www.nieuwdomein.nl/" />, maar dan komt de oude pagina in de history van de browser terecht en wordt die ook nog geïndexeerd door zoekmachines. Bovendien is het bij deze methode niet mogelijk om door te geven dat de pagina "permanent verplaatst" is, wat wel nodig is om je classering bij zoekmachines te kunnen behouden. Je zou de verwijzing ook met behulp van php (of een andere scripttaal) kunnen realiseren, met header("location:http://www.nieuwdomein.nl/"). Nu wordt het doorsturen geregeld op de server, waardoor je history schoon blijft, en je zou met een extra header() nog de "permanent verplaatst" status kunnen meegeven. Echter, een ander nadeel blijft bestaan bij beide methoden: de bezoeker moet de pagina bezoeken waar deze verwijzing in staat om doorverwezen te worden.

Een redirect in je .htaccess lost al deze problemen op. Dit werkt ten eerste zowel op bestands- als op directoryniveau, met behoud van het opgegeven pad. Hierdoor hoef je niet een specifiek bestand te bezoeken om doorverwezen te worden naar de nieuwe plek. Ook kun je optioneel aangeven of de verhuizing permanent of tijdelijk is, wat weer gunstig is voor de optimalisatie voor zoekmachines.

# Stuurt 301 header mee: permanent verplaatst
Redirect permanent / http://www.nieuwdomein.nl/
Redirect /actueel http://www.mijnbedrijf.nl/nieuws
Redirect /rss.xml http://www.mijnblog.nl/feeds/rss

Variabelen geef je via de URL door aan je script met de query string. Het nadeel van een query string is echter dat deze de leesbaarheid van de URL niet ten goede komt. Ook zoekmachines negeren de query string bij het indexeren en waarderen van pagina’s. Met de eerdergenoemde mod_rewrite-module kun je hier wat aan doen.

RewriteEngine on
RewriteRule ^fotos/(.*)/([0-9]+)/in/set-([0-9]+)/$ http://mijnalbum.nl/photos.php?user=$1&photoid=$2&setid=$3 [L]

Het bovenstaande voorbeeld zou de URL http://mijnalbum.nl/fotos/jan/12345/in/set-6789/ achter de schermen herschrijven naar http://mijnalbum.nl/photos.php?user=jan&photoid=12345&setid=6789, waardoor het script in photos.php de juiste variabelen toegespeeld krijgt, terwijl de gebuiker (of zoekmachine) de eerste, veel leesbaardere, URL blijft zien.

Zo kun je er ook voor zorgen dat niet meer valide pagina’s opgevangen worden. Toen ik een tijd geleden van weblogsysteem veranderde, werd er hier en daar nog gelinkt naar mijn oude archieven. Door middel van een slimme RewriteRule kon ik die doorverwijzen naar de nieuwe plek.

# oud:   http://loweblog.com/archives/archive_2005-m09.php
# nieuw: http://loweblog.com/archive/2005/09/
RewriteEngine on
RewriteRule ^archives/archive_([0-9]{4})-m([0-9]{1,2}).php$ http://loweblog.com/archive/$1/$2/ [R=301,L]

De R=301 vlag geeft aan dat de URL niet alleen achter de schermen, maar ook zichtbaar voor de gebruiker herschreven moet worden, samen met een 301-header (permanent verplaatst). Meer over flags.

Meer weten?

1 Om te kijken of deze (en andere) modules in Apache zijn geladen, kun je het resultaat van phpinfo(INFO_MODULES) bekijken.

Auteur

Lodewijk Schutte

bedenkt, bouwt en beheert bij de Bond en beukt bikkelhard in zijn band. Bovendien babbelt hij over bijzondere belevenissen in zijn blog.

Publicatiedatum: 22 november 2006

Let op

Naar Voren is op 18 juli 2010 gestopt met publiceren. De artikelen staan als een soort archief online. Het kan dus zijn dat de informatie verouderd is en dat er inmiddels veel betere of makkelijkere manieren zijn om je doel te bereiken.

Copyright © 2002-2012 » NAAR VOREN en de auteurs