Modifier une session a partir de son id

Le
Julien Arlandis
Bonjour,

Connaissez vous un moyen d'accéder aux variables de session de n'importe
quel utilisateur à partir de son id de session (session_id()) ?
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Mickael Wolff
Le #23002351
On 08/01/11 21:06, Julien Arlandis wrote:
Bonjour,

Connaissez vous un moyen d'accéder aux variables de session de n'importe
quel utilisateur à partir de son id de session (session_id()) ?



Ça dépend de ton backend. Si tu utilises le backend par défaut de
PHP, il suffit d'ouvrir le fichier contenant la session (ça dépend de la
configuration du module de session et des options de compilation de
PHP). Sinon, il faut regarder la documentation liée au backend que tu
utilises.
Julien Arlandis
Le #23003671
Le 08/01/2011 22:59, Mickael Wolff a écrit :
On 08/01/11 21:06, Julien Arlandis wrote:
Bonjour,

Connaissez vous un moyen d'accéder aux variables de session de n'importe
quel utilisateur à partir de son id de session (session_id()) ?



Ça dépend de ton backend. Si tu utilises le backend par défaut de PHP,
il suffit d'ouvrir le fichier contenant la session (ça dépend de la
configuration du module de session et des options de compilation de
PHP). Sinon, il faut regarder la documentation liée au backend que tu
utilises.



Effectivement, dans ma config chaque session est stockée dans un fichier
situé dans /var/lib/php/sess_+session_id , mais existe t-il des outils
pour manipuler ces fichiers ?

statut|s:11:"A la maison";id|s:1:"1";actif|b:1;group|s:3:"999";
check|i:78578930;

Le format semble être le suivant :
nom_variable + '|' + caractère parmi {b(oolean), i(nteger), s(tring),
...} + valeur + 'n'. Pas très sympathique à manipuler...
Jean-Francois Ortolo
Le #23004121
Le 08/01/2011 22:59, Mickael Wolff a écrit :
On 08/01/11 21:06, Julien Arlandis wrote:
Bonjour,

Connaissez vous un moyen d'accéder aux variables de session de n'importe
quel utilisateur à partir de son id de session (session_id()) ?



Ça dépend de ton backend. Si tu utilises le backend par défaut de PHP,
il suffit d'ouvrir le fichier contenant la session (ça dépend de la
configuration du module de session et des options de compilation de
PHP). Sinon, il faut regarder la documentation liée au backend que tu
utilises.




Bééééééhhhhhh....

Cà veut dire qu'un site comportant des accès par login/password, doit
nécessairement crypter la ou les données certifiant l'authentification
d'un abonné ? Et ce cryptage doit nécessairement dépendre de données
propres à chaque abonnés, pour être efficace ?

Merci beaucoup de l'info, celà confirme des indications que j'avais
lues il y a plusieurs mois sur la façon de certifier l'authentification
d'un abonné.

Encore faut-il avoir l'id de session, mais le post initial fait comme
si ce problème était déjà résolu...

Bien à vous.

Amicalement.

Jean-François Ortolo

--
Visitez mon site gratuit donnant des Statistiques,
des Pronostics et des Historiques Graphiques
sur les Courses de Chevaux:
http://www.pronostics-courses.fr
Mickael Wolff
Le #23005861
On 09/01/11 13:11, Julien Arlandis wrote:
statut|s:11:"A la maison";id|s:1:"1";actif|b:1;group|s:3:"999";
check|i:78578930;

Le format semble être le suivant :
nom_variable + '|' + caractère parmi {b(oolean), i(nteger), s(tring),
...} + valeur + 'n'. Pas très sympathique à manipuler...



Le format est décrit ici :
http://php.net/manual/fr/language.oop5.serialization.php
Mickael Wolff
Le #23005871
On 09/01/11 14:39, Jean-Francois Ortolo wrote:

Cà veut dire qu'un site comportant des accès par login/password, doit
nécessairement crypter la ou les données certifiant l'authentification
d'un abonné ? Et ce cryptage doit nécessairement dépendre de données
propres à chaque abonnés, pour être efficace ?



Ça dépend. Si tu es en hébergement mutualisé, selon les options de
configuration de PHP, tu peux avoir accès aux fichiers de session des
colocataires. Dans ce cas, il y a un risque certain de compromission des
données.

