L'image ci-dessus est une requête http lors du processus d'authentification en un seul point de JD.com.
Son processus est le suivant : c'est-à-dire que la page d'accueil actuelle est www.jd.com, puis elle initie l'authentification auprès de sso.jd.hk en lançant une requête inter-domaines. Cette demande transporte des cookies et le cookie est également renvoyé dans la réponse. La domina du cookie renvoyé dans la réponse est définie sur le nom de domaine de premier niveau.
J'ai quelques questions,
(1) Il s'agit d'une requête inter-domaines. Pourquoi la requête contient-elle des cookies ? Est-ce que ça va ? J'ai vu d'autres amis dire que les cookies peuvent être emportés
Par exemple, http://blog.csdn.net/wzl002/a... S'il faut inclure les paramètres de cookies dans les requêtes Ajax inter-domaines
Mais spécifiquement concernant JD.com, comment a-t-il géré cela ?
(2) Les cookies sont définis dans la réponse, mais le nom de domaine actuel n'est pas jd.hk, mais www.jd.com. Cela peut-il être défini spécifiquement, comment JD.com le fait-il ?
(3) p3p est défini dans la réponse. Le problème mentionné à la question 2 est-il résolu grâce à cela ?
(4) p3p peut faire référence à http://blog.csdn.net/ghj1976/...
L'article mentionne :
Après avoir adopté le P3P, vous pouvez configurer le navigateur pour qu'il détecte automatiquement si le site Web : collecte des informations personnellement identifiables, utilise ces informations pour créer des profils d'utilisateurs ou permet aux visiteurs de refuser la collecte de données.Les navigateurs compatibles P3P proposent des options par défaut parmi lesquelles vous pouvez choisir. Vous pouvez également personnaliser vos paramètres en répondant à des questions telles que les données que vous êtes prêt à partager et les types de cookies que vous êtes prêt à accepter. Lorsque vous naviguez sur le Web, ce logiciel détermine si vos préférences en matière de confidentialité correspondent aux pratiques de collecte de données du site Web.
Ma compréhension est la suivante : un navigateur doté de la fonction p3p peut détecter l'écriture de cookies sur plusieurs domaines et demander à l'utilisateur en interagissant avec l'utilisateur s'il accepte l'écriture de cookies sur plusieurs domaines ? Semblable à l’interaction rapide de modification de page Web qui se produit fréquemment ? ? ? ? Cette compréhension semble déraisonnable,
Veuillez dire quelques mots (
＾-＾)
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Comprenez la différence entre les noms de domaine et les hébergeurs. Par exemple, www.jd.com est le nom d'hôte, pas le nom de domaine, et jd.com est le nom de domaine. Dans l'image ci-dessous, si hostOnly est coché, ce cookie ne fonctionnera que sur cet hôte. La modification du nom d'hôte www1.jd.com ne fonctionnera pas. Mais si hostOnly n'est pas coché, ce cookie est valable sur n'importe quel hébergeur sous ce nom de domaine Même si ce cookie est créé sur www.jd.com, il est toujours lisible sur www1.jd.com Ce cookie, c'est-à-dire. , lorsque le navigateur visite www1.jd.com, ce cookie sera envoyé au serveur dans le cadre de la requête.
Le cross-domain Ajax est différent de cela. Ajax confond la différence entre nom de domaine et hôte. Du point de vue d'Ajax, tant que la requête n'est pas initiée sur le même hôte, elle est considérée comme multi-domaine. Par exemple, si vous lancez une requête ajax depuis www.jd.com pour accéder au contenu de www1.jd.com, cela est également considéré comme interdomaine. À proprement parler, cela ne compte que comme étant inter-hôtes, et non inter-domaines. Cependant, pour des raisons historiques, cela a toujours été défini de cette façon, il n'y a donc aucun moyen de le corriger.
Ma suggestion est de concevoir vous-même la méthode de vérification du jeton. Les cookies et les réponses aux requêtes http ne sont que des moyens de transmettre le jeton. Si vous stockez ce jeton dans redis/memcached, tous les nœuds peuvent interroger l'état actuel (s'il a été vérifié) via le jeton, ou écrire un service indépendant pour fournir une vérification pour la même raison. sso.jd.hk utilise des cookies pour enregistrer des informations telles que des jetons de vérification et des horodatages.
Le jeton n'a pas besoin d'être gardé secret, il suffit de répondre directement avec le jeton. Ce mode convient également à l'authentification Websocket.
Méthodes de calcul couramment utilisées :
token = sha1(数据ID+过期时间戳+验证密码)Envoyez le jeton, l'ID de données et l'horodatage d'expiration au client, et joignez ces trois informations lors de l'envoi de demandes à d'autres services, car seul le serveur connaît le mot de passe de vérification, vous pouvez donc vérifier si la demande provient d'un autre service. La méthode de vérification des ressources AWS est similaire à celle-ci, sauf que le mot de passe de vérification est remplacé par votre clé API.