Bonjour,

Encore une question sur les session via cookies ou url. Mais je pense que le problème n'a pas été traité (en tout cas, j'ai pas trouvé).

Je trace les logs de mes visiteurs sur toutes mes pages, sachant que les sessions sont utilisées.
Or, curieusement, dans mes logs, je constate que pour un même visiteur qui passe de page en page, parfois la session passe par cookie, parfois elle s'affiche dans l'url !

Pourtant, si j'ai bien compris le fonctionnement des sessions :
- Soit le visiteur accèpte les cookies, et la session passe par le cookie (rien ne passe dans l'url)
- soit le visiteur refuse les cookies, et la session passe par l'url (SESSIONID=...).

Mais pourquoi d'une page à l'autre, j'ai ou pas la session dans l'url ?

Ma config php
session.use_cookies On On
session.use_only_cookies Off
session.use_trans_sid On On

Merci de votre aide.

Bonjour,

Tu auras toujours les identifiants de session dans la première page que visite l'internaute. Ce n'est qu'à partir de la seconde page qu'il disparaît de l'URL.

Ceci explique la combinaison que tu trouves dans tes logs

Dan

Bonjour,



*Si* le use_trans_sid est activé (ce qui ne devrait jamais arriver, on ne le répetera jamais assez) PHP essaye tout seul de déterminer si le visiteur supporte ou pas les cookies pour savoir s'il fait passer l'identifiant de session par la chaîne de GET ou par un cookie.
Le problème c'est que les navigateurs n'annoncent pas à l'avance s'ils acceptent les cookies. Il n'y a qu'une seule possibilité d'auto-détermination pour PHP : Si un identifiant a été reçu par cookie il le renvoit par cookie, sinon si un identifiant a été reçu par GET ou POST il le renvoit via la chaîne de GET. Si aucun identifiant n'a été reçu on ne peut pas savoir ce que supporte ou pas le client, on lui envoie donc l'identifiant par les deux moyens la première fois, on restreindra la seconde suivant ce qu'on aura reçu.

Le résultat c'est que quel que soit le support des cookies, la première fois on ne peut pas savoir ce qui marche donc on envoie aussi par l'URL, même si ce n'est pas nécessaire.





Je te suggère fortement de mettre le "use_only_cookies" à On et le "use_trans_sid" à Off.

Le trans_sid à Off t'évitera :
- d'avoir à gérer la transmission des identifiants de session à la main à chaque fois que tu fais des URL de manière non classiques (paramètre d'applet, javascript, xmlhttprequest ..)
- d'avoir des divulgations et vols de session à cause de l'entête HTTP "referer" envoyée par les navigateurs
- d'avoir des URL imbitables et complexes à copier/coller, transmettre par oral ou envoyer via email pour tes visiteurs.

Le only_cookies à On te permettra d'éviter une énorme majorité des fixations de session ou au moins de compliquer la tache des méchants.


http://blog.dreams4net.com/SessionsIdentifiantsEtReferants
http://blog.dreams4net.com/SessionUseTransSid

Bonjour,

Juste une petite question


Dans ce cas là, comment traiter le cas des visiteurs qui ont désactivés le support des cookies ?

JP

Tout dépend de ce que tu veux faire.


