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()) ?
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()) ?
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()) ?
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.
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.
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.
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.
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.
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.
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...
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...
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...
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 ?
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 ?
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.
Ç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.
Ç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.
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.
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.
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.
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.
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.
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.
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) ?
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) ?
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) ?
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...
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.
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.
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...
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.
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.
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...
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.
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.