Bonjour
Deux questions :
1) Pour les appels Ajax à des scripts externes, j'ai vu sur le PHP
Manual ( commentaires ), que tout appel à session_start(), bloquait
le fichier de session.
En conséquence, il faudrait théoriquement appeler
'session_write_close()' avant chaque appel Ajax, puis
'session_start()' après chaque appel Ajax, dans le script appelant ?
2) Dans ces scripts appelés par Ajax, pour éviter le cache, je met
des headers type "Expires", "If-Modified", etc... mais avant avoir
lancé le session_start().
Est-il vrai, que session_start() change les headers déjà lancés, ceci
même si ( c'est mon cas ), je fais un ob_start() au début du script,
et un ob_end_flush() à la fin ?
En d'autres termes, dois-je placer les headers après le
session_start(), et pas avant, pour que ces headers soient pris en
compte ?
Le fait de définir le limiteur de cache à la valeur '' désactivera
automatiquement et totalement l'envoi des en-têtes de cache.
Le limiteur de cache est remis à la valeur par défaut de
session.cache_limiter à chaque démarrage de script PHP. Donc, vous
devrez appeler session_cache_limiter() à chaque page, et avant
session_start().
Bonjour
Deux questions :
1) Pour les appels Ajax à des scripts externes, j'ai vu sur le PHP
Manual ( commentaires ), que tout appel à session_start(), bloquait
le fichier de session.
En conséquence, il faudrait théoriquement appeler
'session_write_close()' avant chaque appel Ajax, puis
'session_start()' après chaque appel Ajax, dans le script appelant ?
2) Dans ces scripts appelés par Ajax, pour éviter le cache, je met
des headers type "Expires", "If-Modified", etc... mais avant avoir
lancé le session_start().
Est-il vrai, que session_start() change les headers déjà lancés, ceci
même si ( c'est mon cas ), je fais un ob_start() au début du script,
et un ob_end_flush() à la fin ?
En d'autres termes, dois-je placer les headers après le
session_start(), et pas avant, pour que ces headers soient pris en
compte ?
Le fait de définir le limiteur de cache à la valeur '' désactivera
automatiquement et totalement l'envoi des en-têtes de cache.
Le limiteur de cache est remis à la valeur par défaut de
session.cache_limiter à chaque démarrage de script PHP. Donc, vous
devrez appeler session_cache_limiter() à chaque page, et avant
session_start().
Bonjour
Deux questions :
1) Pour les appels Ajax à des scripts externes, j'ai vu sur le PHP
Manual ( commentaires ), que tout appel à session_start(), bloquait
le fichier de session.
En conséquence, il faudrait théoriquement appeler
'session_write_close()' avant chaque appel Ajax, puis
'session_start()' après chaque appel Ajax, dans le script appelant ?
2) Dans ces scripts appelés par Ajax, pour éviter le cache, je met
des headers type "Expires", "If-Modified", etc... mais avant avoir
lancé le session_start().
Est-il vrai, que session_start() change les headers déjà lancés, ceci
même si ( c'est mon cas ), je fais un ob_start() au début du script,
et un ob_end_flush() à la fin ?
En d'autres termes, dois-je placer les headers après le
session_start(), et pas avant, pour que ces headers soient pris en
compte ?
Le fait de définir le limiteur de cache à la valeur '' désactivera
automatiquement et totalement l'envoi des en-têtes de cache.
Le limiteur de cache est remis à la valeur par défaut de
session.cache_limiter à chaque démarrage de script PHP. Donc, vous
devrez appeler session_cache_limiter() à chaque page, et avant
session_start().
Rebonjour
J'aurais du me souvenir des conseils de Monsieur John Gallet.
En fait, le problème ne venait pas du cache.
Les identificateurs de session ( gérés par php ), semblent avoir eu des
doublons.
En d'autres termes : Au moment où j'étais sur mon site, quelqu'un
d'autre ( adresse ip différente probablement faut pas pousser ), était
connecté à la même page que moi, avec le même id de session.
Depuis ce matin, les id de session ( inscrits dans les tables MySQL avec
les enregs des données ), sont créés par une fonction tmp_random($nbre)
( que je donnerai volontiers ), qui génère une chaîne aléatoire ( et
imprévisible ), de $nbre caractères.
Je n'ai pas besoin que cet id soit conservé entre chaque chargement de
page, il est généré en amont une fois par chargement de page.
Je tiens le code de cette fonction à votre disposition.
L'id en question est fixé à une longueur de 50 caractères.
Respectueusement.
Jean François Ortolo
Rebonjour
J'aurais du me souvenir des conseils de Monsieur John Gallet.
En fait, le problème ne venait pas du cache.
Les identificateurs de session ( gérés par php ), semblent avoir eu des
doublons.
En d'autres termes : Au moment où j'étais sur mon site, quelqu'un
d'autre ( adresse ip différente probablement faut pas pousser ), était
connecté à la même page que moi, avec le même id de session.
Depuis ce matin, les id de session ( inscrits dans les tables MySQL avec
les enregs des données ), sont créés par une fonction tmp_random($nbre)
( que je donnerai volontiers ), qui génère une chaîne aléatoire ( et
imprévisible ), de $nbre caractères.
Je n'ai pas besoin que cet id soit conservé entre chaque chargement de
page, il est généré en amont une fois par chargement de page.
Je tiens le code de cette fonction à votre disposition.
L'id en question est fixé à une longueur de 50 caractères.
Respectueusement.
Jean François Ortolo
Rebonjour
J'aurais du me souvenir des conseils de Monsieur John Gallet.
En fait, le problème ne venait pas du cache.
Les identificateurs de session ( gérés par php ), semblent avoir eu des
doublons.
En d'autres termes : Au moment où j'étais sur mon site, quelqu'un
d'autre ( adresse ip différente probablement faut pas pousser ), était
connecté à la même page que moi, avec le même id de session.
Depuis ce matin, les id de session ( inscrits dans les tables MySQL avec
les enregs des données ), sont créés par une fonction tmp_random($nbre)
( que je donnerai volontiers ), qui génère une chaîne aléatoire ( et
imprévisible ), de $nbre caractères.
Je n'ai pas besoin que cet id soit conservé entre chaque chargement de
page, il est généré en amont une fois par chargement de page.
Je tiens le code de cette fonction à votre disposition.
L'id en question est fixé à une longueur de 50 caractères.
Respectueusement.
Jean François Ortolo
On 02/03/2015 17:10, Jean Francois Ortolo wrote:
Rebonjour
Bonjour
J'aurais du me souvenir des conseils de Monsieur John Gallet.
En fait, le problème ne venait pas du cache.
Les identificateurs de session ( gérés par php ), semblent avoir eu des
doublons.
C'est un peu gros. On a plus de chance de gagner 2 fois au loto que
d'avoir le même PHPSESSID. Quand bien même, je suppose que php vérifie
qu'il n'y a pas déjà une session active avec le même ID.
En d'autres termes : Au moment où j'étais sur mon site, quelqu'un
d'autre ( adresse ip différente probablement faut pas pousser ), était
connecté à la même page que moi, avec le même id de session.
C'est une supposition ou tu l'as vérifié sur des logs?
Ca peut aussi être un vol de session.
Depuis ce matin, les id de session ( inscrits dans les tables MySQL avec
les enregs des données ), sont créés par une fonction tmp_random($nbre)
( que je donnerai volontiers ), qui génère une chaîne aléatoire ( et
imprévisible ), de $nbre caractères.
OK. Par contre, tes ID sont conservés juste pour avoir une liste des ID
déja créés et éviter les doublons, ou pour autre chose?
Je n'ai pas besoin que cet id soit conservé entre chaque chargement de
page, il est généré en amont une fois par chargement de page.
La, par contre, ce n'est pas clair du tout, voir même inquiètant.
Je comprend que tu génère un ID différent pour chaque page et c'est
peut-être la cause du problème.
Un ID est créé pour chaque nouveau visiteur, c'est a dire si il
n'a pas de cookie PHPSESSID ou si il est expiré.
L'ID est conservé pendant toute la visite. En fait, on oublie l'ID.
et on laisse session_start() se débrouiller.
L'ID peut être changé dans certains cas par sécurité comme par exemple
quand un visiteur anonyme s'identifie sur le site.
On 02/03/2015 17:10, Jean Francois Ortolo wrote:
Rebonjour
Bonjour
J'aurais du me souvenir des conseils de Monsieur John Gallet.
En fait, le problème ne venait pas du cache.
Les identificateurs de session ( gérés par php ), semblent avoir eu des
doublons.
C'est un peu gros. On a plus de chance de gagner 2 fois au loto que
d'avoir le même PHPSESSID. Quand bien même, je suppose que php vérifie
qu'il n'y a pas déjà une session active avec le même ID.
En d'autres termes : Au moment où j'étais sur mon site, quelqu'un
d'autre ( adresse ip différente probablement faut pas pousser ), était
connecté à la même page que moi, avec le même id de session.
C'est une supposition ou tu l'as vérifié sur des logs?
Ca peut aussi être un vol de session.
Depuis ce matin, les id de session ( inscrits dans les tables MySQL avec
les enregs des données ), sont créés par une fonction tmp_random($nbre)
( que je donnerai volontiers ), qui génère une chaîne aléatoire ( et
imprévisible ), de $nbre caractères.
OK. Par contre, tes ID sont conservés juste pour avoir une liste des ID
déja créés et éviter les doublons, ou pour autre chose?
Je n'ai pas besoin que cet id soit conservé entre chaque chargement de
page, il est généré en amont une fois par chargement de page.
La, par contre, ce n'est pas clair du tout, voir même inquiètant.
Je comprend que tu génère un ID différent pour chaque page et c'est
peut-être la cause du problème.
Un ID est créé pour chaque nouveau visiteur, c'est a dire si il
n'a pas de cookie PHPSESSID ou si il est expiré.
L'ID est conservé pendant toute la visite. En fait, on oublie l'ID.
et on laisse session_start() se débrouiller.
L'ID peut être changé dans certains cas par sécurité comme par exemple
quand un visiteur anonyme s'identifie sur le site.
On 02/03/2015 17:10, Jean Francois Ortolo wrote:
Rebonjour
Bonjour
J'aurais du me souvenir des conseils de Monsieur John Gallet.
En fait, le problème ne venait pas du cache.
Les identificateurs de session ( gérés par php ), semblent avoir eu des
doublons.
C'est un peu gros. On a plus de chance de gagner 2 fois au loto que
d'avoir le même PHPSESSID. Quand bien même, je suppose que php vérifie
qu'il n'y a pas déjà une session active avec le même ID.
En d'autres termes : Au moment où j'étais sur mon site, quelqu'un
d'autre ( adresse ip différente probablement faut pas pousser ), était
connecté à la même page que moi, avec le même id de session.
C'est une supposition ou tu l'as vérifié sur des logs?
Ca peut aussi être un vol de session.
Depuis ce matin, les id de session ( inscrits dans les tables MySQL avec
les enregs des données ), sont créés par une fonction tmp_random($nbre)
( que je donnerai volontiers ), qui génère une chaîne aléatoire ( et
imprévisible ), de $nbre caractères.
OK. Par contre, tes ID sont conservés juste pour avoir une liste des ID
déja créés et éviter les doublons, ou pour autre chose?
Je n'ai pas besoin que cet id soit conservé entre chaque chargement de
page, il est généré en amont une fois par chargement de page.
La, par contre, ce n'est pas clair du tout, voir même inquiètant.
Je comprend que tu génère un ID différent pour chaque page et c'est
peut-être la cause du problème.
Un ID est créé pour chaque nouveau visiteur, c'est a dire si il
n'a pas de cookie PHPSESSID ou si il est expiré.
L'ID est conservé pendant toute la visite. En fait, on oublie l'ID.
et on laisse session_start() se débrouiller.
L'ID peut être changé dans certains cas par sécurité comme par exemple
quand un visiteur anonyme s'identifie sur le site.
Cette fonction est censé rendre un identificateur/chaîne de caractères,
non prévisible de quelque manière que ce soit, et très très aléatoire.
En espérant que l'id soit unique, ce qui est censé dépendre surtout
du nombre de caractères ( dans mon cas j'en met 50 ).
A priori, les chaînes de caractères sont absolument aléatoires, bien
que leur génération se fasse sur le mode déterministe.
A 63 caractères différents et 50 caractères, et en supposant qu'il
n'y a pas de doublons du tout ( très peu probable et peu crédible ),
celà nous donnerait : 1 / ( 63 ** (50 - 1)) chaînes différentes possible
environ.
De toute manière, mon critère de fiabilité, est que le même id ne se
produise pas en même temps sur deux visiteurs différents.
Cette fonction est censé rendre un identificateur/chaîne de caractères,
non prévisible de quelque manière que ce soit, et très très aléatoire.
En espérant que l'id soit unique, ce qui est censé dépendre surtout
du nombre de caractères ( dans mon cas j'en met 50 ).
A priori, les chaînes de caractères sont absolument aléatoires, bien
que leur génération se fasse sur le mode déterministe.
A 63 caractères différents et 50 caractères, et en supposant qu'il
n'y a pas de doublons du tout ( très peu probable et peu crédible ),
celà nous donnerait : 1 / ( 63 ** (50 - 1)) chaînes différentes possible
environ.
De toute manière, mon critère de fiabilité, est que le même id ne se
produise pas en même temps sur deux visiteurs différents.
Cette fonction est censé rendre un identificateur/chaîne de caractères,
non prévisible de quelque manière que ce soit, et très très aléatoire.
En espérant que l'id soit unique, ce qui est censé dépendre surtout
du nombre de caractères ( dans mon cas j'en met 50 ).
A priori, les chaînes de caractères sont absolument aléatoires, bien
que leur génération se fasse sur le mode déterministe.
A 63 caractères différents et 50 caractères, et en supposant qu'il
n'y a pas de doublons du tout ( très peu probable et peu crédible ),
celà nous donnerait : 1 / ( 63 ** (50 - 1)) chaînes différentes possible
environ.
De toute manière, mon critère de fiabilité, est que le même id ne se
produise pas en même temps sur deux visiteurs différents.