Pour les statistiques tu as deux alternatives au marquage par cookie :
- l'utilisation d'un webbug qui se base sur les requêtes conditionnelles HTTP pour identifier de façon unique un client
- une bête aggrégation de toutes les requêtes venant d'une même ip publique, même ip source, même navigateur qui sont faites à moins de 30 min d'intervalle (ce n'est certes pas super précis mais c'est largement suffisant pour des statistique, de toutes façons le marquage par session n'est pas précis lui non plus dès que le visiteur utilise un proxy ou soft de type "respect de la vie privée")

Si c'est pour un login, une gestion des préférences ou un effet "mémoire" (type caddie ou boutique) la bonne question c'est se demander pourquoi le client a désactivé les cookies. Dans quasiment tous les cas c'est un power-user qui a choisit consciement de ne pas se laisser tracer. Dans ce cas là il refuse volontairement les sessions et faire passer l'identifiant dans l'URL c'est aller contre sa volonté. C'est rarement une bonne idée. Certes il risque de louper des fonctionnalités mais en général il sait ce qu'il risque, ou plutot ce qu'il veut. Certes il y a aussi des gens qui ne savent pas ce qu'ils font mais ils sont rares et pour eux la très grande majorité des sites de commerce ou institutionnels ne marcheront pas : il est déjà au courant qu'il y a problème chez lui et une page sur comment activer les cookies sera bien plus utile qu'un passage des identifiants dans l'URL.

Après il restera toujours des gens qui seront exclus si tu ne passes pas les identifiants dans l'URL. C'est à toi de voir jusqu'où tu veux pervertir ton modèle et ta sécurité pour des gens qui ont désactivé ou interdit le mécanisme justement fait pour ce que tu veux.
Tu en connais beaucoup des gens qui n'ont pas les cookies sans que cela soit fait exprès ?

Non, évidemment

Mais les sessions sont un moyen pratique de gestion des actions utilisateurs.

Pour des applications critiques, boutiques, login, panier... il est évident qu'interdire de passer la session dans l'url est une bonne idée.

En revanche, pour des gestions utilisateurs simples, comme par exemple d'utiliser une session pour stocker des valeurs de recherche ou simplifier une navigation de liste de résultat, le passage par l'url ne pose aucun problème.

Dans ce cas là, l'interdiction semble contre productive.

J'ai lu avec beaucoup d'intérêt tes deux articles, aurais tu un lien plus "pédagogique" vers la déclaration P3P qui sur celui que tu donnes, à la mode "MS-maitre du monde" est particulièrement difficile à comprendre ?

Jp

Ps: en passant félicitations pour PhP 5 avancé, dans le genre c un must

Là on sort de la technique pour passer dans l'opinion mais :
Si quelqu'un perd une valeur de recherche ou un ordre de tri de liste, une préférence, c'est par nature plus ou moins acceptable. Je ne veux pas dire que ce n'est pas gênant, mais si je la perd parce que c'est l'utilisateur refuse de stocker la chose, c'est son problème et plus le mien. S'il refuse les cookies il refuse la mémoire HTTP et c'est justement ça qu'il doit théoriquement avoir comme conséquence.
Vu le faible nombre qui refusent les cookies et le fait que la plupart d'entre eux savent ce qu'ils font et les implications au niveau des pertes, je juge que ce n'est pas à moi de dégrader quoi que ce soit (si c'était un manque de support et non une désactivation mon avis serait peut être différent).



http://blog.dreams4net.com/P3pEtFiltresDeCookies
http://www.yoyodesign.org/doc/w3c/w3c.html
http://www.p3ptoolbox.org/
Rien d'autre sur le P3P dans les cartons. J'avais fait ça plus en réponse à un fil de forum. A l'époque il n'y avait pas grand chose et je n'ai pas fouillé depuis.
En fait cette norme est à mon avis morte née. La seule chose qui reste utile sur ce sujet c'est la recette de cuisine pour passer le filtre MSIE. Tout le reste c'est une belle utopie et une des grandes illusions du W3C : Ca se base sur la bonne foi des déclarant. Sauf que dès que c'est utilisé pour faire du filtrage (quasiment l'unique exploitation que les gens trouveront utile) les développeurs vont mentir pour contourner le filtrage.




Merci, ça fait plaisir de voir qu'il est lu et apprécié.

Merci des liens,

Le web est plein d'utopies qui ne tiennent que sur la bonne foi des uns et des autres.
Celle là était intéressante mais tu à raison, à peine née déjà détournée, comme tant d'autres (qui à pensé au référencement ?)

Pour en revenir au fil, le hasard fait que je suis plongé dans cette problématique sur mon dev actuel, (c'est la raison pour laquelle j'ai envahis ce fil )

Toute la gestion utilisateur est monté sur une session, il n'y à rien de critique, ce sont des process simples de navigation, tri, recherche, consultation.

Cela faisais longtemps que je voulais tester une conception de ce genre sur des front-end et cette appli s'y prete à merveille, justement parce qu'il n'y à rien de critique.

Le confort de développement, de maintenance, la simplification extrème du code sont tellement profitables que la méthode classique par GET-Url-a-rallonge ou la surcharge de POST dans des séquencages de formulaires me semble du coup cauchemardesque.

Le soucis, évidemment, c'est que pas de cookie de session, pas de site

Du coup j'ai implémenté le passage manuel de SID par l'url pour résoudre ce conflit hors crawler et bestioles en tout genres.

Si j'ai bien compris le sens de ta réflexion, ce n'est pas vraiment une bonne idée et je devrais remplacer la béquille par un joli disclaimer au sujet de l'utilisation des cookies sur ce site, ou pour aller au bout du raisonnement laisser le power_user maitre de sa décision ?

C'est évidemment assez théorique car, comme tu le fais remarquer, la désactivation des cookies est relativement rare et que dans le cas de ce dev le vol de session n'à strictement aucune importance..

