Quand même, je ne comprends pas pourquoi mon idée de session mouvante ne
marcherait pas : les cookies sont stockés de manière centralisée dans le
navigateur, et pas fenêtre par fenêtre. Et la page ne contient pas d'infos
sur la session, donc il n'y a pas de problème de cache !
Ci-joint un fichier à placer à la racine, qu'on pourrait appeler à la place
d'une quelconque des icônes dans l'espace privé, et qui changer le numéro
de session à chaque passage sur l'image. C'est à dire, en gros, à chaque
rechargement d'une page. Il faut que l'image soit toute petite et vers la
fin de la page. Et eventuellement que ça soit débranchable si ça énerve les
gens de se faire cookifier à chaque connexion. Mais là on est totalement
sécure !
Je persiste dans l'erreur, peut-être, mais je ne vois pas en quoi j'ai faux.
Plus sérieusement, le problème : le fichier est appelé en GET,
du coup on peut avoir les mêmes problèmes qu'avec les rubriques
créées de façon parasite. A savoir qu'un navigateur ou un proxy
peut très bien décider de faire une requête supplémentaire sur
cette image sans forcément en prendre en compte le résultat
(par exemple le navigateur fait un HEAD pour savoir si le fichier
a "changé" et il ne regarde pas les cookies qui lui sont renvoyés).
Après, il y a une désynchronisation entre la session telle qu'elle
est stockée dans ecrire/data d'une part, et dans le cookie d'autre
part.
Je vois... Est-ce un comportement standard ? Courant ? Est-ce qu'on peut
tester le navigateur avant de renouveller la session ? Rejouer la session au
minimum quand on passe dans l'espace public ? etc.
Je vois... Est-ce un comportement standard ? Courant ? Est-ce qu'on peut
tester le navigateur avant de renouveller la session ? Rejouer la session au
minimum quand on passe dans l'espace public ? etc.
- autorisé par le standard : oui
- courant : plusieurs personnes ont rapporté le problème des
rubriques créées plusieurs fois, et je l'ai reproduit sans
effort avec IE. Donc assez courant.
- tester le navigateur : ça implique de connaître le comportement
de tous les navigateurs et de tous les proxies. Impossible.
Une possibilité : détecter quand la page est envoyée en POST, et
changer la session à ce moment-là. Comme ça, de temps en temps, la
session change.
De toute façon, quelque soit la méthode, le cookie peut être rejoué
dès que l'utilisateur ne fait plus rien (même pendant 10 minutes) :
est-ce vraiment utile de se compliquer la vie ?
les cookies sont stockés de manière centralisée dans le navigateur,
et pas fenêtre par fenêtre.
Attention, cela est à priori vrai pour les cookies durables, mais pas
pour les cookies de session.
Dans IE, par exemple, on peut choisir le fait d'avoir un process
différent pour chaque fenêtre (ce qui évite de tout faire disparaître
quand on doit en "killer" une, d'ailleurs), et les cookies de session
ne sont alors pas partagés.
Une possibilité : détecter quand la page est envoyée en POST, et
changer la session à ce moment-là. Comme ça, de temps en temps, la
session change.
marchera pas, car il faut faire ce boulot à la racine, pas dans ecrire/
est-ce vraiment utile de se compliquer la vie ?
oui ! on peut, dans l'image qui rejoue (c'est le terme?) la session,
vérifier que l'entête est bien GET et pas HEAD (via getallheaders(), à
condition d'être en module). Et mettre les entêtes Expire:, No-Cache: etc...
qui obligent le brouteur à bien recharger.
> les cookies sont stockés de manière centralisée dans le navigateur,
> et pas fenêtre par fenêtre.
Attention, cela est à priori vrai pour les cookies durables, mais pas
pour les cookies de session.
Dans IE, par exemple, on peut choisir le fait d'avoir un process
différent pour chaque fenêtre (ce qui évite de tout faire disparaître
quand on doit en "killer" une, d'ailleurs), et les cookies de session
ne sont alors pas partagés.
Intéressant. Mais dans ce cas de figure il faudrait se loger dans chacune
des fenêtres, non ? Donc ouvrir plusieurs sessions, chacune étant rejouée de
manière indépendante...
vérifier que l'entête est bien GET et pas HEAD (via getallheaders(), à
condition d'être en module).
Pas la peine donc
Explique ? Si on peut le faire bien dans le cas d'un mod_php sur apache
seulement, ça vaut le coup quand même.
De toute façon ce n'est pas le seul cas qui pose problème. Un proxy peut
très bien charger la page avec un HEAD pour se l'enregistrer dans un coin,
ou toute autre bizarrerie. Et après quand quelqu'un aura un problème ce
sera la merde intégrale pour débugger en aveugle, ou même pour diagnostiquer
le truc.
Et mettre les entêtes Expire:, No-Cache: etc...
qui obligent le brouteur à bien recharger.
Ca ne change rien au problème, comme pour les rubriques en double.
idem ?
Ben, les rubriques étaient créées en double alors que la page qui
les créait (rubriques_edit je crois) avait tout l'arsenal des headers
anti-proxy. Donc ça ne protège pas contre un appel en double. Juste
contre la réutilisation d'une version chargée précédemment.
De toute façon ce n'est pas le seul cas qui pose problème. Un proxy peut
très bien charger la page avec un HEAD pour se l'enregistrer dans un coin,
ou toute autre bizarrerie.
Ca fait un peu magie noire ton truc ! Pourquoi un proxy se mettrait-il à
envoyer une requête AVEC LE COOKIE DE SESSION VALIDE ??
A mon avis on peut essayer de le faire au mieux, et le tester sur uZine ou
ailleurs, en le proposant en option, au départ, à la convenance des
webmestres. On verra bien si on nous signale des déconnexions intempestives.
Il suffirait de mettre un message (le temps des tests intensifs) sur la page
login.php3 : "si vous estimez subir des déconnexions intempestives, votre
expérience avec spip nous intéresse", un machin comme ça.... Ca vaut le
coup d'avoir une gestion de sessions totalement bétonnée.
Ben, les rubriques étaient créées en double alors que la page qui
les créait (rubriques_edit je crois) avait tout l'arsenal des headers
J'ai l'impression que le patch contre les rubriques en double est merdique
de chez merdique. Laisser se créer un machin pour l'effacer après, c'est pas
génial. Mais comme je n'arrive pas à avoir ce bug...
Ca fait un peu magie noire ton truc ! Pourquoi un proxy se mettrait-il à
envoyer une requête AVEC LE COOKIE DE SESSION VALIDE ??
Le problème, c'est que comme le standard autorise ce genre de trucs,
il y a des fois des trucs genre magie noire qui se produisent (il suffit
de rencontrer des programmeurs pour se rendre compte qu'ils sont loin
d'avoir tous une façon très logique de résoudre les problèmes qu'on
leur file ;-))). Tiens, un autre truc marrant : sous d'anciennes
versions de Netscape (4.x), quand on resizait la fenêtre, il rechargeait
la page depuis le serveur (sauf avec une page en POST...)
Alors, tu comprends que je méfie des browsers programmés avec les pieds
A mon avis on peut essayer de le faire au mieux, et le tester sur uZine ou
ailleurs, en le proposant en option, au départ, à la convenance des
webmestres. On verra bien si on nous signale des déconnexions intempestives.
Il suffirait de mettre un message (le temps des tests intensifs) sur la page
login.php3 : "si vous estimez subir des déconnexions intempestives, votre
expérience avec spip nous intéresse", un machin comme ça.... Ca vaut le
coup d'avoir une gestion de sessions totalement bétonnée.
Tu peux essayer si tu veux, mais je refuse de m'occuper d'un tel machin ;))
Du reste, comme dit auparavant ça ne bétonne rien puisqu'on peut rejouer
le cookie à la moindre période d'inactivité de l'utilisateur (et il y en a
forcément).
J'ai l'impression que le patch contre les rubriques en double est merdique
de chez merdique. Laisser se créer un machin pour l'effacer après, c'est pas
génial. Mais comme je n'arrive pas à avoir ce bug...
Non, ça c'était le patch d'Arno, qui ne marchait qu'une fois sur deux. Le
mien devrait être propre (la rubrique est créée au moment du POST, donc pas
de requête parasite).
J'ai l'impression que le patch contre les rubriques en double est merdique
de chez merdique. Laisser se créer un machin pour l'effacer après, c'est pas
génial. Mais comme je n'arrive pas à avoir ce bug...
A ce propos, on devrait ajouter dans inc_version et inc-public des éléments
permettant de renvoyer ce qu'il faut en cas de requête de type HEAD
(qu'on peut chopper, je crois, avec $REQUEST_METHOD == 'HEAD')
Dans ecrire/ : bloquer tout calcul : { exit; }
Dans inc-public : rechercher le fichier cache. S'il existe, renvoyer les
entêtes Last_modified: correspondant, sinon renvoyer Un Last-Modified
de la date courante. Dans les deux cas ne pas calculer le fichier cache,
ni l'interpréter.
Du reste, comme dit auparavant ça ne bétonne rien puisqu'on peut rejouer
le cookie à la moindre période d'inactivité de l'utilisateur (et il y en a
forcément).
Il faudrait savoir dans quel ordre se font 1) le chargement de l'image en
bas de page et 2) l'exécution d'un éventuel jajascript voleur dans la page.
Si jaja est exécuté AVANT le chargement de l'image, le cookie volé est mort.
Sinon il est bon...
Hi hi! Tu as raison ! Si on veut en être totalement CERTAIN, au lieu d'un
appel d'image il suffit d'une ligne de... jaja, placée en fin de page (donc
après un éventuel voleur), qui fait changer le numéro de session.
Non, ça c'était le patch d'Arno, qui ne marchait qu'une fois sur deux. Le
mien devrait être propre (la rubrique est créée au moment du POST, donc pas
de requête parasite).
A ce propos, on devrait ajouter dans inc_version et inc-public des éléments
permettant de renvoyer ce qu'il faut en cas de requête de type HEAD
(qu'on peut chopper, je crois, avec $REQUEST_METHOD == 'HEAD')
Dans ecrire/ : bloquer tout calcul : { exit; }
Heu, comme pour l'image-rechargeuse-de-session, je me méfie de l'effet que
peut avoir ce genre de choses. D'autre part, l'espace privé a un impact très
limité sur la charge d'un site, à mon avis.
Dans inc-public : rechercher le fichier cache. S'il existe, renvoyer les
entêtes Last_modified: correspondant, sinon renvoyer Un Last-Modified
de la date courante. Dans les deux cas ne pas calculer le fichier cache,
ni l'interpréter.
On a déjà ça dans inc-cache.php3 :
if ($HTTP_SERVER_VARS['REQUEST_METHOD'] == 'HEAD') {
$use_cache = true;
}
Bon, je vais faire quelques stats sur uzine.net, pour voir s'il y a bcp de
REQUEST_METHOD = HEAD.
Il faudrait savoir dans quel ordre se font 1) le chargement de l'image en
bas de page et 2) l'exécution d'un éventuel jajascript voleur dans la page.
Ah, c'est pour ça le coup de l'image... Je n'y pensais pas.
La réponse est : on n'en sait rien
Hi hi! Tu as raison ! Si on veut en être totalement CERTAIN, au lieu d'un
appel d'image il suffit d'une ligne de... jaja, placée en fin de page (donc
après un éventuel voleur), qui fait changer le numéro de session.
