Beskyt dit testsite
Det er ikke unormalt at arbejde på et website der ikke skal være frit tilgængeligt. Der kan være flere grunde til at arbejde i et mere eller mindre lukket/hemmeligt miljø:
- Et nyt website er ved at blive lavet, men du ønsker først at andre kan se indholdet når tilpas meget er færdiggjort (et website bliver vel aldrig færdigt?)
- Et websiteder er lanceret kører som det skal, men der er også brug for et ‘legeplads-miljø’ hvor ejeren eller udvikleren kan prøve ting uden at driftsiden ligner et kaos.
- Forskellige udgaver af 1 og 2 med eksterne udviklere der skal fremvise ufærdigt arbejde, indhold der ikke er juridisk godkendt osv.
Hvorfor beskytte testsites?
For at gøre en lang historie kort: det er ikke smart at have ufærdigt indhold liggende på nettet. Måske holder du URL’en hemmelig, men internettet rummer en række historier om “hemmelige” ubeskyttede testsites der bliver uønsket opdaget – enten af mennesker eller af søgemaskinernes crawlere.
Hvis testsitets tekstindhold ikke er unikt kan der opstå problemer med dublicate content og som nævnt ovenfor kan der være problemer juraen i de benyttede tekster. Derudover fremstår websitets ejer(e) ikke specielt professionelt med ufærdigt indhold liggende online.
Hvordan kan testsites beskyttes?
Der er forskellige måder at gøre et testsite beskyttet fra offentligheden på. Nogle af dem er bedre end andre, men det afhænger af ofte af hvilket testmiljø du arbejder i og hvem der skal kunne tilgå det. Nedenfor gennemgår jeg et par af de metoder jeg har gjort brug af i forskellige situationer.
Passwordbeskyttelse
Ved passwordbeskyttelse er du ganske godt sikret. Alt efter hvordan du gør vil sikringen kunne brute-forces, men medmindre indholdet er yderst hemmeligt ville jeg ikke bekymre mig om denne risiko. En let måde at passwordbeskytte på er ved at bruge .htaccess- og .htpasswd-filer (eller tilsvarende hvis dit website ikke kører på Apache-server).
IP-begrænsning
Ved at begrænse hvem der kan besøge dit website på IP-niveau har du ganske god kontrol. Begrænsningen foretages typisk i .htaccess-filen hvilket kræver at du har FTP-adgang når du ønsker at åbne eller lukke for adgangen til sitet. Hvis du som udvikler laver et website for en virksomhed vil du derfor skulle forholde dig til hvilke IP-adresser virksomheden skal kunne tilgå dit arbejde fra. Dette kan give udfordring med dynamiske IP’er, folk der arbejder hjemmefra og lignende.
Robots.txt/Meta-robots ‘beskyttesele’
Endelig er der muligheden for at fortælle forskellige crawlers – eksempelvis Google – at de ikke skal crawle siderne i testmiljøet. Dette er efter min mening en mindre optimal løsning der dog kan forsvares hvis man har testmiljøet på en dedikeret IP, benytter samme domæne for testsitet (kræver at man tilgår testsitet ved at pege på test-IP’en for domænet ved ændring hosts-filen på ens lokale pc) og IKKE deler test-IP’en med andre.
Hvad er den bedste løsning?
Hvis det er muligt er det optimalt at kombinere de forskellige sikringer. Når du arbejder med et test-miljø kan det aldrig skade at have en robots.txt-fil der afviser søgemaskinerne. Det er selvfølgelig vigtigt at denne fjernes hvis hele testsitet flyttes til driftmiljøet, men hvis du alligevel formår at glemme det vil du med stor sandsynlighed få påtalt fejlen i Google Webmaster Tools.
Hvis du kun skal vise testsitet til få personer vil jeg anbefale at benytte både password-beskyttelse og adgangsbegrænsning på IP-niveau, men en enkelt af disse alene kan også være fint.