Bon alors voilà mon problème :
Je crée un cookie via une page en local sur un poste, et j'ai besoin que ce cookie puisse être lisible via une autre page sur un domain précis.
J'ai bien essayé en définissant le domain dans mon cookie, mais ca ne marche pas. Si je ne précise pas le domain, le cookie se cré correctement et je peux voir le fichier créé sur le poste. Mais du coup, il ne peut être lu que par des page en local sur le poste ...  
Par contre, si je précise le domain, je ne vois plus le fichier et il ne peut toujours être lu qu'en local ...  
Y a t'il quelque chose de particulier à faire pour qu'un cookie soit lu sur un autre domaine que celui sur lequel il a été créé ?

demande aux créateurs de spyware c le meme principe

Ben c'est normal tout ça hein. Pour une raison de sécurité les navigateurs n'acceptent que les cookies dont le domaine d'application est bien celui dont est originaire le cookie.
 
Sinon, imagine n'importe quel site pourrait modifier les cookies utilisés par un autre site...

Certe, certes, mais j'ai pensé, sans doute un peu naivement, que si je précisai le domaine, ca pourrai fonctionner ...
En fait le problème de fond, c'est de pouvoir identifié des utilisateur d'une appli sans qu'ils n'aient à saisir login/psswd sur un site. Ils se connectent via une appli en local, et le client ne veut pas mettre en place un système d'autentification classique ... D'où l'idée de l'identifier via un cookie qui serai écrit par l'appli local en lisant un fichier de paramètres. Mais bon, il va falloir trouvé une autre solution alors ...

Identification basée sur l'IP ? Pas génial mais bon...

Ben non, c'est pas possible car ils se connectent tous via un service qui leur donne une IP dynamique ...  
Et evidement, il faut que chaque utilisateur soit identifié précisément par son matricule unique ( information que l'on  trouve sur son disque dur, au moins ,c'est déjà ça )

Mouais. A mon avis tu te fatigueras moins à convaincre ton client de changer d'avis que d'imaginer un système d'authentification aussi peu orthodoxe

Quand l'utilisateur change de serveur, au lieu de faire un bête lien, soumet un formulaire hidden contenant les infos que l'utilisateur a saisi pour s'authentifier la première fois.

C'est exactement l'idée que nous avons retenu.
Les grands esprit se rencontre !
 
> gm_superstar
Impossible de les convaincre, ils ont décidé, pas moyen de discuter ... Dingue ça, obligé de faire un truc cradoc ...

Sinon, si tu utilise IIS et de l'ASP des deux côté, il y a un truc très bien :
 
Server.Transfert(url)
 
=> C'est comme un redirect, mais en plus, ça va tranférer les sessions et variables locales de la page (sauf les objets ActiveX (ADO, FSO, XML, etc.) évidement)

Pas de bol, c'est appli java coté client et servlet coté serveur !

la sessions peut se retrouver sur le 2e serveur, c pas pour ça que le cookie d'origine sera là, donc le client n'aura de toutes façons pas "accès" à la session...
(si j'ai tout bien suivi)

Sisi, le cookie accompagnant la session est migré.
 
Par contre, les cookies créés à la main sont pas transmis. Mais rien n'empêche de créer le cookie depuis le serveur distant à partir des infos locales transmises lors du transfert.