Session d'arachage de cheveux

[Dadou]

Bon voila j'ai un problème de sessions (pas de cheveux, mais si ça continue cela risque de le devenir )

Je travaille sur un projet pour lequel on a 4 serveurs :

- Un de Dev pour faire tous les développements,

- Un de Recette pour les batteries de test

- Un de Publication pour permettre aux charmantes demoiselles de la Com d'intégrer le contenu

- Et celui de Production qui est le serveur visible par tous les internautes.

On a développé un backoffice, l'authentification fonctionne grâce aux sessions (et accessoirement, il y a une limitation par IP).

Sur le Dev, Recette, et la Publication, cela fonctionne sans problèmes, par contre la ou cela se corse c'est sur la Production (et forcément sur celui qui doit être le plus carré, ) :

En gros quand on tape son login et password, on est bien authentifié, mais dès que l'on va ailleurs dans le back, on est renvoyé au formulaire de connexion comme si la session n'étais pas généré.

Mais, si auparavant, je passe par le Front, qui utilise aussi les sessions, le problème disparait. C'est à dire que je peux me connecter normalement au back, puis aller ou bon il me semble ensuite.

Enfin je me vois mal expliquer au client que pour accéder au back qu'il devra passer par le Front pour générer la session.

La j'avoue, je tourne en rond depuis un petit moment et je ne comprend pas pourquoi sur les 4 il y en a un qui ne fonctionne pas correctement

Merci d'avance pour le coup de mail,

[Portekoi]

Bonjour,

Quand tu le renvoies au formulaire, c'est parce que les sessions sont vides?

Tu as bien la même version de php entre les serveurs? As tu comparé les 4 phpinfo(); ?

Portekoi

[Dadou]

A mon avis, oui la session n'est pas toujours généré sur la Prod

J'ai fait attention d'avoir la :

- Même version d'apache, c'est à dire la 2.0.63

- Même version de PHP, c'est à dire la 4.3.9

- Même version de mysql, c'est à dire la 4.1.22

Concernant le serveur de Dev et de Recette, c'est moi qui les ait installé, la Publication et la Production c'est le service informatique du client m'affirmant qu'ils sont rigoureusement identique (ce que je commence à douter fortement) et forcement, le seul pour lequel je ne peux pas tester directement le phpinfo() c'est celui qui merde

[KaRaK]

Hello,

A mon avis tu as mis le doigt sur le problème. A partir du moment où tu es certain que le code utilisé est le même cela vient certainement de la configuration du serveur. Tu n'as pas moyen de passer en production une page qui affiche le phpinfo ? C'est curieux que le service informatique du client ne te le communique pas pour dissiper les doutes.

A part cela, le seul autre problème que je vois possible, c'est dans le code, des contrôles sur le nom de domaine lors de la création de la session (ou ailleurs dans le code) qui modifierait le comportement.

Bon courage

[Dadou]

Ben non le phpinfo pas autorisé sur le serveur de Prod, et puis avant de les appeler il faut que je sache un minimum d'où peut provenir le problème vu qu'ils affirment que les serveurs sont identiques.

De toute façon à l'heure qu'il est je vais devoir attendre demain pour les appeler.

[Kioob]

Et tu n'as pas accès tout simplement à ini_get ? :S Et le dossier de stockage des sessions (s'il s'agit d'un stockage fichier) ?

Sinon le backoffice est sur le même sous domaine ? Y a t'il un changement de protocole http / https entre le front et le back ?

=> il se pourrait que ce soit tout simplement les paramètres du cookie de session qui soient différents.

Comme pour tout je pense qu'il "suffit" de procéder par étape :

- déjà voir si le cookie de session est bien conservé lorsque l'on passe du front au back et vice versa

- puis voir si un après un session_start() le contenu a été conservé ou non

Sinon est ce le même "session handler" sur les deux ? Et est ce le même compte Unix pour les deux ?

[Dadou]

