Leopoldo Ghielmetti wrote:
Si j'ai bien compris les opÃrations sont les suivantes:
- accÃs au webmin local
- webmin stocke un coockie local
- accÃs au site "pirate"
- le site "pirate" inclut un lien sur le webmin local
- le brower envoie la requÃte au webmin
- le webmin demande le cookie
- le browser controle que le site demandeur (webmin) Ã bien le droit de
lire le cookie (gÃnÃrà par webmin lui mÃme). rÃponse: Oui
- le browser envoie le cookie au webmin
Le fonctionnement des cookie est plus simple.
Note : je ne connais pas Webmin, mais j'imagine qu'il utilise une
implÃmentation typique.
1) AccÃs à Webmin incluant les donnÃes d'identification.
2) RÃponse de Webmin contenant le cookie qui contient les donnÃes
d'identifications validÃes (un identifiant de session par exemple).
3) Le navigateur stocke le cookie localement. Le cookie (soit
l'identifiant de session) sera automatiquement inclu dans les
requÃtes suivantes à Webmin.
4) AccÃs à une quelconque page hors de Webmin.
5) La page quelconque cause l'envoi d'une requÃte (par exemple sous
prÃtexte de charger une image) Ã Webmin.
C'est là que tout se joue. Le navigateur va-tÂ-il ou non envoyer le
cookie dans la requÃte à Webmin ?
- Si le cookie n'est pas envoyÃ, Webmin ne sait pas de qui vient la
requÃte et la rejette.
- Si le cookie est envoyÃ, Webmin reconnaÃt son identifiant de
session et procÃde...
Les anciens navigateurs envoyaient le cookie. C'Ãtait notamment exploitÃ
par les sites collectant des infos sur les visites.
Les nouveaux navigateurs (AFAIK) n'envoient pas le cookie avec la
requÃte pour l'image car la requÃte est initiÃe par une page ne venant
pas du mÃme site.
La documentation historique sur les cookies est disponible Ã
http://wp.netscape.com/newsref/std/cookie_spec.html
Marc Mongenet
_______________________________________________
gull mailing list
[email protected]
http://lists.alphanet.ch/mailman/listinfo/gull
