Gestion des options de cookies

• Mettre l’option 'secure' à true dès qu’on est en HTTPS
• Mettre l’option 'secure' à true si la constante _COOKIE_SECURE est définie (auparavent uniquement sur les cookies _COOKIE_SECURE_LIST + spip_session);
• Appeler la plupart des cookies pour SPIP avec l’option 'httponly' à true
• Déprecier la constante _COOKIE_SECURE_LIST (utiliser l’option 'httponly' à true sur les appels concernés)
• (edit): Déprecier la constante _COOKIE_SECURE
• (edit): Changement de signature de spip_setcookie (pour reprendre celle de php)

Refs: #5552 (closed)

--

J’ai plusieurs questions tout de même :

• sur _COOKIE_SECURE peut être qu’il faut simplement de déprécier aussi, vu qu’on affecte true si https ?
• sur le tableau $options (j’ai mis @deprecated l’ancien code): mais je me demande s’il ne faut pas revenir à la signature de PHP.

Je m’explique :

Depuis PHP 8+ on peut nommer les paramètres d’appels de fonction, tel que

• setcookie('nom', 'valeur', expires: 3600, secure: true);

PHP sur cette fonction accèpte, comme on a fait, un tableau en 3è option

• setcookie('nom', 'valeur', ['expires' => 3600, 'secure' => true]);

Mais à partir d’un tableau, en PHP on peut aussi utiliser le spread operator (···) pour exploser un tableau (même avec clés indexées) en paramètre de fonction, tel que

• setcookie('nom', 'valeur', ...['expires' => 3600, 'secure' => true]);

Un des avantages des arguments nommés, c’est que les IDE et les outils d’analyse statique voient rapidement les typages et les éventuels prooblèmes, contrairement à des tableaux où il faut alors spécifier dans le PHP doc un format assez spécifique.

Ça serait plus clair et cohérent que cette fonction spip_setcookie mappe la signature de PHP du coup, non ? (edit: fait)