ça fait un bout de temps que je regarde la doc sur les sessions, en me
disant qu'il faut que je me lance. Là j'ai un peu de temps et de
tranquillité, alors juste avant j'aimerais que vous m'aidiez à éclaircir
quelques points.
1) Grâce aux sessions, je n'aurais plus de problème de variables
inaccessibles dans certains scripts ?
2) Je lis partout qu'il faut faire appel à session_start() une fois au début
de chaque page, mais qu'en est-il d'une page faisant appel à une autre par
require ou include, qui éventuellement fait-elle même appel à une autre, etc
? Faut-il gérer ça, ou est-ce transparent ?
3) Pour effacer la session, il faut faire appel à session_destroy. Si un
utilisateur quitte la page avant, le fichier temporaire sera-il détruit
automatiquement, ou bien faut-il prévoir un petit ménage de temps en temps ?
4) J'ai un script récupéré qui utilise :
if (!$uniqid AND !headers_sent()) { $uniqid=uniqid(rand());
setcookie("uniqid",$uniqid,time()+(3600*24*365*30)); }
si j'ai bien compris, je doit pouvoir le modifier pour être en adéquation
avec les sessions de php 4.3.0. Quelqu'un peut-il m'aiguiller ?
Merci
--
VarioFlux
http://www.educador.biz
Centre d'éducation canine sur la Côte d'Azur
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
\(¯`·...Rem's ...·´¯\)
Bjr,
1) Grâce aux sessions, je n'aurais plus de problème de variables inaccessibles dans certains scripts ?
Exact..
2) Je lis partout qu'il faut faire appel à session_start() une fois au début
de chaque page, mais qu'en est-il d'une page faisant appel à une autre par require ou include, qui éventuellement fait-elle même appel à une autre, etc
? Faut-il gérer ça, ou est-ce transparent ?
Il suffit de faire un include en entete de la page qui va inclure toutes les autres
3) Pour effacer la session, il faut faire appel à session_destroy. Si un utilisateur quitte la page avant, le fichier temporaire sera-il détruit automatiquement, ou bien faut-il prévoir un petit ménage de temps en temps ?
Le fichier sera détruit une fois dépassé la durée de vie de la session , fixée dans le php.ini à la ligne : session.lifetime et session.gc_maxlifetime
4) J'ai un script récupéré qui utilise : if (!$uniqid AND !headers_sent()) { $uniqid=uniqid(rand()); setcookie("uniqid",$uniqid,time()+(3600*24*365*30)); } si j'ai bien compris, je doit pouvoir le modifier pour être en adéquation avec les sessions de php 4.3.0. Quelqu'un peut-il m'aiguiller ?
Là, je suis désolé mais j'ai pas le temps et en plus je n'utilise JAMAIS les cookies (trop dépendants du client)..
Merci
De rien. Salut.
Bjr,
1) Grâce aux sessions, je n'aurais plus de problème de variables
inaccessibles dans certains scripts ?
Exact..
2) Je lis partout qu'il faut faire appel à session_start() une fois au
début
de chaque page, mais qu'en est-il d'une page faisant appel à une autre par
require ou include, qui éventuellement fait-elle même appel à une autre,
etc
? Faut-il gérer ça, ou est-ce transparent ?
Il suffit de faire un include en entete de la page qui va inclure toutes les
autres
3) Pour effacer la session, il faut faire appel à session_destroy. Si un
utilisateur quitte la page avant, le fichier temporaire sera-il détruit
automatiquement, ou bien faut-il prévoir un petit ménage de temps en temps
?
Le fichier sera détruit une fois dépassé la durée de vie de la session ,
fixée dans le php.ini à la ligne : session.lifetime et
session.gc_maxlifetime
4) J'ai un script récupéré qui utilise :
if (!$uniqid AND !headers_sent()) { $uniqid=uniqid(rand());
setcookie("uniqid",$uniqid,time()+(3600*24*365*30)); }
si j'ai bien compris, je doit pouvoir le modifier pour être en adéquation
avec les sessions de php 4.3.0. Quelqu'un peut-il m'aiguiller ?
Là, je suis désolé mais j'ai pas le temps et en plus je n'utilise JAMAIS les
cookies (trop dépendants du client)..
1) Grâce aux sessions, je n'aurais plus de problème de variables inaccessibles dans certains scripts ?
Exact..
2) Je lis partout qu'il faut faire appel à session_start() une fois au début
de chaque page, mais qu'en est-il d'une page faisant appel à une autre par require ou include, qui éventuellement fait-elle même appel à une autre, etc
? Faut-il gérer ça, ou est-ce transparent ?
Il suffit de faire un include en entete de la page qui va inclure toutes les autres
3) Pour effacer la session, il faut faire appel à session_destroy. Si un utilisateur quitte la page avant, le fichier temporaire sera-il détruit automatiquement, ou bien faut-il prévoir un petit ménage de temps en temps ?
Le fichier sera détruit une fois dépassé la durée de vie de la session , fixée dans le php.ini à la ligne : session.lifetime et session.gc_maxlifetime
4) J'ai un script récupéré qui utilise : if (!$uniqid AND !headers_sent()) { $uniqid=uniqid(rand()); setcookie("uniqid",$uniqid,time()+(3600*24*365*30)); } si j'ai bien compris, je doit pouvoir le modifier pour être en adéquation avec les sessions de php 4.3.0. Quelqu'un peut-il m'aiguiller ?
Là, je suis désolé mais j'ai pas le temps et en plus je n'utilise JAMAIS les cookies (trop dépendants du client)..
Faire passé des id de session par get pose enormement de probleme de securité, ne facilite pas le code ( flemard que je suis :)) et de plus n'est pas joli dans l'url.
ce n'est pas exact : si tu utilises les sessions, c'est le serveur qui décide quelle méthode de transmission du SessID utiliser (si compilé avec --trans-sid dans linux, toujours je suppose dans windows) en gros ça donne : - si le client accèpte les cookies alors un cookie PHPSESSID est créé - si le client ne les accepte pas le fichier envoyé est édité a posteriori par le serveur pour y ajouter le fameux "?PHPSESSID=xxxxx".
d'autre part il faut toujours tester la validité de la session pour chaque page (basé sur une reconnaissance de REMOTE_ADDR par exemple) pour éviter les problèmes de "bookmarkage" d'url avec id sessions.
Guillaume Bouchard wrote:
Faire passé des id de session par get pose enormement de probleme de
securité, ne facilite pas le code ( flemard que je suis :)) et de plus
n'est pas joli dans l'url.
ce n'est pas exact : si tu utilises les sessions, c'est le serveur qui
décide quelle méthode de transmission du SessID utiliser (si compilé
avec --trans-sid dans linux, toujours je suppose dans windows)
en gros ça donne :
- si le client accèpte les cookies alors un cookie PHPSESSID est créé
- si le client ne les accepte pas le fichier envoyé est édité a
posteriori par le serveur pour y ajouter le fameux "?PHPSESSID=xxxxx".
d'autre part il faut toujours tester la validité de la session pour
chaque page (basé sur une reconnaissance de REMOTE_ADDR par exemple)
pour éviter les problèmes de "bookmarkage" d'url avec id sessions.
Faire passé des id de session par get pose enormement de probleme de securité, ne facilite pas le code ( flemard que je suis :)) et de plus n'est pas joli dans l'url.
ce n'est pas exact : si tu utilises les sessions, c'est le serveur qui décide quelle méthode de transmission du SessID utiliser (si compilé avec --trans-sid dans linux, toujours je suppose dans windows) en gros ça donne : - si le client accèpte les cookies alors un cookie PHPSESSID est créé - si le client ne les accepte pas le fichier envoyé est édité a posteriori par le serveur pour y ajouter le fameux "?PHPSESSID=xxxxx".
d'autre part il faut toujours tester la validité de la session pour chaque page (basé sur une reconnaissance de REMOTE_ADDR par exemple) pour éviter les problèmes de "bookmarkage" d'url avec id sessions.
Nudrema
- si le client ne les accepte pas le fichier envoyé est édité a posteriori par le serveur pour y ajouter le fameux "?PHPSESSID=xxxxx".
Oui, mais il faut savoir que comme le serveur n'a aucun moyen de savoir si le client accepte les cookie, il fera toujours un id par get au depart.
en fait après test il semblerait que effectivement le serveur utilise toujours le système indiqué dans la configuration (donc si pas de cookies et indiqué comme tel dans la config ça foire). Mais en tout cas il ne faut pas pour autant ajouter <?php echo($PHPSESSID); ?> à chaque lien...
d'autre part il faut toujours tester la validité de la session pour chaque page (basé sur une reconnaissance de REMOTE_ADDR par exemple) pour éviter les problèmes de "bookmarkage" d'url avec id sessions.
Je ne voie pas en quoi cela peut aider ? Plus de precision stp.
voir plus bas ;-)
Par contre, les problemes de l'id par get
- Bookmarkage d'une url inutile - Copie sur un forum ou un NG d'une url contenant l'id de session ( j'ai deja vu le faire, donc ce n'est pas un cas improbable )
ces cas peuvent être corrigés par la vérification de l'adresse ip du visiteur (on refuse de récupérer la session (on la détruit) si l'ip n'est pas bonne...) et/ou par l'ajout d'une variable 'expiration' à la session (pour les bookmark dans le cas de connexions permanentes par exemple)
De plus, php genere mal les id de session, car il met un & aulieu de & dans les chaines get ( reglable dans le php.ini quand on y a acces... ) Et pour les formulaire, il foire tout, vu qu'il colle a la balise <form> un inpyt hidden... Mais dans les recomandations, il ne doit pas y avoir de input directement dans form, mais dans un block avant. Bye Bye le validator. pour les formulaires je n'avais jamais fait attention mais pour le &
plutôt que & dis-moi si je me trompe mais tu peux corriger ça via .htaccess non ? (de même tu peux spécifier via .htaccess que tu veux utiliser les cookies ^^)
- Esseye de passer sur un vieux php PHPSSESID=<script type="text/javascript">Alert('truc')</script> ( correctement encoder ) si je ne me trompe pas y avais un bug la dessus a une epoque, ce n'est pas dangereux, mais tres moche :)
pas compris ^^ puis de toute façon je n'utilise que les dernières versions ;-)
- si le client ne les accepte pas le fichier envoyé est édité a
posteriori par le serveur pour y ajouter le fameux "?PHPSESSID=xxxxx".
Oui, mais il faut savoir que comme le serveur n'a aucun moyen de savoir
si le client accepte les cookie, il fera toujours un id par get au depart.
en fait après test il semblerait que effectivement le serveur utilise
toujours le système indiqué dans la configuration (donc si pas de
cookies et indiqué comme tel dans la config ça foire). Mais en tout cas
il ne faut pas pour autant ajouter <?php echo($PHPSESSID); ?> à chaque
lien...
d'autre part il faut toujours tester la validité de la session pour
chaque page (basé sur une reconnaissance de REMOTE_ADDR par exemple)
pour éviter les problèmes de "bookmarkage" d'url avec id sessions.
Je ne voie pas en quoi cela peut aider ? Plus de precision stp.
voir plus bas ;-)
Par contre, les problemes de l'id par get
- Bookmarkage d'une url inutile
- Copie sur un forum ou un NG d'une url contenant l'id de session ( j'ai
deja vu le faire, donc ce n'est pas un cas improbable )
ces cas peuvent être corrigés par la vérification de l'adresse ip du
visiteur (on refuse de récupérer la session (on la détruit) si l'ip
n'est pas bonne...) et/ou par l'ajout d'une variable 'expiration' à la
session (pour les bookmark dans le cas de connexions permanentes par
exemple)
De plus, php genere mal les id de session, car il met un & aulieu de
& dans les chaines get ( reglable dans le php.ini quand on y a
acces... ) Et pour les formulaire, il foire tout, vu qu'il colle a la
balise <form> un inpyt hidden... Mais dans les recomandations, il ne
doit pas y avoir de input directement dans form, mais dans un block
avant. Bye Bye le validator.
pour les formulaires je n'avais jamais fait attention mais pour le &
plutôt que & dis-moi si je me trompe mais tu peux corriger ça via
.htaccess non ? (de même tu peux spécifier via .htaccess que tu veux
utiliser les cookies ^^)
- Esseye de passer sur un vieux php PHPSSESID=<script
type="text/javascript">Alert('truc')</script> ( correctement encoder )
si je ne me trompe pas y avais un bug la dessus a une epoque, ce n'est
pas dangereux, mais tres moche :)
pas compris ^^ puis de toute façon je n'utilise que les dernières
versions ;-)
- si le client ne les accepte pas le fichier envoyé est édité a posteriori par le serveur pour y ajouter le fameux "?PHPSESSID=xxxxx".
Oui, mais il faut savoir que comme le serveur n'a aucun moyen de savoir si le client accepte les cookie, il fera toujours un id par get au depart.
en fait après test il semblerait que effectivement le serveur utilise toujours le système indiqué dans la configuration (donc si pas de cookies et indiqué comme tel dans la config ça foire). Mais en tout cas il ne faut pas pour autant ajouter <?php echo($PHPSESSID); ?> à chaque lien...
d'autre part il faut toujours tester la validité de la session pour chaque page (basé sur une reconnaissance de REMOTE_ADDR par exemple) pour éviter les problèmes de "bookmarkage" d'url avec id sessions.
Je ne voie pas en quoi cela peut aider ? Plus de precision stp.
voir plus bas ;-)
Par contre, les problemes de l'id par get
- Bookmarkage d'une url inutile - Copie sur un forum ou un NG d'une url contenant l'id de session ( j'ai deja vu le faire, donc ce n'est pas un cas improbable )
ces cas peuvent être corrigés par la vérification de l'adresse ip du visiteur (on refuse de récupérer la session (on la détruit) si l'ip n'est pas bonne...) et/ou par l'ajout d'une variable 'expiration' à la session (pour les bookmark dans le cas de connexions permanentes par exemple)
De plus, php genere mal les id de session, car il met un & aulieu de & dans les chaines get ( reglable dans le php.ini quand on y a acces... ) Et pour les formulaire, il foire tout, vu qu'il colle a la balise <form> un inpyt hidden... Mais dans les recomandations, il ne doit pas y avoir de input directement dans form, mais dans un block avant. Bye Bye le validator. pour les formulaires je n'avais jamais fait attention mais pour le &
plutôt que & dis-moi si je me trompe mais tu peux corriger ça via .htaccess non ? (de même tu peux spécifier via .htaccess que tu veux utiliser les cookies ^^)
- Esseye de passer sur un vieux php PHPSSESID=<script type="text/javascript">Alert('truc')</script> ( correctement encoder ) si je ne me trompe pas y avais un bug la dessus a une epoque, ce n'est pas dangereux, mais tres moche :)
pas compris ^^ puis de toute façon je n'utilise que les dernières versions ;-)
Guillaume Bouchard
Nudrema wrote:
en fait après test il semblerait que effectivement le serveur utilise toujours le système indiqué dans la configuration (donc si pas de cookies et indiqué comme tel dans la config ça foire). Mais en tout cas il ne faut pas pour autant ajouter <?php echo($PHPSESSID); ?> à chaque lien...
En fait. SI tu met use_trans_sid a ON, tu n'a pas besion d'ajouté un echo du PHPSSESID.
Si tu le met a OFF ( reccomandé ) tu doit le faire manuelement.
Ensuite, comme je le disait, le serveur utilisera TOUJOURS ( sauf si tu lui dit que tu ne veut pas de GET ) le GET à la premiere visite. A la limite, si tu ne veut pas une chaine GET degeu au depart, tu peut faire une suite de deux Header Location pour tester si les cookies fonctionent et faire passé l'id de façon invisible pour la premiere foix, c'est aussi crade que un id de session en GET :)
ces cas peuvent être corrigés par la vérification de l'adresse ip du visiteur (on refuse de récupérer la session (on la détruit) si l'ip n'est pas bonne...) et/ou par l'ajout d'une variable 'expiration' à la session (pour les bookmark dans le cas de connexions permanentes par exemple)
Expiration : inutile, les sessions expirent d'elle meme :) Pour l'ip, cela securise, mais pas completement, il y a toujours le probleme des personnes qui on le meme ip à cause de proxy, et souvent ces personnes traine ensemble, donc peuvent se refiler facilement leur ip... Bref, j'appele cela une bidouille :)
pour les formulaires je n'avais jamais fait attention mais pour le & plutôt que & dis-moi si je me trompe mais tu peux corriger ça via .htaccess non ? (de même tu peux spécifier via .htaccess que tu veux utiliser les cookies ^^)
Tu à raison.
-- Guillaume.
Nudrema wrote:
en fait après test il semblerait que effectivement le serveur utilise
toujours le système indiqué dans la configuration (donc si pas de
cookies et indiqué comme tel dans la config ça foire). Mais en tout cas
il ne faut pas pour autant ajouter <?php echo($PHPSESSID); ?> à chaque
lien...
En fait.
SI tu met use_trans_sid a ON, tu n'a pas besion d'ajouté un echo du
PHPSSESID.
Si tu le met a OFF ( reccomandé ) tu doit le faire manuelement.
Ensuite, comme je le disait, le serveur utilisera TOUJOURS ( sauf si tu
lui dit que tu ne veut pas de GET ) le GET à la premiere visite. A la
limite, si tu ne veut pas une chaine GET degeu au depart, tu peut faire
une suite de deux Header Location pour tester si les cookies fonctionent
et faire passé l'id de façon invisible pour la premiere foix, c'est
aussi crade que un id de session en GET :)
ces cas peuvent être corrigés par la vérification de l'adresse ip du
visiteur (on refuse de récupérer la session (on la détruit) si l'ip
n'est pas bonne...) et/ou par l'ajout d'une variable 'expiration' à la
session (pour les bookmark dans le cas de connexions permanentes par
exemple)
Expiration : inutile, les sessions expirent d'elle meme :)
Pour l'ip, cela securise, mais pas completement, il y a toujours le
probleme des personnes qui on le meme ip à cause de proxy, et souvent
ces personnes traine ensemble, donc peuvent se refiler facilement leur
ip... Bref, j'appele cela une bidouille :)
pour les formulaires je n'avais jamais fait attention mais pour le &
plutôt que & dis-moi si je me trompe mais tu peux corriger ça via
.htaccess non ? (de même tu peux spécifier via .htaccess que tu veux
utiliser les cookies ^^)
en fait après test il semblerait que effectivement le serveur utilise toujours le système indiqué dans la configuration (donc si pas de cookies et indiqué comme tel dans la config ça foire). Mais en tout cas il ne faut pas pour autant ajouter <?php echo($PHPSESSID); ?> à chaque lien...
En fait. SI tu met use_trans_sid a ON, tu n'a pas besion d'ajouté un echo du PHPSSESID.
Si tu le met a OFF ( reccomandé ) tu doit le faire manuelement.
Ensuite, comme je le disait, le serveur utilisera TOUJOURS ( sauf si tu lui dit que tu ne veut pas de GET ) le GET à la premiere visite. A la limite, si tu ne veut pas une chaine GET degeu au depart, tu peut faire une suite de deux Header Location pour tester si les cookies fonctionent et faire passé l'id de façon invisible pour la premiere foix, c'est aussi crade que un id de session en GET :)
ces cas peuvent être corrigés par la vérification de l'adresse ip du visiteur (on refuse de récupérer la session (on la détruit) si l'ip n'est pas bonne...) et/ou par l'ajout d'une variable 'expiration' à la session (pour les bookmark dans le cas de connexions permanentes par exemple)
Expiration : inutile, les sessions expirent d'elle meme :) Pour l'ip, cela securise, mais pas completement, il y a toujours le probleme des personnes qui on le meme ip à cause de proxy, et souvent ces personnes traine ensemble, donc peuvent se refiler facilement leur ip... Bref, j'appele cela une bidouille :)
pour les formulaires je n'avais jamais fait attention mais pour le & plutôt que & dis-moi si je me trompe mais tu peux corriger ça via .htaccess non ? (de même tu peux spécifier via .htaccess que tu veux utiliser les cookies ^^)