Dernières questions, purement techniques celles-là:
- use_only_cookies ON rendrait l'implémentation manuelle de SID innopérante ?
- c'est accessible par ini_set ?
(Je suppose que non mais j'ai pas eu le temps de tester, je suis en recettage ).

JP

Je me permet de sortir encore de la problématique initiale mais .. est-ce que réellement c'est une session qui est adaptée à ton cas ? Les processus de recherche de tri et de navigation ne gagnent pas forcément à passer en session. Il faut bien voir que ça empêche par exemple de faire deux recherches paralleles avec des paramètres différents. Or vouloir comparer deux recherches sans perdre le contexte d'une des deux n'a souvent rien de totalement fantasque.
Je ne connais pas ton application et ton contexte, mais ça peut être aussi une piste à réfléchir.





Tu "devrais" est peut être un peu fort. Disons que je pense qu'il faut éviter d'autoriser les identifiants de sessions dans l'URL si ce n'est pas absolument critique à cause d'un contexte particulier. Maintenant ce sont mes choix hein, d'autres ont des avis différents.
Moralement j'ai beaucoup moins de difficulté à retirer une fonctionalité à quelqu'un qui a refusé l'accès de son coté (cookie) qu'à quelqu'un qui n'a pas le choix (handicap quelconque par exemple). J'avoue que je considère que si quelqu'un refuse c'est son choix et plus mon problème, effectivement.



Ce qui veut dire que nul part dans ce site tu ne fais d'identification à l'aide de la session, tu ne stockes de données personnelles ... *et* que tu garantis que ça sera toujours ainsi (sinon tu risques une faille dans le futur si tu oublies ou si tu n'as pas le temps de tout refaire).



Oui et non. Ca désactive la lecture automatique des SID dans l'URL ou le corps de la requête lors d'un appel à session_start(). C'est effectivement fait pour empecher tout passage de SID ailleurs que dans les cookies.
Maintenant rien ne t'empêche de relire la valeur du SID dans $_REQUEST et l'amener manuellement à PHP via session_id(). Ceci dit dans ce cas ça revient à faire la même chose que PHP en t'exposant aux mêmes risques donc autant désactiver use_only_cookie.
PHP fait globalement bien le travail du passage du SID. Le problème ce n'est pas que PHP le fasse, c'est que ce soit possible

Concernant ini_set() je ne sais pas. Je présume que ça doit marcher si tu changes la valeur avant l'appel à session_start() (et donc que tu n'as pas de session.auto_start activé) mais ça demanderait vérification.

Bonjour à tous.

Quel succès ! Je passais par hasard devant mon post, quand j'ai vu 8 réponses. Bizarre, je n'ai pas reçu les mails de notification de réponse, alors que l'option est activée...

Bref, merci mille fois de vos réponses, elles sont parfaitement claires. Mais du coup, je pense qu'il n'y a pas d'autre option que de passer use_only_cookie à ON, car si les liens au départ de la page d'accueil contiennent systématiquement la session, adieu le référencement !

Je suis d'ailleurs d'accord avec le principe selon lequel quand les cookies sont là pour faciliter la navigation, si le visiteur les refuse, tant pis pour lui. Mais pour les fonctions panier, c'est quand même dommage...



Dois-je comprendre qu'avec le trans_sid à ON, les sessions ne passent pas si l'appel de la page se fait par du javascript ?
Et qu'entends tu par 'passer les session à la main' ? Je vais m'user la santé si je dois être derriere chaque visiteur

Autre question : J'ai une serie de pages qui s'affichent une iframe. Dans cette iframe,les pages se succèdent, avec passage de session.
Or je constate que la session passe systématiquement par l'url, jamais par cookie, et ce sur toutes les pages affichées dans l'IFRAME. (balises HREF ou formulaire POST, pas de JS). Pourtant les pages internes à l'IFRAME sont sur le même serveur que mes pages 'classiques', donc devraient suivre la même logique, non ?
Y a t il des particularités pour les IFRAME, je n'ai rien vu sur le sujet, et comme vous etes des puits de science, j'abuse, j'abuse



Je suis décidement un niais : c'est quoi un webbug ?

En tous cas merci de votre aide, ça me fait vraiment avancer !

Bye

Je pense que les principaux moteurs de recherche savent maintenant composer avec ça et ne pas prendre en compte le PHPSESSID. Il faudrait vérifier mais je suis sûr que les gens du forum référencement sauront ce qu'il en est si tu leur pose la question.




PHP gère tout seul les SID mais il n'est pas magique. Il reconnait les formulaire, les liens, les images .. à partir d'une série d'attributs/balises qu'il connait. La reconnaissance est très basique.
Ca ne marchera pas si tu utilises une balise peu courante, si tu t'amuses à modifier en javascript la cible de tes liens/formulaires/images/applets, ou encore si tu génère du contenu directement en javascript. (pas que PHP soit mal foutu mais il ne peut pas tout prévoir et analiser le js pour savoir ce que ça va faire à l'exécution)



Je te propose la lecture d'un article qui résume bien la question du tracking statistique et des possibilités avec PHP : http://frederic.bouchery.free.fr/?2005/02/...us-etes-traques

Tout à fais d'accord, c'est justement parce que le contexte et la logique applicative s'y pretent que j'en ai profité pour faire cette expérience.

En revanche je n'avais pas pensé à la répercussion de l'utilisation de session dans le cadre de processus parallèles (hors sujet dans ce projet mais merci pour la piste, je vais y réfléchir.)

Merci en tout cas de la richesse de tes réponses.

JP

Merci à tous pour les tuyaux.