Il y a une semaine et un jour, j'ai envoyé une LRAR. D'après le site web de La Poste, elle a été remise contre signature il y a une semaine. Aujourd'hui, j'ai reçu la réponse de mon destinataire. Je n'ai toujours pas reçu l'accusé de réception (t'sais, le bout de carton). La Poste perd les accusés de réception, c'est-à-dire les trucs qui sont censés servir de preuve. C'est le 4e accusé perdu depuis le début de l'année 2020 sur plus d'une cinquantaine de LRAR, soit quasiment 10 % de perte. Ça commence à faire beaucoup…

Je ne sais pas si je suis le seul concerné…

Ce n'est pas indispensable mais il y toujours quelques fonctionnalités liées à la session comme le nombre de liens affichés par page

Je n'avais pas pensé à ça. Après vérification : dans la version 0.7.0, le stockage du nombre de liens affichés par page est la seule utilité d'une session quand on n'est pas connecté.

Du coup, le correctif est simple. Ma ligne header_remove('set-cookie'); devient :

if (! isset($_GET['linksperpage']))
{
    header_remove('set-cookie');
}

Dans mon cas, je ne souhaite pas proposer cette fonctionnalité (choisir le nombre de liens par page) donc je reste sur ma proposition initiale.

De manière générale, lorsqu'il y a un dysfonctionnement ou un comportement qui peut être amélioré comme ici, le bon réflexe est de remonter le problème en créant un ticket.

Je ne souhaite pas détenir un compte GitHub. ^^

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.