Ben non, malheureusement je suis très limité : pas d'accès à ini_get, tu penses, j'ai testé, le dossier de stockage des sessions, et bien aucune idée, la procédure de mise à jour est assez particulière : je publie sur le serveur de Publication, puis via une interface web, je lance la synchro avec le serveur de Prod.

Quand aux sessions, quand je passe du Front au Back elles sont gardées, par contre, quand je fais uniquement le back, pas gardée du tout.

Il n'y a pas de changement de protocole entre le Front et le Back, et ils sont sur le même domaine site : -www.site.com => -www.site.com/back

Pour le reste des questions, je saurais quoi leur poser demain matin

[Kioob]

Une possibilité dans ce cas serait que sur le front le cookie soit placé dans "/", et sur le back uniquement quand "/back". Ce qui expliquerait que le passage fonctionne dans un sens mais pas dans l'autre.

Et ça, tu peux facilement le vérifier directement avec les extensions de Firefox (la developperbar typiquement).

PS : chez nous aussi le passage en prod se fait via une interface web spécifique, qui lance le rsync "qui-va-bien", mais ça n'empêche pas d'y livrer n'importe quoi si on veut

[Dadou]

Et ça, tu peux facilement le vérifier directement avec les extensions de Firefox (la developperbar typiquement).

Arrrg, mais pourquoi je n'y ait pas pensé à celle la je testerais demain matin, l'admin n'accepte que les ip locale

[Dadou]

Voila, j'ai testé avec l'extension webdevelopper

- En passant par le Front, le cookie de session est bien créé, et bien gardée tout au long de la navigation.

- En passant par le Back, sur la Prod uniquement, le cookie de session n'est pas créé

ça commence à me gaver cette différence de conf

[cyberlaura]

Bonjour,

en créant un cookie, il faut spécifier un domaine. Il devrait donc y avoir un test selon le serveur pour spécifier le domaine sur lequel le cookie va se créer. Non ?

[Dadou]

Ce n'est pas un simple cookie qui est créé, mais un cookie de session avec session_start() donc de mon coté je ne peux rien spécifier.

[cyberlaura]

Et bien, d'après la doc, dans le php.ini, tu dois avoir session.use_cookies=1 , s'il est à zéro, pas de cookies, et plusieurs autres options, telle que session.cookie_domain ....

[Dadou]

Je n'ai pas accès au php.ini mais je suis sur que session.use_cookies est bien à 1 puisque quand on passe par le Front le cookie de session est créé

[cyberlaura]

Oui, je comprends mieux le problème. A ce moment là, ne peut-tu pas créer un simple fichier de test qui ne contienne que la ligne session_start(); que tu mettras dans le back afin de voir si le cookie est créé ? Et s'il te renvoie un SID.

[Dadou]

Le session_start() est la premiere commande de mon fichier, je viens de lui ajouter un print_r(session_id()), plus que 10 minutes à attendre

Edit : Même pas, j'ai bien un id de session

[xpatval]

heu, juste histoire de le dire, tu n'aurais pas un session_destroy() qui traîne quelque part...?

[Dadou]

Ben non, juste un unset mais uniquement pour le lien de déconnexion

[Kioob]

Mais le cookie de session, il a quelle tronche quand tu regardes les entêtes ? (Information => View Response Headers)

Parce que s'il n'est pas conservé quand tu passes du back au front, faut pas chercher plus loin ça ne peut pas fonctionner sans ça.

[Dadou]

C'est bon, ils ont fait quelque chose sur le serveur, ça fonctionne correctement (enfin, j'attends toujours l'info de leur part m'indiquant qu'ils ont corrigé le problème)

Maintenant, je les travaille au corps pour savoir quel était le problème (c'est que j'aime bien savoir pourquoi ça marche pas).

Sinon, en fait Kioob une fois créé la session fonctionnait partout que tu passe du front au back, puis de nouveau au front. C'était la création de la session directement depuis le back qui ne fonctionnait pas