Das Bild oben ist eine HTTP-Anfrage während des Single-Point-Authentifizierungsprozesses von JD.com.
Sein Prozess ist wie folgt: Das heißt, die aktuelle Homepage ist www.jd.com und initiiert dann die Authentifizierung bei sso.jd.hk, indem eine domänenübergreifende Anfrage initiiert wird. Diese Anfrage enthält Cookies und das Cookie wird auch in der Antwort zurückgegeben. Die Domain des in der Antwort zurückgegebenen Cookies wird auf den Domänennamen der ersten Ebene festgelegt.
Ich habe ein paar Fragen,
(1) Dies ist eine domänenübergreifende Anfrage. Warum enthält die Anfrage Cookies? Ist das in Ordnung? Ich habe andere Freunde gesehen, die gesagt haben, dass Kekse mitgeführt werden können
Zum Beispiel http://blog.csdn.net/wzl002/a... Ob Cookie-Einstellungen in domänenübergreifende Ajax-Anfragen einbezogen werden sollen
Aber speziell im Hinblick auf JD.com, wie ist er damit umgegangen?
(2) Cookies werden in der Antwort gesetzt, aber der aktuelle Domainname ist nicht jd.hk, sondern www.jd.com. Wie macht das konkret?
(3) p3p ist in der Antwort eingestellt. Wird das in Frage 2 genannte Problem dadurch gelöst?
(4) p3p kann auf http://blog.csdn.net/ghj1976/...
verweisenDer erwähnte Artikel:
Nach der Einführung von P3P können Sie den Browser so einstellen, dass er automatisch erkennt, ob die Website: personenbezogene Daten sammelt, diese Informationen zur Erstellung von Benutzerprofilen verwendet oder Besuchern erlaubt, die Datenerfassung abzulehnen.P3P-fähige Browser verfügen über einige Standardoptionen, aus denen Sie wählen können. Oder Sie können Ihre Einstellungen anpassen, indem Sie Fragen beantworten, z. B. welche Daten Sie weitergeben möchten und welche Arten von Cookies Sie akzeptieren möchten. Während Sie im Internet surfen, ermittelt diese Software, ob Ihre Datenschutzeinstellungen mit den Datenerfassungspraktiken der Website übereinstimmen.
Mein Verständnis ist: Ein Browser mit P3P-Funktion kann das Schreiben von Cookies über Domänen hinweg erkennen und den Benutzer durch Interaktion mit dem Benutzer fragen, ob er dem Schreiben von Cookies über Domänen hinweg zustimmt? Ähnlich wie bei der häufig vorkommenden Webseiten-Änderungs-Prompt-Interaktion? ? ? ? Dieses Verständnis scheint unvernünftig,
Bitte sagen Sie ein paar Worte (
＾-＾)
![[Web-Frontend] Node.js-Schnellstart](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
搞清楚域名和主机的区别。比如www.jd.com是主机名，不是域名，jd.com是域名。在下图中，如果勾选了hostOnly，则此cookie只在此主机上起作用，换一个主机名www1.jd.com就不起作用了。但如果没有勾选hostOnly，则此cookie在此域名下的任意主机上都是有效的，即使创建此cookie时是在www.jd.com上，但是在www1.jd.com上依然可以读取到此cookie，也就是说，当浏览器访问www1.jd.com时，会把这个cookie作为request的一部分发送给服务器。
Ajax的跨域与此不同。Ajax混淆了域名和主机的区别。在Ajax看来，只要不是在同一主机上发起的请求，都算跨域。比如从www.jd.com上发起一个ajax请求访问www1.jd.com上的内容，这也算跨域。严格来说，这只算跨主机，不能算跨域，但是由于历史原因，现在一直是这么定义的，所以也没有办法改正过来了。
我的建议是自己设计token验证方式，cookie和http请求回复只是传递token的方式。如果你在redis/memcached里存这个token，所有节点都可以通过token查询到当前状态（是否已验证），或者独立写个服务提供验证也是一样的道理。sso.jd.hk用cookie是为了保存验证token和时间戳之类的信息。
token无需保密，直接回复token即可。这种模式同样适合于websocket验证。
常用的计算方法：
token = sha1(数据ID+过期时间戳+验证密码)把token，数据ID，过期时间戳都送给客户，往其它服务发请求的时候附上这3个信息，因为只有服务器知道验证密码，这样就可以验证请求是否来源于另外的服务。AWS资源验证方式和这个类似，只不过把验证密码换成了你的API密匙而已。