Celà dit, le mécanisme de session est destiné à fournir un mécanisme
d'état que HTTP ne fourni pas. Les mots de passe n'ont donc pas de
raison d'être dans les sessions.

Et enfin, chiffrer la session, en sachant que la serialisation des
données ajoute déjà un overhead non-négligeable, n'est pas forcément
pertinent.
Pascal
Le #23008441
Le 10/01/2011 11:23, Mickael Wolff a écrit :
Ça dépend. Si tu es en hébergement mutualisé, selon les options de
configuration de PHP, tu peux avoir accès aux fichiers de session des
colocataires. Dans ce cas, il y a un risque certain de compromission des
données.



Sérieusement ?
Il y aurait encore des hébergeurs avec des configs à la noix qui
permettraient ce genre de hacking ?
Si tu as des sources d'infos, je suis preneur.


--
Cordialement,
Pascal
Julien Arlandis
Le #23012001
Le 10/01/2011 11:23, Mickael Wolff a écrit :
On 09/01/11 14:39, Jean-Francois Ortolo wrote:

Cà veut dire qu'un site comportant des accès par login/password, doit
nécessairement crypter la ou les données certifiant l'authentification
d'un abonné ? Et ce cryptage doit nécessairement dépendre de données
propres à chaque abonnés, pour être efficace ?



Ça dépend. Si tu es en hébergement mutualisé, selon les options de
configuration de PHP, tu peux avoir accès aux fichiers de session des
colocataires. Dans ce cas, il y a un risque certain de compromission des
données.

Celà dit, le mécanisme de session est destiné à fournir un mécanisme
d'état que HTTP ne fourni pas. Les mots de passe n'ont donc pas de
raison d'être dans les sessions.



Bonjour,

Pour ma part je considère les sessions comme un mécanisme de mémoire
tampon consistant à dupliquer certaines données utilisateurs stockées
dans la base de données qui sont très sollicitées par les scripts, afin
d'économiser des connexions et des requêtes vers la base. Mais est ce
que l'accès en lecture d'une variable de session est plus rapide qu'un
simple select sur une table indexée, c'est ce que j'ai toujours
inconsciemment pensé mais n'ayant jamais fait de mesure peut être que
cette hypothèse est erronée sous certaines conditions. En particulier
quand la BD est hébergée sur le même serveur que php, le gain de
performance est il réel? Au sujet de la connexion à la base, est il
possible que les scripts se partagent la même connexion pour économiser
les authentifications (j'utilise PDO) ?
Mickael Wolff
Le #23012431
On 11/01/11 08:46, Pascal wrote:
Sérieusement ?
Il y aurait encore des hébergeurs avec des configs à la noix qui
permettraient ce genre de hacking ?
Si tu as des sources d'infos, je suis preneur.



C'est pour ce genre de raisons qu'il faut tester son hébergeur, et ne
pas hésiter à changer lorsqu'on trouve quelque chose de bizare. Pour ce
que ça coûte un hébergement mutualisé.
Tout les hébergeurs n'ont pas les moyens ou les compétences pour
configurer correctement un hébergement mutualisé. Ou encore, ceci peut
ne pas faire partie de la politique de sécurité. En hébergement
mutualisé, tu sais que tu partage un même processus (et donc un même
utilisateur) avec d'autres clients. À partir de là, il ne faut pas
s'attendre à une parfaite étanchéité.
Mickael Wolff
Le #23012441
On 11/01/11 21:42, Julien Arlandis wrote:

Pour ma part je considère les sessions comme un mécanisme de mémoire
tampon consistant à dupliquer certaines données utilisateurs stockées
dans la base de données qui sont très sollicitées par les scripts, afin
d'économiser des connexions et des requêtes vers la base.



La session n'est pas un système de cache.
C'est un détournement du mécanisme standard des sessions. Une session
est l'ensemble des données relatives à l'état de ton application. Par
exemple, les tokens pour les formulaires, le modèle en cours de
modification ou création (par exemple, une ressource créée à travers
plusieurs formulaires, la sauvegarde automatique temporaire d'un
article, etc).
Lorsqu'on utilise les sessions en base de données, ça va
difficilement réduire les appels à la base de données.
Cette optimisation a priori peut avoir des effets désastreux. Le
back-end par défaut utilises des fichiers sur la machine qui héberge le
processus Apache ou PHP CGI. Ce qui signifie qu'on augmente les IO sur
le disque du serveur qui sert l'application. On sait que l'un des
principaux goulets d'étranglement des applications web est les IO disque
sur le serveur web. C'est pour ça qu'il existe d'autres backend pour les
sessions (Memcache, MySQL, etc). Pour peut que la session soit
lourdement utilisée comme cache applicatif, les serveurs peuvent
s'effondrer sous une forte charge.

Mais est ce que l'accès en lecture d'une variable de session est plus rapide qu'un
simple select sur une table indexée,


Comme toujours en informatique, dans les systèmes complexes : ça
dépend :o)

