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
John GALLET
Si à la soumission de la troisième étape, je redirige vers une URLM en SSL, je perds mon objet en session,
Vérifie dans le manuel si ce comportement est "normal" (et stupide, cas dans lequel, direction un autre mécanisme de gestion de sessions) ou si c'est une erreur de codage.
Si par exemple c'est une sombre histoire de domaine dans le cookie, il n'y a pas que les cookies dans la vie des sessions natives php, et peut-être un moyen de contourner. Ou peut-être parce que quand tu "rediriges" vers SSL ce n'est pas fait de manière compatible.
Quelles solutions, méthodes ou architectures proposeriez vous dans un cas pareil ?
Ce besoin est assez "normal" donc il doit bien y avoir un moyen de faire fonctionner ça correctement. Il faut comprendre d'où vient la perte de session avant de pouvoir répondre.
a++; JG
Si à la soumission de la troisième étape, je redirige vers une URLM en
SSL, je perds mon objet en session,
Vérifie dans le manuel si ce comportement est "normal" (et stupide, cas
dans lequel, direction un autre mécanisme de gestion de sessions) ou si
c'est une erreur de codage.
Si par exemple c'est une sombre histoire de domaine dans le cookie, il
n'y a pas que les cookies dans la vie des sessions natives php, et
peut-être un moyen de contourner. Ou peut-être parce que quand tu
"rediriges" vers SSL ce n'est pas fait de manière compatible.
Quelles solutions, méthodes ou architectures proposeriez vous dans un
cas pareil ?
Ce besoin est assez "normal" donc il doit bien y avoir un moyen de faire
fonctionner ça correctement. Il faut comprendre d'où vient la perte de
session avant de pouvoir répondre.
Si à la soumission de la troisième étape, je redirige vers une URLM en SSL, je perds mon objet en session,
Vérifie dans le manuel si ce comportement est "normal" (et stupide, cas dans lequel, direction un autre mécanisme de gestion de sessions) ou si c'est une erreur de codage.
Si par exemple c'est une sombre histoire de domaine dans le cookie, il n'y a pas que les cookies dans la vie des sessions natives php, et peut-être un moyen de contourner. Ou peut-être parce que quand tu "rediriges" vers SSL ce n'est pas fait de manière compatible.
Quelles solutions, méthodes ou architectures proposeriez vous dans un cas pareil ?
Ce besoin est assez "normal" donc il doit bien y avoir un moyen de faire fonctionner ça correctement. Il faut comprendre d'où vient la perte de session avant de pouvoir répondre.
a++; JG
Yttrium
Si par exemple c'est une sombre histoire de domaine dans le cookie, il n'y a pas que les cookies dans la vie des sessions natives php, et peut-être un moyen de contourner. Ou peut-être parce que quand tu "rediriges" vers SSL ce n'est pas fait de manière compatible.
Bonjour,
Il s'agissait probablement d'un problème , non lié à PHP, après avoir passé en revue la configuration du serveur et réalisé quelques modifications, tout fonctionne.
Cepedant, je suis presque surpris que cela fonctionne. Si les sessions en sont pas gérées par des cookies, mais par des fichiers sur le serveur. En changeant de serveur virutels (puisque je passe en SSL sur un nouveau virtual host), comment la session est elle conservée ?
Merci de votre aide.
Salutations.
-- [- Yttrium - http://www.danstesyeux.com -] Le temps ne fait rien à l'affaire, quand on est con... on est con...
Si par exemple c'est une sombre histoire de domaine dans le cookie, il
n'y a pas que les cookies dans la vie des sessions natives php, et
peut-être un moyen de contourner. Ou peut-être parce que quand tu
"rediriges" vers SSL ce n'est pas fait de manière compatible.
Bonjour,
Il s'agissait probablement d'un problème , non lié à PHP, après avoir
passé en revue la configuration du serveur et réalisé quelques
modifications, tout fonctionne.
Cepedant, je suis presque surpris que cela fonctionne.
Si les sessions en sont pas gérées par des cookies, mais par des
fichiers sur le serveur.
En changeant de serveur virutels (puisque je passe en SSL sur un nouveau
virtual host), comment la session est elle conservée ?
Merci de votre aide.
Salutations.
--
[- Yttrium - http://www.danstesyeux.com -]
Le temps ne fait rien à l'affaire, quand on est con...
on est con...
Si par exemple c'est une sombre histoire de domaine dans le cookie, il n'y a pas que les cookies dans la vie des sessions natives php, et peut-être un moyen de contourner. Ou peut-être parce que quand tu "rediriges" vers SSL ce n'est pas fait de manière compatible.
Bonjour,
Il s'agissait probablement d'un problème , non lié à PHP, après avoir passé en revue la configuration du serveur et réalisé quelques modifications, tout fonctionne.
Cepedant, je suis presque surpris que cela fonctionne. Si les sessions en sont pas gérées par des cookies, mais par des fichiers sur le serveur. En changeant de serveur virutels (puisque je passe en SSL sur un nouveau virtual host), comment la session est elle conservée ?
Merci de votre aide.
Salutations.
-- [- Yttrium - http://www.danstesyeux.com -] Le temps ne fait rien à l'affaire, quand on est con... on est con...
Calimero
Yttrium wrote:
Cepedant, je suis presque surpris que cela fonctionne. Si les sessions en sont pas gérées par des cookies, mais par des fichiers sur le serveur. En changeant de serveur virutels (puisque je passe en SSL sur un nouveau virtual host), comment la session est elle conservée ?
Hein ? quoi ?
Côté serveur, une session est identifiée par un ... identifiant, un jeton (le session id !). A partir de cet ID, il est possible de retrouver les données. La recherche de ces infos, le stockage, la suppression à expiration sont gérées par un handler, c'est à dire un ensemble de fonctions. Le handler typique en PHP est le handler "files" qui va effectivement stocker les infos de session sur le disque dur du serveur web. Il y a d'autres handlers qui peuvent travailler en RAM, dans une base de données SQL, en utilisant un daemon de type memcached, ... tu peux également écrire ton propre handler pour gérer stockage/récupération/expiration des infos de session.
A cet instant, on sait établir une correspondance entre un ID de session et les données qui vont avec, sur le serveur. Il faut maintenant effectuer la correspondance "visiteur ==> données", c'est à dire "visiteur ==> session ID ==> données". On va donc envoyer par un certain moyen le session ID au visiteur (enfin, au User Agent) en demandant que le visiteur le renvoie à chaque requête successive pour qu'on puisse effectué la recherche "visiteur ==> sessionID ==> données".
Il y a donc différents moyens, l'un d'eux est l'emploi de cookies. Le serveur renvoie le session ID sous forme de cookie (éphémère, généralement), cookie que le navigateur renverra (s'il est bien configuré) à chaque requête ultérieure. Un cookie n'est valable que pour un hostname, avec en plus d'éventuelles restrictions sur le path. On peut restreindre les cookies pour www.truc.com/toto afin que www.truc.com/bidule ne puisse pas les lire. Bref, que tu tapes en HTTP ou HTTPS "www.truc.com", le navigateur considère que c'est le même hostname et va donc considérer que c'est le même "espace à cookies" et tu pourras donc garder tes sessions. Je ne sais pas si certains navigateurs font une distinction entre HTTPS et HTTP (ma motivation pour lire les RFC, ou fouiller mon IE/FFox est un peu faible, vue l'heure).
Un autre moyen de trainer le session ID de requête en requête est de le passer constamment dans l'URL. Tu te retrouves avec des URL du genre: http://www.truc.com/toto.php?sid«CDEFGHIJKLM1234 Au lieu de chercher dans les cookies, PHP va alors étudier l'URL pour extraire le session ID et donc pouvoir retrouver les infos associées à la session.
Notons toutefois que selon ta configuration de virtual hosts, il doit effectivement être possible de péter les sessions entre HTTPS et HTTP, en spécifiant des options de config PHP par vhost. Mais a priori, ce sera alors une démarche voulue/consciente.
Bref, il faut clairement comprendre la distinction entre ce qui est côté serveur et ce qui est côté client, sinon on peut se compliquer la vie ou inversement s'exposer à de graves désillusions.
-- @+ Calimero
Yttrium wrote:
Cepedant, je suis presque surpris que cela fonctionne.
Si les sessions en sont pas gérées par des cookies, mais par des
fichiers sur le serveur.
En changeant de serveur virutels (puisque je passe en SSL sur un nouveau
virtual host), comment la session est elle conservée ?
Hein ? quoi ?
Côté serveur, une session est identifiée par un ... identifiant, un
jeton (le session id !). A partir de cet ID, il est possible de
retrouver les données. La recherche de ces infos, le stockage, la
suppression à expiration sont gérées par un handler, c'est à dire un
ensemble de fonctions. Le handler typique en PHP est le handler
"files" qui va effectivement stocker les infos de session sur le
disque dur du serveur web. Il y a d'autres handlers qui peuvent
travailler en RAM, dans une base de données SQL, en utilisant un
daemon de type memcached, ... tu peux également écrire ton propre
handler pour gérer stockage/récupération/expiration des infos de session.
A cet instant, on sait établir une correspondance entre un ID de
session et les données qui vont avec, sur le serveur. Il faut
maintenant effectuer la correspondance "visiteur ==> données", c'est à
dire "visiteur ==> session ID ==> données".
On va donc envoyer par un certain moyen le session ID au visiteur
(enfin, au User Agent) en demandant que le visiteur le renvoie à
chaque requête successive pour qu'on puisse effectué la recherche
"visiteur ==> sessionID ==> données".
Il y a donc différents moyens, l'un d'eux est l'emploi de cookies. Le
serveur renvoie le session ID sous forme de cookie (éphémère,
généralement), cookie que le navigateur renverra (s'il est bien
configuré) à chaque requête ultérieure. Un cookie n'est valable que
pour un hostname, avec en plus d'éventuelles restrictions sur le path.
On peut restreindre les cookies pour www.truc.com/toto afin que
www.truc.com/bidule ne puisse pas les lire.
Bref, que tu tapes en HTTP ou HTTPS "www.truc.com", le navigateur
considère que c'est le même hostname et va donc considérer que c'est
le même "espace à cookies" et tu pourras donc garder tes sessions. Je
ne sais pas si certains navigateurs font une distinction entre HTTPS
et HTTP (ma motivation pour lire les RFC, ou fouiller mon IE/FFox est
un peu faible, vue l'heure).
Un autre moyen de trainer le session ID de requête en requête est de
le passer constamment dans l'URL.
Tu te retrouves avec des URL du genre:
http://www.truc.com/toto.php?sid«CDEFGHIJKLM1234
Au lieu de chercher dans les cookies, PHP va alors étudier l'URL pour
extraire le session ID et donc pouvoir retrouver les infos associées à
la session.
Notons toutefois que selon ta configuration de virtual hosts, il doit
effectivement être possible de péter les sessions entre HTTPS et HTTP,
en spécifiant des options de config PHP par vhost. Mais a priori, ce
sera alors une démarche voulue/consciente.
Bref, il faut clairement comprendre la distinction entre ce qui est
côté serveur et ce qui est côté client, sinon on peut se compliquer la
vie ou inversement s'exposer à de graves désillusions.
Cepedant, je suis presque surpris que cela fonctionne. Si les sessions en sont pas gérées par des cookies, mais par des fichiers sur le serveur. En changeant de serveur virutels (puisque je passe en SSL sur un nouveau virtual host), comment la session est elle conservée ?
Hein ? quoi ?
Côté serveur, une session est identifiée par un ... identifiant, un jeton (le session id !). A partir de cet ID, il est possible de retrouver les données. La recherche de ces infos, le stockage, la suppression à expiration sont gérées par un handler, c'est à dire un ensemble de fonctions. Le handler typique en PHP est le handler "files" qui va effectivement stocker les infos de session sur le disque dur du serveur web. Il y a d'autres handlers qui peuvent travailler en RAM, dans une base de données SQL, en utilisant un daemon de type memcached, ... tu peux également écrire ton propre handler pour gérer stockage/récupération/expiration des infos de session.
A cet instant, on sait établir une correspondance entre un ID de session et les données qui vont avec, sur le serveur. Il faut maintenant effectuer la correspondance "visiteur ==> données", c'est à dire "visiteur ==> session ID ==> données". On va donc envoyer par un certain moyen le session ID au visiteur (enfin, au User Agent) en demandant que le visiteur le renvoie à chaque requête successive pour qu'on puisse effectué la recherche "visiteur ==> sessionID ==> données".
Il y a donc différents moyens, l'un d'eux est l'emploi de cookies. Le serveur renvoie le session ID sous forme de cookie (éphémère, généralement), cookie que le navigateur renverra (s'il est bien configuré) à chaque requête ultérieure. Un cookie n'est valable que pour un hostname, avec en plus d'éventuelles restrictions sur le path. On peut restreindre les cookies pour www.truc.com/toto afin que www.truc.com/bidule ne puisse pas les lire. Bref, que tu tapes en HTTP ou HTTPS "www.truc.com", le navigateur considère que c'est le même hostname et va donc considérer que c'est le même "espace à cookies" et tu pourras donc garder tes sessions. Je ne sais pas si certains navigateurs font une distinction entre HTTPS et HTTP (ma motivation pour lire les RFC, ou fouiller mon IE/FFox est un peu faible, vue l'heure).
Un autre moyen de trainer le session ID de requête en requête est de le passer constamment dans l'URL. Tu te retrouves avec des URL du genre: http://www.truc.com/toto.php?sid«CDEFGHIJKLM1234 Au lieu de chercher dans les cookies, PHP va alors étudier l'URL pour extraire le session ID et donc pouvoir retrouver les infos associées à la session.
Notons toutefois que selon ta configuration de virtual hosts, il doit effectivement être possible de péter les sessions entre HTTPS et HTTP, en spécifiant des options de config PHP par vhost. Mais a priori, ce sera alors une démarche voulue/consciente.
Bref, il faut clairement comprendre la distinction entre ce qui est côté serveur et ce qui est côté client, sinon on peut se compliquer la vie ou inversement s'exposer à de graves désillusions.
-- @+ Calimero
Yttrium
Bref, il faut clairement comprendre la distinction entre ce qui est côté serveur et ce qui est côté client, sinon on peut se compliquer la vie ou inversement s'exposer à de graves désillusions.
Merci pour ces explications.
Je fais trés bien la part des choses entre ce qui est coté serveur et coté client. La seule notions dont je n'avais pas connaissance c'etait :
Un cookie n'est valable que pour un hostname, avec en plus d'éventuelles restrictions sur le path. On peut restreindre les cookies pour www.truc.com/toto afin que www.truc.com/bidule ne puisse pas les lire. Bref, que tu tapes en HTTP ou HTTPS "www.truc.com", le navigateur considère que c'est le même hostname et va donc considérer que c'est le même "espace à cookies" et tu pourras donc garder tes sessions.
Merci donc pour cet eclaircissement. Salutations.
-- [- Yttrium - http://www.danstesyeux.com -] Le temps ne fait rien à l'affaire, quand on est con... on est con...
Bref, il faut clairement comprendre la distinction entre ce qui est côté
serveur et ce qui est côté client, sinon on peut se compliquer la vie ou
inversement s'exposer à de graves désillusions.
Merci pour ces explications.
Je fais trés bien la part des choses entre ce qui est coté serveur et
coté client.
La seule notions dont je n'avais pas connaissance c'etait :
Un cookie n'est valable que pour un hostname, avec en plus
d'éventuelles restrictions sur le path. On peut restreindre
les cookies pour www.truc.com/toto afin que www.truc.com/bidule ne
puisse pas les lire.
Bref, que tu tapes en HTTP ou HTTPS "www.truc.com", le navigateur
considère que c'est le même hostname et va donc considérer que c'est
le même "espace à cookies" et tu pourras donc garder tes sessions.
Merci donc pour cet eclaircissement.
Salutations.
--
[- Yttrium - http://www.danstesyeux.com -]
Le temps ne fait rien à l'affaire, quand on est con...
on est con...
Bref, il faut clairement comprendre la distinction entre ce qui est côté serveur et ce qui est côté client, sinon on peut se compliquer la vie ou inversement s'exposer à de graves désillusions.
Merci pour ces explications.
Je fais trés bien la part des choses entre ce qui est coté serveur et coté client. La seule notions dont je n'avais pas connaissance c'etait :
Un cookie n'est valable que pour un hostname, avec en plus d'éventuelles restrictions sur le path. On peut restreindre les cookies pour www.truc.com/toto afin que www.truc.com/bidule ne puisse pas les lire. Bref, que tu tapes en HTTP ou HTTPS "www.truc.com", le navigateur considère que c'est le même hostname et va donc considérer que c'est le même "espace à cookies" et tu pourras donc garder tes sessions.
Merci donc pour cet eclaircissement. Salutations.
-- [- Yttrium - http://www.danstesyeux.com -] Le temps ne fait rien à l'affaire, quand on est con... on est con...
