GuiGui's Show

Résumé : pour empêcher Shaarli (version 0.7) de déposer un cookie dans le navigateur web de tous tes visiteurs, même ceux qui ne s'identifient pour écrire / administrer, ajoute une instruction header_remove('set-cookie'); à la fin du fichier index.php, juste avant « renderPage(); ».

Un truc m'a toujours gonflé avec le logiciel Shaarli : il dépose tout le temps un cookie, même si le visiteur ne s'identifie pas. Je pourrais raisonner en juriste (ce cookie est-il légitime ? Dois-je recueillir le consentement de mes visiteurs pour le déposer ? A priori, non, mais, d'un autre côté, comme il n'est pas prévu ni attendu qu'un visiteur puisse se connecter, il est cocasse de déposer un cookie pour cette finalité… Etc.), mais ça ne m'intéresse pas. Je raisonne en technicien : toute action inutile doit disparaître, point. ÉDIT DU 03/11/2020 À 20 H 30 : comme me l'a signalé Arthur, la session permet de stocker le nombre de liens que le visiteur souhaite afficher sur une page. Les autres personnalisations nécessitent de s'être identifié. FIN DE L'ÉDIT.

Pour constater ce dont je parle, on peut procéder ainsi :

$ curl -k -D - -o /dev/null -s https://shaarli.guiguishow.info/ | grep 'set-cookie'
set-cookie: shaarli=idfu66r9egijg8f1nmh775ao96; domain=shaarli.guiguishow.info
set-cookie: shaarli_staySignedIn=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/

Mon WordPress, lui, ne dépose aucun cookie (tant qu'on ne poste pas un commentaire ou que l'on ne se connecte pas à son administration, bien entendu) :

$ curl -k -D - -o /dev/null -s https://www.guiguishow.info/ | grep 'set-cookie'
$ 

À la ligne 207 du fichier index.php de Shaarli, on trouve une instruction « session_start(); » qui appelle le gestionnaire de sessions qui, par défaut, dépose un premier cookie. Un deuxième est déposé par la fonction logout() qui est systématiquement appelée par la fonction setup_login_state() qui est appelée ligne 329.

J'utilise la version 0.7.0 de Shaarli. Si le deuxième cookie n'est plus déposé sur une version plus récente, le premier l'est toujours.

Le formulaire de connexion est traité à partir de la ligne 451. On constate que toutes les fins de ce bloc « if » contiennent un « exit() », c'est-à-dire la fin du script.

D'une manière générale, le dépôt d'un cookie se fait avec un entête de réponse HTTP « set-cookie ». On ne peut pas demander au serveur web de supprimer l'entête HTTP « set-cookie » (Header always unset set-cookie avec Apache httpd, par exemple) sinon tout accès admin / écrivain devient impossible.

Je n'ai pas les compétences nécessaires pour remanier le code de Shaarli afin de déplacer le « session_start() » au bon endroit, démarrer une session que si le visiteur tente de s'identifier, etc.

En revanche, je comprends que je peux ajouter une instruction header_remove('set-cookie'); à la fin du fichier index.php, juste avant « renderPage(); ». ÉDIT DU 03/11/2020 À 20 H 30 : si l'on veut que l'utilisateur puisse choisir le nombre de liens affichés sur une page, il faut encadrer l'instruction d'une condition : if (! isset($_GET['linksperpage'])) header_remove('set-cookie');. FIN DE L'ÉDIT.

En faisant ça :

• Dans le cas général, le fonctionnement interne de Shaarli reste inchangé, il tente bien de déposer un cookie en ajoutant un entête HTTP « set-cookie », mais, juste avant le rendu de la page, hop, on l'en empêche en supprimant ledit entête ;
  
  
• Quand je m'identifie, le formulaire de connexion est vérifié et validé, l'expiration du cookie (dont l'entête permettant son dépôt a déjà été ajouté à la pile des entêtes de réponse) est positionnée en fonction de mon choix (« Stay signed in » coché ou non), puis mon navigateur est redirigé vers la page d'accueil et le script s'arrête… sans atteindre l'instruction demandant la suppression de l'entête déposant un cookie. À partir de là, ayant reçu l'entête « set-cookie », mon navigateur web sait qu'il doit positionner un entête « cookie » à chaque fois qu'il revient sur mon shaarli donc l'identification fonctionne correctement.