Discussion :

[flo73]

Bonjour à tous,

Je rencontre un soucis pour le moins gênant dans le developpement php d'une application/site destinée à l'utilisation sur smartPhone.

J'utilise les sessions PHP pour authentifier un user et créer une commande de produits en ligne.

Tout fonctionne correctement lorsque je suis en Wifi avec mon smartPhone mais tout devient aléatoire dès lors que je passe en 3G / EDGE ou GPRS.

Après quelques recherches il s'avère que l'adresse IP en 3G/EDGE/GPRS change pratiquement à chaque changement de page. Ce qui a pour conséquence évidente: la perte de la session.

cf: http://forum.ovh.com/showthread.php?t=57607&page=2

La solution au problème est donc évoquée dans le lien ci-dessus.
Pour résumer, il suffit de passer le SID PHP de page en page via un champ caché de formulaire. (je souhaite éviter le passage de l'id par URL)

Mon problème est que je ne sais pas comment mettre en oeuvre le passage de l'id de session par des champs cachés.

Si quelqu'un à la possibilité de m'éclairer sur ce point, je suis preneur.

Merci par avance

[gene69]

je l'ai jamais fait mais la piste que j'utiliserai à ta place tentative de chargement d'un id de session eventuelement présent dans $_COOCKIES puis démarrage de la session.

aucune idée si ça marche.

[flo73]

Je ne suis pas certain qu'on puisse justement lire les cookies de session.

Une solution plus propre m'oriente vers le stockage en base mysql.

Mais encore pareil, je ne sais pas comment procéder...

Quelqu'un a-t-il déjà réalisé ceci?

Merci beaucoup

[gene69]

entendons nous bien.
Les coockies de session sont des fichiers sur ton serveur, c'est $_SESSION et dans le cas d'espèce tu n'y a pas accès à cause de l'ip changeante. tu n'y a pas acces non pour un probleme de droits mais pour un probleme de hashage des identifiant;

les coockies (les vrais, les délicieux délices) sont stockés dans le navigateur du visiteur et ils sont systématiquement transmit par le naviagateur. c'est $_COOCKIES.

Le mécanisme des $_SESSION c'est un fichier sur ton serveur, identifié par un nom unique, qui contient la version serialisée de $_SESSION. pas exactement serialize($_SESSION) mais c'est tout comme.

quand tu utilises session_start(), php

1. va chercher dans sa conf le nom du cookie de session (par défaut PHPID)
2. cherche si isset($_COOCKIES['PHPID']) et si il existe un fichier dont le nom est contenu dans $_COOCKIES['PHPID'] sur le serveur et apparament vérifie que le nom de fichier est compatible avec l'adresse ip du visiteur.( doit y avoir une sorte de chiffre, je ne sais pas le détail, je n'ai jamais eu besoin de m'y pencher.)
3. s'il trouve ses petits, php désérialise le fichier de session dans $_SESSION
4. s'il ne trouve pas ses petits, il envoie une entete spéciale dans la page pour dire qu'il crée un nouveau $_COOCKIES['PHPID'] (je veux dire chez le visiteur, qui lui rajoutera les informations liées à l'identité du site)
5. à la fin du script php reserialise $_SESSION et met à jour le fichier sur le serveur.

dans ton cas, si $_COOKIES est conservé lors de la navigation avec smartphone, ya bon, tu peux forcer la lecture de l'identifiant du fichier de session (serveur) avec des choses comme session_id(string). Au lieu d'utiliser la fonction par défaut utilise la tienne et tu seras sauvé. Cette fonction devra prendre autre chose que l'ip/port du visiteur comme entree.

si tu n'as pas $_COOCKIES du tout... difficile.
alors tu vas être obligé d'utiliser un block de temporisation de sortie ob_start()/ob_get_clean() pour réécrire ta page ( expressions régulieres nous voilà ) en concatenant à postériori une variable &PHPID=kfjsdkljfslk à toute tes url.
( cad '#src="(.*)"|href="(.*)"#i'|action="(.*) ) en faisant gaffe à tellement de truc (genre les ancres... )

est-ce qu'il y a plus simple, je ne sais pas. Lorsqu'on ne peut pas utiliser les mécanismes par défaut d'un language, faut pas s'étonner de rentrer dans de la complexité.

Je ne comprends pas en quoi la base de donnée qui sera derriere le serveur http "verra" mieux le client que le serveur http.

[flo73]

Merci pour ces précisions....

Le but de la manoeuvre est de générer un id de session à la connexion de l'utilisateur, de l'enregistrer en base et de s'en servir tout au long de sa session. On supprime l'entrée en base dès la fin de la session.

On force ainsi l'user à conserver son id de session même si son ip change entre chaque page.

Mon problème réside dans la manière de lire cet id en base.

Je tourne en rond.

Je sais que ceci est possible mais je n'arrive pas à le mettre en place.

Merci beaucoup pour votre aide

[flo73]

Bonjour,

si ça peut servir à quelqu'un, voici comment j'ai contourné le problème:
(stockage de la session sur mon serveur)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
session_save_path($_SERVER['DOCUMENT_ROOT']."/../Sessions"); //stockage de la session vers repertoire Sessions au même niveau que www
session_set_cookie_params(0, '/', '.domaine.com'); //permet de fonctionner en domaine.com et www.domaine.com
session_name('membre'); //on définit le nom de la session
session_start();

[RunCodePhp]

Le but de la manoeuvre est de générer un id de session à la connexion de l'utilisateur, de l'enregistrer en base et de s'en servir tout au long de sa session. On supprime l'entrée en base dès la fin de la session.

On force ainsi l'user à conserver son id de session même si son ip change entre chaque page.

Oui et non je dirais.

Par rapport au problème que tu évoque, et apparemment selon le lien tu n'est pas le seul, c'est que le fond du problème c'est qu'au niveau de la gestion des session faite par défaut en Php, et bien une nouvelle session serait automatiquement accordée si l'IP change.

Ce n'est pas le type de stockage qui est en cause finalement.

La solution proposée est de faire en sorte que ce ne soit plus automatique, mais de gérer soit les sessions.
Php offre tout ce qu'il faut pour le faire soit même, ça repose en très grande partie sur la fonction session_set_save_handler().
La doc : session_set_save_handler


Dans ce cas là, on devras soit même parcourir les fichiers de session (ou interroger la Bdd peu importe), et récupérer la session selon certains critères.
Que l'IP soit la même ou pas ne devrait donc plus être une restriction.


Maintenant, j'admets que gérer les sessions soit même dans la Bdd (donc plus du tout dans des fichiers) offre pas mal de possibilités, plus que ne le permet les fichiers.

Maintenant, faut peut être se poser la question si récupérer une session selon un cookie quelque soit l'IP ne serait pas un manque de sécurité.
Personnellement je n'est pas la capacité à répondre à cette question.


Question comme ça.
As tu fais des essai pour au moins être certain que le navigateur renvoi au moins un cookie ?

[RunCodePhp]

si ça peut servir à quelqu'un, voici comment j'ai contourné le problème:
(stockage de la session sur mon serveur)

Je n'avais pas fais attention à ta réponse.

Je ne parviens pas à comprendre pourquoi le simple fait de mettre le répertoire de session dans son espace d'hébergement éliminerait ce problème d'IP ?

Ca serait finalement pas un problème d'IP, non ?
Un problème de droit plus restrictif quand c'est géré dans le répertoire par défaut peut être ?

Bon, de toute manière tant mieux si ceci résout le problème.

[gene69]

c'est terrible parce dans ce que tu flo73 écrit, la distinction entre les sessions et les coockies est pas évidente. Va falloir que tu travailles tout ça.

Mettre la session dans la base de donnée n'apporte à mon avis une plus-value que limité, sauf à avoir énormément de visiteurs, et faire du load-balancing entre deux serveurs fronteaux. Ci ya des cas d'utilisation plus évidents je suis preneur, envoyez les liens !!!

M'enfin, Flo73, si ça marche ton systeme...

[RunCodePhp]

Ci ya des cas d'utilisation plus évidents je suis preneur, envoyez les liens !!!

Désolé, mais c'est un peu la dictature comme raisonnement.


Et le plaisir de coder, d'apprendre, etc ..., c'est pas suffisant comme raison ?
Par contre, j'ai pas de lien à te proposer ... j'ai moi même du mal à savoir d'où vient ce plaisir en question.

[flo73]

Je n'avais pas fais attention à ta réponse.

Je ne parviens pas à comprendre pourquoi le simple fait de mettre le répertoire de session dans son espace d'hébergement éliminerait ce problème d'IP ?

Ca serait finalement pas un problème d'IP, non ?
Un problème de droit plus restrictif quand c'est géré dans le répertoire par défaut peut être ?

Bon, de toute manière tant mieux si ceci résout le problème.

J'ai peut-être oublié d'insister sur le fait que mon serveur est un mutualisé chez OVH: ce qui suit est donc applicable dans mon cas:

Nous avons tous constaté que la 3G passe par un proxy et que l'IP du visiteur change aléatoirement d'une page à l'autre.
En mutu c'est un cluster qui gère la répartition des requêtes vers les stockages appropriés, le cluster peut nous balader d'un serveur à l'autre pour équilibrer les charges surtout si on change d'IP entre chaque requête. Nous ignorons chez la plupart des hébergeurs "low cost" la solution choisie pour gérer les sessions (séparément sur chaque serveur, groupées sur un /temp commun... ?), dans la plupart des cas c'est l'adresse IP du visiteur qui est utilisée pour restituer à chacun sa session. Chez OVH lorsqu'on change d'IP la session persiste (session ID) mais les variables ne suivent pas, mais si le proxy vous réattribue une IP précédente, hop !! vous retrouvez vos variables de sessions. Galère !!!

STOCKEZ VOS SESSIONS CHEZ VOUS et tout rentre dans l'ordre