Le Livre d'Argent

Je profite de la mise à jour du site pour essayer quelques nouveaux réglages, et donc du coup, j'en profite aussi pour vous fournir les explications qui vont avec. Comme le titre l'indique, nous allons cette fois parler de la façon dont un site Web (par exemple, un forum, ou un webmail) peut vous reconnaître(1), et savoir que c'est à vous qu'il doit fournir certains accès ou certaines informations (ce qui est plutôt conseillé. Vous n'aimeriez pas que n'importe qui puisse lire vos messages privés ou modifier vos réglages persos, je suppose).

La difficulté à ce niveau était que le protocole http (la façon dont l'information s'échange entre le serveur et votre navigateur) n'est pas fait pour ça, à la base : d'autres protocoles, comme par exemple ceux qui servent aux messageries instantanées, sont conçus spécifiquement pour que les utilisateurs soient clairement identifié, puisque c'est à la base de leur fonctionnement. En revanche, le Web a d'abord été pensé comme un réseau de pages statiques, diffusées de la même façon à tout le monde.

Pour arriver à ce genre de comportements, il a donc fallu mettre en place des solutions de contournement (les premières d'une longue série).

La première de ces solutions a été de demander à l'utilisateur de s'authentifier directement dans l'en-tête du message qu'il envoie au serveur. C'est, à mon sens, la manière de procéder la plus propre, parce qu'elle utilise directement le protocole lui-même, sans avoir à recourir à des outils supplémentaires.

En revanche, cette technique présente quelques manques de souplesse qui peuvent parfois s'avérer problématiques : d'abord, ça ne laisse pas la possibilité d'accéder aux pages ainsi protégées de manière anonyme : pour une page donnée, soit la sécurité n'est pas activée, et personne n'est clairement identifié ; soit elle l'est, et les utilisateurs doivent entrer un login et un mot de passe pour réussir à passer, sinon ils n'ont droit qu'à un code d'erreur.

Ensuite, ça ne porte que sur les pages sur lesquelles ça a été activées : si vous vous êtes identifiés pour accéder à une page protégée, puis que vous chargez une page non-protégée, on perd les identifiants, et il n'y a aucune information permettant de vous donner des informations spéciales sur la page non-protégée (par exemple, vous ne pourrez pas avoir un petit « bonjour <votre pseudo> » qui s'affiche en haut de page. Ni de trucs plus utiles que ça, du coup).

De plus, une gestion dynamique de ce genre de fonctionnement est assez lourde à mettre en place, ce qui fait que, la plupart du temps(2), la configuration de ce qui est accessible et de ce qui ne l'est pas est chargée en mémoire au démarrage du serveur, et ne change plus jusqu'à ce qu'on le relance.

Enfin, seuls le login et le mot de passe sont transmis de cette manière (ça ne permet pas de mémoriser d'autres informations) ; et comme c'est transmis dans l'en-tête du message, on ne peut pas envoyer de belles pages de connexion, puisque le navigateur doit envoyer ces informations avant de recevoir la réponse, et donc il faut se connecter depuis une petite pop-up faite exprès, ce qui n'est pas forcément très agréable.

Du coup, depuis que l'on est passé à des pages générées dynamiquement plutôt qu'à des pages statiques, une autre solution a été proposée, qui consiste à faire gérer l'identification par le logiciel qui génère les pages plutôt que par celui qui les envoie. Car en effet, les sites Web dynamiques que l'on croise le plus souvent aujourd'hui sont gérés par deux logiciels distincts : le serveur HTTP, qui récupère vos requêtes et regarde à quels fichiers ils correspondent ; et le CGI(3), qui va générer du contenu spécifique en fonction de la requête que vous exprimez.

Pour transmettre au CGI les informations dont il a besoin pour fonctionner (car lui-même n'a, de base, pas plus d'informations que ce que reçoit le serveur HTTP), on utilise des cookies. Il s'agit de petits fichiers textes, stoqués par votre navigateur, dans lequel on enregistre des petits bouts d'informations, et qui sont envoyés au serveur avec votre requête pour qu'il se rappelle de vous.

Cela permet donc de simuler de véritables sessions : le CGI stocke, quelque part sur le serveur, les informations qu'il associe à votre compte (par exemple, votre nom d'utilisateur, la date de votre dernière connexion, vos préférences personnelles, tout ça), et votre navigateur enregistre un cookie contenant un identifiant unique permettant de vous reconnaître. Quand vous demandez à charger une page du site, le navigateur envoie votre cookie d'identification, et le CGI n'a plus qu'à charger les informations correspondantes pour vous générer une page sur mesure.

Seulement, en informatique comme ailleurs, rien n'est parfait, et cette technique présente elle aussi quelques inconvénients. D'abord, elle ne fonctionne que si votre navigateur est configuré pour accepter les cookies(4) (ce qui est généralement le cas par défaut, mais que vous pouvez tout-à-fait modifier).

