[PHP 5.3] Sessions - bonnes pratiques pour un débutant

[totale_eclipse]

Hello tout le monde.

J'ai hésité à poster dans la rubriques "Sessions" mais vu que je suis débutant ....

Je développe à mes heures perdues (ce n'est pas ma profession) et on a fait appel à moi en catastrophe pour développer une petite interface web pour environ 500 utilisateurs (enregistrement de données en base, restitution ....)

Je ne suis pas un pro et je suis donc face à une grande responsabilité

Vous me direz : qui est assez fou pour faire appel à un amateur pour développer un site pour 500 utilisateurs ?

Pour l'instant j'ai développé cette petite interface en local sous la plateforme wampserver.
Et je me pose la question de la gestion des sessions.
Tous les utilisateurs sont connectés dans le même LAN.

J'ai peur qu'il y ait des conflits de sessions ou tout autre type de tracas lié à la connexion simultanée de plusieurs utilisateurs.

Pouvez-vous m'indiquer quelles les règles de bases à respecter et les actions à mener pour que les choses soient faites proprement ?

je vous explique quand même rapidement le principe d'identification que j'ai mis en place :
Il n'était pas question de faire gérer aux utilisateurs des id/passw
Chaque utilisateur recevra donc un mail personnalisé avec l'url d'accès dans laquelle est passée en paramètre une clé cryptée (différente et unique pour chaque utilisateur) et que je récupère ensuite en GET.

Je vérifie ensuite que cette clé est valide et je la stocke ensuite en session et je vérifie régulièrement côté serveur que la variable session associée à cette clé est non vide sinon --> déconnexion
Je précise que je n'utilise pas les cookies (peut-être devrais-je ?)

Voilà je voulais donc savoir qu'elles sont les règles de bases à adopter pour faire les choses correctement, je reprécise que tous les utilisateurs sont dans le même LAN.

Merci d'avance pour vos réponses.

[Benjamin Delespierre]

J'ai peur qu'il y ait des conflits de sessions ou tout autre type de tracas lié à la connexion simultanée de plusieurs utilisateurs.

Pas de souci, l'identification de la session se fait avec un token (une chaine de caractère incompréhensible) qu'il est d'ailleurs possible de manipuler manuellement.
Cet identifiant de session (ou SID) transite entre le navigateur de l'utilisateur et le serveur soit par paramètre sur URL soit (par défaut) par cookie.
C'est donc au navigateur qu'est liée la session et non à l'ip.
Même si tu ne fais pas d'authentification au sens login / password, la réception d'un paramètre sur $_GET pour identifier un utilisateur lance bien un session_start non ? Si c'est ça tu n'as rien d'autre à faire.

Je précise que je n'utilise pas les cookies (peut-être devrais-je ?)

Tu en est sûr ? Regarde ce qui se passe au niveau des requêtes HTTP quand tu navigue sur le site avec une session ouverte (tu peux regarder ce genre de chose avec un plugin firefox comme Firebug).

[totale_eclipse]

Merci Benjamin,

oui j'ai bien commencé par un session_start.

J'ai regardé les requêtes http (avec entête http direct et non firebug )
et j'ai des lignes du type : Cookie: PHPSESSID=jbhos6fmdr2oqmo01pu00d9nc2
c'est de çà que tu parles ?
Mais çà c'est un fichier créé sur le serveur, non ?

Je faisais plutôt allusion aux cookies sur le poste client, si cela peut servir à quelque chose de les utiliser dans mon cas .....
(ps : comme tu peux le voir, j'ai des lacunes sur les fondamentaux, il y a des notions que je devrais approfondir )

En fait ma crainte est d'avoir 2 (ou plusieurs) utilisateurs connectés en même temps et qui s'échangeraient leurs données sans le savoir.
Les techniciens dans ma boîte ont mis en place un système de timestamp car ils avaient rencontré ce type de problème quand 2 utilisateurs étaient connectés derrière le même proxy et comme dans mon cas les 500 utilisateurs sont dans le même LAN et que mon appli sera hébergée à l'exterieur du LAN, voilà pourquoi j'ai peur ...

Merci encore pour ton aide.

[stealth35]

les sessions marche par client, y'a un cookie de sessions coté client, et un fichier de sessions par client coté serveur, le cookie de sessions contient uniquement le hash de sessions

[christele_r]

Bonjour,
Passer une cle (id) de session en GET n'est pas souhaitable.
Par ailleur il faut te dire qu'il existe par nom de domaine ou adresse intranet,
deux cookies
Le cookies de données ou tu mets ce que tu veux et qui est permanant si tu le souhaites, par exemple 1 ans ...
Le cookies de session se crées automatiquement sur le micro d' un des 500 users. il contient par exemple "lkjqkjllj454569qsxsx!!ppoosisisisikk"
id de session d'un visiteur.
Ton serveur, ou qu'il soit a créé en même temps un fichier texte
lkjqkjllj454569qsxsx!!ppoosisisisikk.txt
qui va comprendre toutes les données du visiteur.
La fin de vie de base du fichier texte (même s'il reste souvent présent)
est de 15/20 minutes sans activitée du visiteur
Le cookies de session lui meurt dés que le visiteur ferme son navigateur.
(je n' ais pas dit quitte le site !)
Voila tu y vois plus clair j' espéres.

[stealth35]

Envoyé par mauriser

La fin de vie de base du fichier texte (même s'il reste souvent présent)
est de 15/20 minutes sans activitée du visiteur
Le cookies de session lui meurt dés que le visiteur ferme son navigateur.
(je n' ais pas dit quitte le site !)

t'es sur de toi ?

[totale_eclipse]

Envoyé par mauriser

Bonjour,
Passer une cle (id) de session en GET n'est pas souhaitable.
Par ailleur il faut te dire qu'il existe par nom de domaine ou adresse intranet,
deux cookies
Le cookies de données ou tu mets ce que tu veux et qui est permanant si tu le souhaites, par exemple 1 ans ...
Le cookies de session se crées automatiquement sur le micro d' un des 500 users. il contient par exemple "lkjqkjllj454569qsxsx!!ppoosisisisikk"
id de session d'un visiteur.
Ton serveur, ou qu'il soit a créé en même temps un fichier texte
lkjqkjllj454569qsxsx!!ppoosisisisikk.txt
qui va comprendre toutes les données du visiteur.
La fin de vie de base du fichier texte (même s'il reste souvent présent)
est de 15/20 minutes sans activitée du visiteur
Le cookies de session lui meurt dés que le visiteur ferme son navigateur.
(je n' ais pas dit quitte le site !)
Voila tu y vois plus clair j' espéres.

Merci pour ta réponse.
Oui je suis convaincu qu'il serait préférable d'identifier les utilisateurs par un id et un pwd, mais là une des contraintes que l'on m'a imposée est de ne pas obliger les utilisateurs à gérer des id/pwd, j'ai donc opté pour une clé propre à chacun (clé que j'ai complexifiée)

Donc au final si je comprends bien, je n'ai pas de souci à me faire, j'ai fait tout ce qu'il fallait ?

[christele_r]

Envoyé par stealth35

t'es sur de toi ?

Oui c' est du moins la régle de base,
mais sur quel point as-tu un doute

[stealth35]

Envoyé par mauriser

Oui c' est du moins la régle de base,
mais sur quel point as-tu un doute

oui "de base", faut bien préciser que c'est pas forcement le cas, une session peu rester autant de temps que l'on souhaite sur le serveur ( comme son cooki ).
pareil pour le gc par défaut c'est 24 min mais cette valeur peu être modifié

[christele_r]

Envoyé par stealth35

oui "de base", faut bien préciser que c'est pas forcement le cas, une session peu rester autant de temps que l'on souhaite sur le serveur ( comme son cooki ).
pareil pour le gc par défaut c'est 24 min mais cette valeur peu être modifié

Exactement l'Ami, mais totale_eclipse ayant précisé étre trés débutant, je ne penses pas qu'il ait modifiers les paramétres par défault

[totale_eclipse]

Envoyé par mauriser

Exactement l'Ami, mais totale_eclipse ayant précisé étre trés débutant, je ne penses pas qu'il ait modifiers les paramétres par défault

oui je n'ai pas touché au gc_maxlifetime, je l'ai laissé 1440sec
d'ailleurs vous me confirmez que ça correspond bien à la durée max de la session sans activité ? c'est bien çà ?

[stealth35]

Envoyé par totale_eclipse

oui je n'ai pas touché au gc_maxlifetime, je l'ai laissé 1440sec
d'ailleurs vous me confirmez que ça correspond bien à la durée max de la session sans activité ? c'est bien çà ?

si le temps de la session est à 0 (ce qui correspond a la fermeture du site), oui