8722 sujets

Développement web côté serveur, CMS

Bonjour,
Pour les besoins d'un site, j'ai mis en place une session PHP de la façon suivante :
a) fichier functions.php contenant en tout début un appel à session_start
b) sur chaque page (script PHP) la première instruction est un require_once sur le fichier précédent
c) chaque page fait appel à une fonction renderDocument stockée dans functions.php, prenant en charge la sérialisation HTML / CSS
d) deux pages PHP connexion.php et deconnexion.php (leurs noms parlent d'eux-mêmes)
Problème constaté :
a) aucun cookie de session n'est enregistré (vérifié sur outils navigateurs)
b) chaque appel de page (chargement initial ou rafraîchissement) regénére une nouvelle session (ID session affiché différent)
Pour avancer, j'ai créé un petit projet de test plus simple contenant :
a) un fichier test-session-commons.php contenant juste l'appel à session_start
b) une page test-session-1.php ayant un require_once sur le fichier commun, affichant les infos session (ex. ID), stockant dans la session un timestamp et affichant un lien vers la seconde page
c) une page test-session-2.php ayant un require_once sur le fichier commun, affichant les infos session (ex. ID) + la valeur du champ timestamp récupéré dans $_SESSION et affichant un lien de retour vers la première page
Tout fonctionne impeccablement :
- l'identifiant de session est identique sur toutes les pages
- le cookie de session est correctement créé
- le timestamp actualisé sur la page 1 est correctement récupéré sur la page 2
Bref, à configuration identique, l'une marche l'autre pas... Ayant quelques heures de vol en informatique, je me doute bien qu'il doit y avoir un tout petit truc de différent, mais après avoir tourné longuement sur les scripts, rien ne me saute aux yeux.
J'ai pris bien soin :
- de n'avoir aucun caractère avant la séquence <?php débutant les scripts
- de tester avec ou sans la séquence ?> en fin de script functions.php
- d'appeler session_start une seule fois en début de functions.php, qui lui même est systématiquement la première instruction de chaque script page
- de placer la session avant toute sérialisation d'une balise HTML
- de tester avec et sans CSP (au cas où CSP aurait bloqué quoi que ce soit)
- de tester sur 4 navigateurs différents (Edge,Firefox, Opera et Iridium)
- de tester avec et sans session_name précédant session_start
- de tester avec et sans options passées en paramètre à session_start
- de tester sur le même serveur Apache HTTP, donc configuration strictement identique pour le site et la suite de test
Bref, le constat est toujours le même :
- la suite de test fonctionne impec
- le code normal duplique les sessions (ID différents + perte données stockées)
La seule chose que j'ai constatée est que la page connexion.php s'appelant elle-même (attribut @action du formulaire), la session est bien reconnue. Par contre, dès que je change de page pour aller, par exemple, à la page projets.php qui liste les projets utilisateurs mais requiert qu'il soit connecté, le message utilisateur non connecté est affiché.
Pas vraiment facile de mettre en place un code sur un outil de test PHP en ligne car la suite de test toute simple et suivant la même architecture du site, fonctionne sans accroc. Ce ne serait donc pas significatif.
Il est suprenant que sans changer de configuration, sur les 4 navigateurs, le cookie de session est systématiquement créé par la suite de test, mais ne l'est pas par le site, alors que l'architecture est la même entre les scripts PHP :
- session_start dans functions.php
- require_once de functions.php en début de chaque page
- code HTML sérialisé après appel de session_start
Ce message est un peu long, mais si quelqu'un a une piste je suis preneur.
J'ai bien évidemment largement navigué sur le web avant de poster ledit message pour creuser l'aspect session en PHP (qui n'est pas mon langage de base et que je déteste de plus en plus...) mais les tutoriels sont tous calqués sur la même architecture et, a priori, je suis le même schéma.
Merci d'avance pour ceux qui pourront éclairer un tant soit peu ma lanterne avec les subtilités des sessions PHP que vous auriez pu rencontrer au cours de vos pérégrinations.
Modifié par sepecat (06 May 2021 - 18:03)
Salut sepecat,
Pour qu'on puisse voir l'ensemble de ton code et peut-être tomber sur un truc que tu n'as pas vu, c'est possible que tu crées un repo sur Github ?
Je pourrais cloner le repo et tester si ça fonctionne chez moi.
MatthieuR a écrit :
Salut sepecat,
Pour qu'on puisse voir l'ensemble de ton code et peut-être tomber sur un truc que tu n'as pas vu, c'est possible que tu crées un repo sur Github ?
Je pourrais cloner le repo et tester si ça fonctionne chez moi.

Hello Matthieu.
Merci de ton attention. Le site, développé en mode "startup", comporte des algos spécifiques (ex. gestion automatique de la CSP, optimisation des styles, etc.) et comporte donc un code qui n'a pas vocation à être rendu public.
Ce qui complique les choses...
Par contre, je chercherais plus sur le forum Alsa un retour d'expérience de développeurs ayant rencontré à un moment donné des problèmes avec les sessions PHP et pouvant m'indiquer les causes qu'ils ont pu isoler et les solutions apportées.
De mon côté, je vais intégrer progressivement des fonctions sur les deux pages de test et voir à quel moment ça pète...
Cordialement.
PS - Félicitations en tout cas pour ton implication régulières, avec quelques autres intervenants, dans la vie de ce forum. Toujours appréciable pour apprendre / dépanner...
Solution trouvée...
Ma fonction renderDocument :
- utilise un flux (ob_start)
- sérialise le contenu HTML
- clôt le flux enrécupèrant le texte pour calculer sa longueur et alimenter l'entête HTTP content-length
- supprime tous les entêtes HTTP (header_remove)
- crée les entêtes HTTP adaptés à la page (CSP, content-type, etc.)
Logiquement, c'est le header_remove qui était fautif puisqu'il supprime le cookie de session...
Si cela peut aider.
Salut sepecat,
Ah cool que tu aies identifié l'action causant ce reste de session !
Et merci pour ton précédent PS, c'est toujours un plaisir de pouvoir donner un coup de main quand j'ai le temps et l'idée pouvant un peu débloquer la situation.
Je pourrais te retourner (ainsi qu'aux autres membres actifs) le même compliment Smiley biggrin
La pratique du développement web est une passion et dès qu'un problème/bloquage arrive ça titille de vouloir trouver la solution.