c'est ce que j'ai toujours
inconsciemment pensé mais n'ayant jamais fait de mesure peut être que
cette hypothèse est erronée sous certaines conditions.


Utiliiser une optimisation sans faire de tests n'est pas une bonne
initiative. Ceci dit, c'est difficile de faire des tests de performance.
Je ne te jeterai pas la première pierre ;)

En particulier quand la BD est hébergée sur le même serveur que php, le gain de
performance est il réel?


Il faut tester. Mais il ne faut pas oublier d'inclure le temps
d'initialisation de la session. La déserialisation des données n'est pas
gratuite.

Au sujet de la connexion à la base, est il
possible que les scripts se partagent la même connexion pour économiser
les authentifications (j'utilise PDO) ?


Dans un même script, une connexion sera unique (tout au moins avec
MySQL). C'est un comportement qui est géré par l'extension.
La connexion à la base de données peut être mutualisée entre les
différents appels à la base de donnée. On peut activer cette
fonctionnalité en utilisant une connexion permanente. *Mais* en
hébergement mutualisé, c'est généralement désactivé. La raison est que,
si tu a 10 000 clients qui conservent une connexion permanente vers la
base de donnée-- ça peut être quelque peu insoutenable. Il ne faut pas
non plus oublier que MySQL resterait aussi à l'écoute, ce qui signifie
qu'il doit aussi allouer des ressources à la connexion permanente. En
fait, les connexions permanentes sont déconseillées sur les systèmes
fortement sollicités. Désactiver Keep Alive sur Apache peut sauver un
serveur du passage à lighttpd.

Il n'y a pas de réponse générale. Il faut tester et s'adapter au
besoins de l'application (ou du site).
Julien Arlandis
Le #23014941
Le 12/01/2011 07:07, Mickael Wolff a écrit :
On 11/01/11 21:42, Julien Arlandis wrote:

Pour ma part je considère les sessions comme un mécanisme de mémoire
tampon consistant à dupliquer certaines données utilisateurs stockées
dans la base de données qui sont très sollicitées par les scripts, afin
d'économiser des connexions et des requêtes vers la base.



La session n'est pas un système de cache.
C'est un détournement du mécanisme standard des sessions. Une session
est l'ensemble des données relatives à l'état de ton application...



... et à une connexion donnée. Par exemple, si on veut partager une
donnée propre à l'application (comme le nombre de visiteurs) il ne me
semble pas que l'on puisse utiliser l'objet $_SESSION dans ce cas,
quelle serait la solution appropriée dans ce cas?


Par
exemple, les tokens pour les formulaires, le modèle en cours de
modification ou création (par exemple, une ressource créée à travers
plusieurs formulaires, la sauvegarde automatique temporaire d'un
article, etc).
Lorsqu'on utilise les sessions en base de données, ça va difficilement
réduire les appels à la base de données.



Par exemple si on veut afficher le prénom de l'utilisateur sur chaque
page du site, une solution serait de stocker le prénom en session à
chaque authentification de l'utilisateur. Dans ce cas l'appel à la base
de données ne se fait qu'une seule fois : lors de l'authentification.


En particulier quand la BD est hébergée sur le même serveur que php,
le gain de
performance est il réel?


Il faut tester. Mais il ne faut pas oublier d'inclure le temps
d'initialisation de la session. La déserialisation des données n'est pas
gratuite.



Quand PHP et Mysql sont sur le même serveur, n'est il pas possible de
supprimer la phase d'authentification étant donné que je suis seul à
exploiter la base sur mon serveur dédié? Et peut on utiliser les sockets
unix dans ce cas pour faire l'économie de TCP/IP qui doit quand même
alourdir la charge?
Publicité
Poster une réponse
Anonyme