Je veux utilisé ules sessions pour faire une zone privée j'ai qq questions au
sujet des sessions alors si vous voulez bien y répondre :
Lorsque je créais une session celle si est propre à chaque utilisateur, et si
j'ai 10 personnes en zone privée j'ai dix session ?
La session créé est valable combien de temps comment définir la durée ?
Pour vérifier qu'une personne est logé je fais un test pour savoir si'il existe
une session ouverte ? comment faire cette vérification ? en vérifiant que l'id
(session.id) correspond avec une variable que je transmet dans l'URL ?
Quel est l'id de session id créé par défaut lors d'une session.start ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Guillaume Bouchard
Gypaete.net wrote:
Lorsque je créais une session celle si est propre à chaque utilisateur, et si j'ai 10 personnes en zone privée j'ai dix session ?
Autant de session que d'utilisateurs.
La session créé est valable combien de temps comment définir la durée ?
Si tu fais des session a la main, le temps que tu veux. Si c'est les session php4 que je te deconseille, elle est valable pendant session.gc_maxlifetime du php.ini, réglable via .htaccess, ini_set ou modification direct du php.ini
Pour vérifier qu'une personne est logé je fais un test pour savoir si'il existe une session ouverte ? comment faire cette vérification ? en vérifiant que l'id (session.id) correspond avec une variable que je transmet dans l'URL ?
Si l'on se base sur le fait que tu utilise les session php. Lors de la connexion, tu a stocker dans la session une preuve que l'utilisateur est logué, un flag logué. Il te suffit de tester l'existence de ce flag pour savoir si ton utilisateur est logué. if(isset($_SESSION['flag']))...
Quel est l'id de session id créé par défaut lors d'une session.start ?
Il est aleatoire, il n'y en a pas par defaut.
-- Guillaume.
Gypaete.net wrote:
Lorsque je créais une session celle si est propre à chaque utilisateur, et si
j'ai 10 personnes en zone privée j'ai dix session ?
Autant de session que d'utilisateurs.
La session créé est valable combien de temps comment définir la durée ?
Si tu fais des session a la main, le temps que tu veux.
Si c'est les session php4 que je te deconseille, elle est valable
pendant session.gc_maxlifetime du php.ini, réglable via .htaccess,
ini_set ou modification direct du php.ini
Pour vérifier qu'une personne est logé je fais un test pour savoir si'il existe
une session ouverte ? comment faire cette vérification ? en vérifiant que l'id
(session.id) correspond avec une variable que je transmet dans l'URL ?
Si l'on se base sur le fait que tu utilise les session php. Lors de la
connexion, tu a stocker dans la session une preuve que l'utilisateur est
logué, un flag logué. Il te suffit de tester l'existence de ce flag pour
savoir si ton utilisateur est logué. if(isset($_SESSION['flag']))...
Quel est l'id de session id créé par défaut lors d'une session.start ?
Lorsque je créais une session celle si est propre à chaque utilisateur, et si j'ai 10 personnes en zone privée j'ai dix session ?
Autant de session que d'utilisateurs.
La session créé est valable combien de temps comment définir la durée ?
Si tu fais des session a la main, le temps que tu veux. Si c'est les session php4 que je te deconseille, elle est valable pendant session.gc_maxlifetime du php.ini, réglable via .htaccess, ini_set ou modification direct du php.ini
Pour vérifier qu'une personne est logé je fais un test pour savoir si'il existe une session ouverte ? comment faire cette vérification ? en vérifiant que l'id (session.id) correspond avec une variable que je transmet dans l'URL ?
Si l'on se base sur le fait que tu utilise les session php. Lors de la connexion, tu a stocker dans la session une preuve que l'utilisateur est logué, un flag logué. Il te suffit de tester l'existence de ce flag pour savoir si ton utilisateur est logué. if(isset($_SESSION['flag']))...
Quel est l'id de session id créé par défaut lors d'une session.start ?
Il est aleatoire, il n'y en a pas par defaut.
-- Guillaume.
Guillaume Bouchard
Christian wrote:
Ici même, Guillaume Bouchard a écrit tantôt :
Si c'est les session php4 que je te deconseille (...)
Suit les liens ( nottament qui pointe vers le blog de Ganf) et tu auras la totalité de la reponse.
-- Guillaume.
John GALLET
Bonjour,
Si c'est les session php4 que je te deconseille (...) Pourquoi donc ?
Réponse rapide : c'est surtout une question d'habitudes et de contraintes de l'application. Pour quelqu'un qui prend le train en marche avec PHP4, pourquoi pas. Pour quelqu'un qui a déjà écrit les deux fonctions et trois requêtes SQL nécessaires à gérer des sessions manuellement, ça ne sert à rien.
Un exemple bête de l'inconvénient des sessions natives PHP : tu veux savoir quel est le "nombre de connectés" (comprendre : personnes distinctes ayant fait une requête sur le site il y a moins de 10 minutes par exemple). Vas essayer de faire ça avec des sessions natives PHP4, on en reparlera. Si tu as une table dans un SGBD, il suffit de faire un COUNT avec une clause WHERE sur la colonne heure d'expiration... Tu veux logguer toutes les sessions qui partent en time out : impossible. En SGBD, il suffit de faire un SELECT avant le DELETE (oui, on peut avoir un petit problème de transactions, c'est éventuellement à gérer). Tu veux avoir plusieurs machines frontales PHP pour de la répartition de charge. En général, le SGBD reste central, il est donc accessible de toutes les machines frontales et peu importe qu'un même internaute passe un coup sur une machine un coup sur une autre. Les sessions natives php4 sont gérées par des fichiers temporaires : il faut en protéger l'accès, et s'il y a plusieurs machines frontales être certain que l'internaute arrive toujours au même endroit ou monter un disque en type NFS, bref, faut bidouiller.
En plus, un débutant ne comprendra pas qu'il est idiot de vouloir stocker dans une session le retour d'un mysql_connect ou d'un mysql_query ou d'un fopen ou d'un fsockopen (heureusement, ça marche pas !).
Bref, ça ne sert pas à grand chose et c'est la tentation du fourre-tout.
Enfin, comme toujours : les sessions natives php4 ont leur intérêt à condition qu'on sache ce qu'on fait et comment ça fonctionne. C'est pour ça que je "hurle" régulièrement contre le manque de curiosité induit par les "résonnements" du type "m'en fous de comprendre je colle easyphp et je porc-gramme".
En l'occurence, c'est relativement pratique pour éviter de se trimballer dans l'URL des choix globaux de l'internaute non stockés côté serveur de manière rémanente (genre trucs stockés en cookies).
a++ JG --
Elle est mieux ma signature ? Oui. T'enlèves encore les conneries qu'il y a dedans
et ce sera parfait. (in GNU)
Bonjour,
Si c'est les session php4 que je te deconseille (...)
Pourquoi donc ?
Réponse rapide : c'est surtout une question d'habitudes et de contraintes de
l'application. Pour quelqu'un qui prend le train en marche avec PHP4,
pourquoi pas. Pour quelqu'un qui a déjà écrit les deux fonctions et trois
requêtes SQL nécessaires à gérer des sessions manuellement, ça ne sert à
rien.
Un exemple bête de l'inconvénient des sessions natives PHP : tu veux savoir
quel est le "nombre de connectés" (comprendre : personnes distinctes ayant
fait une requête sur le site il y a moins de 10 minutes par exemple). Vas
essayer de faire ça avec des sessions natives PHP4, on en reparlera. Si tu
as une table dans un SGBD, il suffit de faire un COUNT avec une clause WHERE
sur la colonne heure d'expiration... Tu veux logguer toutes les sessions qui
partent en time out : impossible. En SGBD, il suffit de faire un SELECT
avant le DELETE (oui, on peut avoir un petit problème de transactions, c'est
éventuellement à gérer). Tu veux avoir plusieurs machines frontales PHP pour
de la répartition de charge. En général, le SGBD reste central, il est donc
accessible de toutes les machines frontales et peu importe qu'un même
internaute passe un coup sur une machine un coup sur une autre. Les sessions
natives php4 sont gérées par des fichiers temporaires : il faut en protéger
l'accès, et s'il y a plusieurs machines frontales être certain que
l'internaute arrive toujours au même endroit ou monter un disque en type
NFS, bref, faut bidouiller.
En plus, un débutant ne comprendra pas qu'il est idiot de vouloir stocker
dans une session le retour d'un mysql_connect ou d'un mysql_query ou d'un
fopen ou d'un fsockopen (heureusement, ça marche pas !).
Bref, ça ne sert pas à grand chose et c'est la tentation du fourre-tout.
Enfin, comme toujours : les sessions natives php4 ont leur intérêt à
condition qu'on sache ce qu'on fait et comment ça fonctionne. C'est pour ça
que je "hurle" régulièrement contre le manque de curiosité induit par les
"résonnements" du type "m'en fous de comprendre je colle easyphp et je
porc-gramme".
En l'occurence, c'est relativement pratique pour éviter de se trimballer
dans l'URL des choix globaux de l'internaute non stockés côté serveur de
manière rémanente (genre trucs stockés en cookies).
a++
JG
--
Elle est mieux ma signature ?
Oui. T'enlèves encore les conneries qu'il y a dedans
Si c'est les session php4 que je te deconseille (...) Pourquoi donc ?
Réponse rapide : c'est surtout une question d'habitudes et de contraintes de l'application. Pour quelqu'un qui prend le train en marche avec PHP4, pourquoi pas. Pour quelqu'un qui a déjà écrit les deux fonctions et trois requêtes SQL nécessaires à gérer des sessions manuellement, ça ne sert à rien.
Un exemple bête de l'inconvénient des sessions natives PHP : tu veux savoir quel est le "nombre de connectés" (comprendre : personnes distinctes ayant fait une requête sur le site il y a moins de 10 minutes par exemple). Vas essayer de faire ça avec des sessions natives PHP4, on en reparlera. Si tu as une table dans un SGBD, il suffit de faire un COUNT avec une clause WHERE sur la colonne heure d'expiration... Tu veux logguer toutes les sessions qui partent en time out : impossible. En SGBD, il suffit de faire un SELECT avant le DELETE (oui, on peut avoir un petit problème de transactions, c'est éventuellement à gérer). Tu veux avoir plusieurs machines frontales PHP pour de la répartition de charge. En général, le SGBD reste central, il est donc accessible de toutes les machines frontales et peu importe qu'un même internaute passe un coup sur une machine un coup sur une autre. Les sessions natives php4 sont gérées par des fichiers temporaires : il faut en protéger l'accès, et s'il y a plusieurs machines frontales être certain que l'internaute arrive toujours au même endroit ou monter un disque en type NFS, bref, faut bidouiller.
En plus, un débutant ne comprendra pas qu'il est idiot de vouloir stocker dans une session le retour d'un mysql_connect ou d'un mysql_query ou d'un fopen ou d'un fsockopen (heureusement, ça marche pas !).
Bref, ça ne sert pas à grand chose et c'est la tentation du fourre-tout.
Enfin, comme toujours : les sessions natives php4 ont leur intérêt à condition qu'on sache ce qu'on fait et comment ça fonctionne. C'est pour ça que je "hurle" régulièrement contre le manque de curiosité induit par les "résonnements" du type "m'en fous de comprendre je colle easyphp et je porc-gramme".
En l'occurence, c'est relativement pratique pour éviter de se trimballer dans l'URL des choix globaux de l'internaute non stockés côté serveur de manière rémanente (genre trucs stockés en cookies).
a++ JG --
Elle est mieux ma signature ? Oui. T'enlèves encore les conneries qu'il y a dedans
et ce sera parfait. (in GNU)
Gg
On 23 Aug 2003 10:39:04 GMT, John GALLET wrote:
Enfin, comme toujours : les sessions natives php4 ont leur intérêt à condition qu'on sache ce qu'on fait et comment ça fonctionne. C'est pour ça que je "hurle" régulièrement contre le manque de curiosité induit par les "résonnements" du type "m'en fous de comprendre je colle easyphp et je porc-gramme".
Euh.. c'est juste pour dire, j'ai EasyPHP, mais je gère mes sessions :-) D'ailleurs j'ai aussi fait un système de gestion avec un petit fichier qui va bien à la place d'une table, mais ca serait à tester.
-- GéraLd : http://gerald.fauvelle.free.fr | Photos : http://www.gg.free.fr | myStats : Système de statistiques | Version 1.0.8 - http://my.stats.free.fr
On 23 Aug 2003 10:39:04 GMT, John GALLET wrote:
Enfin, comme toujours : les sessions natives php4 ont leur intérêt à
condition qu'on sache ce qu'on fait et comment ça fonctionne. C'est pour ça
que je "hurle" régulièrement contre le manque de curiosité induit par les
"résonnements" du type "m'en fous de comprendre je colle easyphp et je
porc-gramme".
Euh.. c'est juste pour dire, j'ai EasyPHP, mais je gère mes sessions :-)
D'ailleurs j'ai aussi fait un système de gestion avec un petit fichier qui
va bien à la place d'une table, mais ca serait à tester.
--
GéraLd : http://gerald.fauvelle.free.fr
| Photos : http://www.gg.free.fr
| myStats : Système de statistiques
| Version 1.0.8 - http://my.stats.free.fr
Enfin, comme toujours : les sessions natives php4 ont leur intérêt à condition qu'on sache ce qu'on fait et comment ça fonctionne. C'est pour ça que je "hurle" régulièrement contre le manque de curiosité induit par les "résonnements" du type "m'en fous de comprendre je colle easyphp et je porc-gramme".
Euh.. c'est juste pour dire, j'ai EasyPHP, mais je gère mes sessions :-) D'ailleurs j'ai aussi fait un système de gestion avec un petit fichier qui va bien à la place d'une table, mais ca serait à tester.
-- GéraLd : http://gerald.fauvelle.free.fr | Photos : http://www.gg.free.fr | myStats : Système de statistiques | Version 1.0.8 - http://my.stats.free.fr
John GALLET
Bonsoir,
D'ailleurs j'ai aussi fait un système de gestion avec un petit fichier qui va bien à la place d'une table
Je ne voudrais pas que tu croies que je te prends en grippe, mais je serais curieux de connaire l'intérêt d'un tel développement. Les sessions natives PHP4 sont déjà sur fichiers. Donc j'avoue que j'ai un peu de mal à suivre.
a++ JG
Bonsoir,
D'ailleurs j'ai aussi fait un système de gestion avec un petit fichier qui
va bien à la place d'une table
Je ne voudrais pas que tu croies que je te prends en grippe, mais je serais
curieux de connaire l'intérêt d'un tel développement. Les sessions natives
PHP4 sont déjà sur fichiers. Donc j'avoue que j'ai un peu de mal à suivre.
D'ailleurs j'ai aussi fait un système de gestion avec un petit fichier qui va bien à la place d'une table
Je ne voudrais pas que tu croies que je te prends en grippe, mais je serais curieux de connaire l'intérêt d'un tel développement. Les sessions natives PHP4 sont déjà sur fichiers. Donc j'avoue que j'ai un peu de mal à suivre.
a++ JG
Gg
On 24 Aug 2003 10:09:26 GMT, John GALLET wrote:
Je ne voudrais pas que tu croies que je te prends en grippe, mais je serais curieux de connaire l'intérêt d'un tel développement.
Pour ne pas utiliser une table mySQL.
Les sessions natives PHP4 sont déjà sur fichiers. Donc j'avoue que j'ai un peu de mal à suivre.
Non, là j'utilise un seul fichier dont je gère le contenu, comme on le fait avec une table mysql. L'intérêt, c'est de mettre le fichier où on veut, sans passer 1 h à comprendre que sur Free il faut créer un répertoire sessions (avec le s à la fin) pour que ça marche, et que chez un autre hébergeur ca sera autrement.
Enfin, moi je trouve ça pratique, par exemple pour un outil qui utiliserait des sessions, un utilisateur a juste à copier l'outil en question sur son site, et pas s'embéter à voir ce qu'il faut faire pour que les sessions fonctionnent.
-- GéraLd : http://gerald.fauvelle.free.fr | Photos : http://www.gg.free.fr | myStats : Système de statistiques | Version 1.0.8 - http://my.stats.free.fr
On 24 Aug 2003 10:09:26 GMT, John GALLET wrote:
Je ne voudrais pas que tu croies que je te prends en grippe, mais je serais
curieux de connaire l'intérêt d'un tel développement.
Pour ne pas utiliser une table mySQL.
Les sessions natives
PHP4 sont déjà sur fichiers. Donc j'avoue que j'ai un peu de mal à suivre.
Non, là j'utilise un seul fichier dont je gère le contenu, comme on le fait
avec une table mysql.
L'intérêt, c'est de mettre le fichier où on veut, sans passer 1 h à
comprendre que sur Free il faut créer un répertoire sessions (avec le s à
la fin) pour que ça marche, et que chez un autre hébergeur ca sera
autrement.
Enfin, moi je trouve ça pratique, par exemple pour un outil qui utiliserait
des sessions, un utilisateur a juste à copier l'outil en question sur son
site, et pas s'embéter à voir ce qu'il faut faire pour que les sessions
fonctionnent.
--
GéraLd : http://gerald.fauvelle.free.fr
| Photos : http://www.gg.free.fr
| myStats : Système de statistiques
| Version 1.0.8 - http://my.stats.free.fr
Je ne voudrais pas que tu croies que je te prends en grippe, mais je serais curieux de connaire l'intérêt d'un tel développement.
Pour ne pas utiliser une table mySQL.
Les sessions natives PHP4 sont déjà sur fichiers. Donc j'avoue que j'ai un peu de mal à suivre.
Non, là j'utilise un seul fichier dont je gère le contenu, comme on le fait avec une table mysql. L'intérêt, c'est de mettre le fichier où on veut, sans passer 1 h à comprendre que sur Free il faut créer un répertoire sessions (avec le s à la fin) pour que ça marche, et que chez un autre hébergeur ca sera autrement.
Enfin, moi je trouve ça pratique, par exemple pour un outil qui utiliserait des sessions, un utilisateur a juste à copier l'outil en question sur son site, et pas s'embéter à voir ce qu'il faut faire pour que les sessions fonctionnent.
-- GéraLd : http://gerald.fauvelle.free.fr | Photos : http://www.gg.free.fr | myStats : Système de statistiques | Version 1.0.8 - http://my.stats.free.fr
