J'ai créé un site Web (A) qui se connecte et récupère les données client d'un service Web distinct.
L'organisation propriétaire (A) possède également un site Web (B) qui a un formulaire Web. Ils veulent qu'un client connecté sur (A) puisse cliquer sur (B) et voir un formulaire pré-rempli avec leurs coordonnées.
Cela signifie que (A) doit écrire son identifiant client dans un cookie, que (B) peut lire, puis (B) peut demander les données au service Web et pré-remplir le formulaire.
Cela soulève deux questions:
Le site Web (B) peut-il lire le cookie du site Web (A)?
Si oui, pour empêcher quelqu'un de modifier un cookie et de voir les données d'autres personnes dans le formulaire, je devrais faire quelque chose comme crypter le cookie sur (A) puis le décrypter dans (B) - des suggestions le long de cette ligne?
Je ne peux pas changer la connexion existante en OAuth ou quelque chose, car le service Web est consommé par plusieurs autres sites, donc cela ne peut pas changer.
Non. Le site Web B ne peut pas lire un cookie du site Web A.
La solution la plus simple consiste à transmettre les informations de connexion/informations d'identification du site Web A au site Web B et à ce que le site Web B installe un cookie distinct. Par exemple, après vous être connecté au site Web A, vous pouvez les rediriger rapidement vers le site Web B avec une chaîne de requête chiffrée. Le site Web B pourrait alors lire les informations, créer son propre cookie et rediriger l'utilisateur vers le site A.
C'est désordonné mais possible.
Vous avez mentionné que la même entreprise possède les deux sites. Comme vous le soupçonniez, si les sites ont le même domaine comme www.mycompany.com et store.mycompany.com, ils peuvent partager des cookies. L'en-tête de réponse HTTP ressemblerait à ceci:
Set-Cookie: user_id=1295214458; Path=/; Domain=.mycompany.com
Étant donné que le client a un accès direct à ces données, vous devez également inclure une signature afin que la falsification soit détectée. Habituellement, le tout est crypté et signé dans un "jeton", qui est défini comme cookie. Mais techniquement, seule la signature est requise.
Si dans votre cas, tous vos utilisateurs utilisent des navigateurs prenant en charge HTML5, vous pouvez utiliser window.postMessage
méthode qui permet de addEventListener
d'un côté et de postMessage
de l'autre. Voici un article/exemple de Nice: https://developer.mozilla.org/en-US/docs/Web/API/window.postMessage .
Ensuite, les étapes sont simples:
Les cookies ne sont accessibles qu'à un seul domaine sur lequel ils sont définis.
Je crois que si vous utilisez deux sous-domaines sur le même domaine, il serait possible de partager les cookies, mais le navigateur n'envoie pas de cookies définis sur un domaine à un autre.
Modifier: vous voulez également éviter de stocker de grandes quantités de données dans un cookie. Y a-t-il peut-être une chance que vous puissiez créer une API que le site B pourrait interroger avec javascript?
Il existe des outils open source sur Internet qui peuvent le faire, mais cela va à l'encontre de l'idée derrière la philosophie des cookies. Les cookies sont destinés à être accessibles par un seul domaine. Vous pouvez cependant vous moquer de ce domaine et "pirater" dans le navigateur. Ce n'est pas recommandé et certains navigateurs ont une sécurité plus stricte et ne permettent pas cela.
Je vous suggère de créer un service Web dans le site Web A et de donner un accès en lecture à B pour le lire.
Solution de contournement potentielle: vous pouvez utiliser un cadre en ligne sur le site secondaire pour afficher le contenu du site principal (en prenant la fenêtre complète):
<!DOCTYPE HTML>
<html>
<head>
<title>your page title</title>
<style type="text/css">
body, html {
margin: 0; padding: 0; height: 100%; overflow: hidden;
}
#content {
position:absolute; left: 0; right: 0; bottom: 0; top: 0px;
}
</style>
</head>
<body>
<div id="content">
<iframe width="100%" height="100%" frameborder="0" src="http://yourMainSite.com/dataDependentPage.php" ></iframe>
TESTING
</div>
</body>
</html>