Comment stocker de gros cookies efficacement ?
Posté : 06 mars 2006, 01:12
Je doute qu'il existe une solution à mon problème mais je profite d'avoir accès à de brillants cerveaux tels que les vôtres pour confirmer mon doute. 
Postulat: je réfléchis à un système de forum (oui, le 125874ème projet de forum PHP) qui s'appuirait énormément sur le stockage d'informations dans des cookies. Notamment, les topics lus. Je n'ai pas encore profondément songé à l'implémentation, mais chaque topic lu demanderait entre 6 et 8 octets de stockage. Le stockage étant réparti sur plusieurs topics pour éviter d'atteindre la limite de taille par cookie. (par exemple, en basant le nom du cookie sur "topic_id % nb_cookies")
Mon problème est le suivant: même si on peut les délester périodiquement, ces cookies peuvent rapidement devenir relativement gros donc je suis à la recherche d'une solution qui me permettrait d'exploiter un cookie en javascript sans qu'il soit transmis dans la requête HTTP. Bon, à priori c'est impossible, mais je n'aime pas ce mot
(non, je ne suis pas l'identité secrète de Super Dupont)
J'ai exploré différentes approches, pour l'instant la moins pire consiste à définir le "cookie path" sur l'adresse du script qui liste les topics. Par exemple, "Set-cookie: [...]; path=/viewforum.php". Étonnamment, ça fonctionne et l'en-tête "Cookie" n'est envoyé qu'à viewforum.php (qui d'ailleurs, ne s'appelle pas viewforum.php car on a également besoin de ces informations dans viewtopic.php, mais l'exemple reste valide). La prochaine étape pour moi est de ne pas envoyer ce Cookie même si la page demandée est viewforum.php... une idée ?
Une autre piste, explorée puis abandonnée, était de définir comme path l'adresse d'un script Javascript. L'idée était d'avoir un script qui s'occupe de changer les images des topics (lu/non-lu) et de limiter le scope des cookies à ce script uniquement. En définissant une date d'expiration lointaine, aucune requête ne part donc aucun transfert. J'ai trouvé cette idée tellement démoniaque que j'ai ri comme le Dr Evil pendant au moins deux minutes. Bon... après ça j'ai cherché comment récupérer le cookie à part du script et je me suis aperçu que le seul cookie auquel on pouvait accéder était document.cookie, donc impossible d'associer un cookie avec un javascript. Si j'ai tort, merci de me corriger, je vous en serai éternellement reconnaissant.
Il me reste encore une troisième piste à explorer, mais je me doute que si elle fonctionne ce ne sera que le hasard d'une faille d'implémentation de Firefox. Je me demande si en trichant avec un header "Content-location" ou "Content-base" on pourrait accéder à un cookie associé au même domaine mais avec un autre path. Auquel cas, il suffirait de définir un path inexistant (de ce fait, aucune requête ne l'enverra au serveur) et utiliser ce path dans un "Content-location" pour y accéder via document.cookie. Relativement tiré par les cheveux.
Tous les commentaires sont les bienvenus, merci.
Postulat: je réfléchis à un système de forum (oui, le 125874ème projet de forum PHP) qui s'appuirait énormément sur le stockage d'informations dans des cookies. Notamment, les topics lus. Je n'ai pas encore profondément songé à l'implémentation, mais chaque topic lu demanderait entre 6 et 8 octets de stockage. Le stockage étant réparti sur plusieurs topics pour éviter d'atteindre la limite de taille par cookie. (par exemple, en basant le nom du cookie sur "topic_id % nb_cookies")
Mon problème est le suivant: même si on peut les délester périodiquement, ces cookies peuvent rapidement devenir relativement gros donc je suis à la recherche d'une solution qui me permettrait d'exploiter un cookie en javascript sans qu'il soit transmis dans la requête HTTP. Bon, à priori c'est impossible, mais je n'aime pas ce mot
(non, je ne suis pas l'identité secrète de Super Dupont)J'ai exploré différentes approches, pour l'instant la moins pire consiste à définir le "cookie path" sur l'adresse du script qui liste les topics. Par exemple, "Set-cookie: [...]; path=/viewforum.php". Étonnamment, ça fonctionne et l'en-tête "Cookie" n'est envoyé qu'à viewforum.php (qui d'ailleurs, ne s'appelle pas viewforum.php car on a également besoin de ces informations dans viewtopic.php, mais l'exemple reste valide). La prochaine étape pour moi est de ne pas envoyer ce Cookie même si la page demandée est viewforum.php... une idée ?
Une autre piste, explorée puis abandonnée, était de définir comme path l'adresse d'un script Javascript. L'idée était d'avoir un script qui s'occupe de changer les images des topics (lu/non-lu) et de limiter le scope des cookies à ce script uniquement. En définissant une date d'expiration lointaine, aucune requête ne part donc aucun transfert. J'ai trouvé cette idée tellement démoniaque que j'ai ri comme le Dr Evil pendant au moins deux minutes. Bon... après ça j'ai cherché comment récupérer le cookie à part du script et je me suis aperçu que le seul cookie auquel on pouvait accéder était document.cookie, donc impossible d'associer un cookie avec un javascript. Si j'ai tort, merci de me corriger, je vous en serai éternellement reconnaissant.
Il me reste encore une troisième piste à explorer, mais je me doute que si elle fonctionne ce ne sera que le hasard d'une faille d'implémentation de Firefox. Je me demande si en trichant avec un header "Content-location" ou "Content-base" on pourrait accéder à un cookie associé au même domaine mais avec un autre path. Auquel cas, il suffirait de définir un path inexistant (de ce fait, aucune requête ne l'enverra au serveur) et utiliser ce path dans un "Content-location" pour y accéder via document.cookie. Relativement tiré par les cheveux.
Tous les commentaires sont les bienvenus, merci.
) et tout porte à croire que le design est suffisament "vérouillé" pour que ce que j'essaie d'accomplir soit impossible. D'ailleurs, durant mes recherches j'ai découvert que ma technique à base de Content-location était plus ou moins à l'origine d'une faille de sécurité d'IE (patchée depuis deux ans).