J'implémentais une fonctionnalité permettant au conteneur de session de suivre undernièreActivitéhorodatage, mis à jour à chaque demande authentifiée. Des trucs standards. Je l'ai écrit, je l'ai testé localement avec curl et j'ai remarqué quelque chose d'étrange : je recevais constamment un nouveauSet-Cookievaleur d’en-tête sur chaque réponse. Pas occasionnellement. Sur chacun d’entre eux. Une semaine plus tard, j'envoyais une pull request àmezzio/mezzio-session-cache.
Notre système avait une contrainte : deux applications backend, écrites dans des langages différents, partageant une seule session utilisateur. L’une d’elles était l’application principale PHP/Mezzio. L'autre était un service dans une pile différente qui devait lire et mettre à jour ledernièreActivitéhorodatage activé, le même conteneur de session.
Il existe plusieurs façons de faire fonctionner le partage de session polyglotte. Nous avons atterri sur un backend de cache partagé (Redis) avec une structure de session bien définie. Les deux applications pouvaient lire et écrire dans leurs propres bibliothèques, à condition qu'elles soient d'accord sur le format de stockage et le nom du cookie. L'ID de session était le contrat.
Ce contrat est la partie qui s’est discrètement rompue.
Mon premier réflexe fut la liste habituelle de suspects. Quelque chose appelaitrégénérerId()dans un middleware que je ne connaissais pas ? Y a-t-il eu une déconnexion déclenchée d'une manière ou d'une autre ? Une couche de cache mal configurée a-t-elle expulsé et recréé des sessions ?
Après avoir fouillé un peu dans la pile d'appels, je me suis retrouvé dans la bibliothèque elle-même. Et voilà :CacheSessionPersistancerégénérait l'ID de session chaque fois que les données...
[Courte citation de 8% de l'article original]