Lors du développement d’un site web, il est pratique à partir d’un certain moment de le publier et pouvoir le rendre accessible à une minorité de personnes (du genre le client pour commencer à avoir du feedback).
Je décris dans ce billet différentes méthodes permettant de répondre à ce besoin.
Filtrage par IP
Une solution naïve serait de bloquer l’accès au site sauf à une poignée d’IPs, qui serait les IPs des personnes autorisées à consulter le site en construction. Cela cependant ne fonctionne pas si l’IP n’est pas connu à l’avance, comme par exemple lorsque le FAI fournit des IPs d’un pool dynamiques ou tout simplement lors d’une présentation (Orange et Bouygues notamment).
Filtrage par Cookie
Une seconde solution, et c’est celle que je veux présenter ici, se base sur un autre mécanisme. Je trouve cette solution particulièrement élégante car simple tout en répondant parfaitement au problème.
Dans cette solution, la clé n’est plus l’IP comme dans la première solution mais le cookie. La présence d’un cookie détermine l’accès au site.
L’implémentation la plus simple se fait en deux phases:
- la première phase est la création d’une page-à-la-con dont le seul objectif sera d’insérer le cookie au navigateur puis d’effectuer une redirection par JavaScript vers le point d’entrée du site.
- la seconde phase est l’implémentation de la restriction, en général au sein du serveur web car alors c’est de la configuration pur et il n’est pas nécessaire de bidouiller le code source du site.
La restriction doit répondre aux règles suivantes :
- L’url permettant de poser le cookie doit être en accès libre. Il faut la garder secrète.
- L’accès au site doit être autorisée si la requête provient d’une IP autorisée ou si le cookie d’accès est présent
- Poser un fichier robots.txt pour éviter que l’url du premier point soit crawlé par les principaux moteurs de recherche.
Ci-dessous un exemple d’implémentation de la restriction façon Apache
SetEnvIf Request_URI "youhou_cookie\.php$" let_me_in SetEnvIfNoCase Cookie "euphor=tissu" let_me_in order deny,allow allow from 82.247.154.152 allow from 193.248.37.205 allow from 2001:470:1f13:129f::/64 allow from env=let_me_in deny from all
Et voilà une version pour IIS
<configuration>
<system.webServer>
<rewrite>
<rules>
<clear />
<rule name="cookie-redirect" enabled="true" patternSyntax="ExactMatch" stopProcessing="true">
<match url="entry-url" />
<conditions logicalGrouping="MatchAll" trackAllCaptures="false" />
<action type="Redirect" url="/" appendQueryString="false" redirectType="Found" />
</rule>
<rule name="cookie-checker" patternSyntax="ECMAScript" stopProcessing="true">
<match url=".*" negate="false" />
<conditions logicalGrouping="MatchAll" trackAllCaptures="false">
<add input="{REQUEST_URI}" pattern="^entry-url$" negate="true" />
<add input="{HTTP_COOKIE}" pattern="pass=euphor" negate="true" />
</conditions>
<action type="AbortRequest" />
</rule>
</rules>
<outboundRules>
<rule name="set-cookie" preCondition="url-checker" patternSyntax="ECMAScript" stopProcessing="false">
<match serverVariable="RESPONSE_Set_Cookie" pattern=".*" negate="false" />
<action type="Rewrite" value="pass=euphor; Max-Age=86400" replace="true" />
</rule>
<preConditions>
<preCondition name="url-checker">
<add input="{REQUEST_URI}" pattern="entry-url" />
</preCondition>
</preConditions>
</outboundRules>
</rewrite>
<httpErrors errorMode="Detailed" />
</system.webServer>
</configuration>
Il sera préférable d’effectuer la redirection en javascript plutôt qu’avec un code HTTP 302, on évite quelques cas à priori bizarre (je ne me suis pas penché dessus) où le cookie n’est pas pris en compte par le navigateur.
FAQ
- Pas besoin de s’embêter avec tout ça, il suffit simplement de ne pas laisser trainer l’url du site non ?
Il suffit de surfer sur le site avec Google Chrome par exemple et le site se fait référencer dans la semaine. - En plaçant un robots.txt, on évite que le site se fasse référencer par les moteurs de recherche, c’est bon là ?
Oui Google et Bing! respectent le fichier robots.txt, mais ce n’est pas un simple fichier qui va bloquer, techniquement parlant, le référencement par tout moteur de recherche. Le crawler de la bibliothèque nationale de France par exemple ignore complètement ce fichier - Obligé de suivre la solution 2 alors ?
Sous l’angle de la sécurité, garder secret un nom de domaine ou poser un fichier robots.txt c’est de l’esbrouffe. Tant qu’il n’existe pas de barrière solide, onpeutdoit considérer que le site est en accès libre. La solution 1 peut suffire mais la solution 2 apporte de la souplesse.