Ensuite, elle nécessite que le serveur soit capable de mémoriser vos informations, et qu'un traitement dynamique ait lieu à chaque fois que vous essayez de charger une page. Ce n'est pas forcément quelque chose de très handicapant, mais sur une machine de faible capacité, ça peut quand même représenter une charge dont on préférerait se passer.

Ce système fait aussi qu'il y a plusieurs manières de s'identifier : d'abord, lors de votre connexion, vous devez envoyer votre login et votre mot de passe (ou autres ; c'est cette fois à la personne qui développe le site de décider), puis, une fois votre session démarrée, vous devez envoyer un autre identifiant qui permet de récupérer les informations temporaires la concernant. Sur pas mal de sites, il y a également une option « me connecter automatiquement », qui stocke dans un cookie (différent du cookie gérant la session) les informations permettant de démarrer une session. Cela fait donc d'autant plus de portes d'entrées possibles pour quelqu'un ayant décidé de vous faucher votre compte.

Ceci mis à part, les deux solutions sont par ailleurs à égalité sur ce point : elles demandent toutes les deux que vous transmettiez des informations permettant de vous identifier chaque fois que vous envoyez une requête au serveur. Si vous utilisez le protocole HTTP ordinaire, cela signifie donc que n'importe qui présent sur le réseau peut écouter ces transferts, et donc récupérer des informations qui lui permettraient de se faire passer pour vous, ce qui n'est pas spécialement intéressant.

Dans tous les cas, donc, je vous recommande vivement (à condition que le site en question fournisse cette possibilité, ce qui n'est hélas pas toujours le cas) de préférer utiliser la navigation sécurisée par le protocole HTTPS, dont je vous ai parlé il n'y a pas longtemps : cela permettra au moins d'éviter qu'un indésirable écoute aux portes.

En ce qui concerne mon site, j'ai décidé, comme je vous le disait au début, d'essayer un réglage un peu particulier. Je suis bizarre, que voulez-vous ^^

En fait, une des caractéristiques particulières de mon site est que je n'utilise presque pas de CGI : plutôt que d'être régénérées à chaque visite, les pages Web contenant mes articles sont enregistrées en dur dans des fichiers à chaque fois que j'en ajoute un ou que quelqu'un répond (ce qui, hélas, ne se produit pas très souvent…) ; et, la plupart du temps, c'est le serveur HTTP qui vous envoie directement ces fichiers statiques.

Je n'ai donc pas besoin d'utiliser les sessions gérées par le CGI comme le font la plupart des autres sites, et j'ai donc décidé d'utiliser plutôt la première méthode, qui me semble plus propre et plus sécurisée ; avec une configuration spécifique permettant d'en contourner les limites que j'évoquais ci-dessus.

En fait, quand vous vous connectez à mon site en HTTP ordinaire, je ne vous demande aucun identifiant, mais vous n'avez accès qu'aux pages que je considère comme ne contenant aucune donnée sensible. Histoire de ne pas avoir à changer la configuration de mon serveur à chaque évolution du site, j'ai demandé au serveur d'interdire l'accès, en HTTP, à toutes les pages dont un élément du chemin d'accès commence par un caractère « _ ». Comme ça, je n'ai qu'à rajouter ou retirer ce caractère au début de mes noms de fichiers pour modifier les droits d'accès.

En revanche, j'ai demandé une authentification sur l'ensemble du site lorsque vous vous connectez en HTTPS, ce qui permet d'avoir accès à tout le contenu que je veux diffuser, de manière sécurisée, sans que vous ayez besoin d'accepter les cookies(5). Comme l'ensemble du site est protégé de cette manière, j'ai accès aux informations chaque fois que j'ai besoin d'effectuer des traitements particuliers (c'est-à-dire pas souvent pour le moment, mais je pourrais en rajouter si besoin).

Cette solution me semble intéressante : elle ne vous ne vous empêche pas d'envoyer des données (par exemple, une réponse à cet article ^^) au site, si votre pseudo n'est pas réservé, puisque vous n'avez rien de confidentiel à transmettre (pas de mot de passe…) ; et de l'autre côté, elle requiert que vous passiez par une navigation sécurisée pour transmettre des infos confidentielles.

Notez que si vous ne disposez pas de compte sur mon site (si vous en voulez un à vous, il faut m'envoyer un mail pour me le demander), vous pouvez tout de même vos connecter en HTTPS en utilisant le pseudo-compte invité que j'ai mis en place : puisqu'il faut nécessairement un login, celui-ci est « guest », et le mot de passe correspondant est « guest » également. Mais ne vous attendez pas forcément à ce que cet utilisateur anonyme ait tous les accès, évidemment.