Angenommen, ich habe eine Schnittstelle zum Erhalten von Bestätigungscodes. Sie befindet sich unter https://api.b.com/captcha.
Meiner Vorstellung nach wird die Aktualisierungsfunktion des Bestätigungscodes durch das Hinzufügen eines Zeitstempels nach der URL implementiert, beispielsweise durch Ändern der URL in etwa so
https://api.b.com/captcha?149...
Der herkömmliche Bestätigungscode sollte hauptsächlich über die Sitzung erfolgen. Das Frontend zeichnet eine Sitzungs-ID im Cookie auf.
Das Backend zeichnet diese Sitzungs-ID und den entsprechenden Bestätigungscode auch in Redis auf.
Das Frontend verfügt über eine Funktion zum Aktualisieren des Bestätigungscodes, indem Sie darauf klicken. Bei jedem Klick wird ein neuer Bestätigungscode generiert und der Wert des Bestätigungscodes, der der Sitzungs-ID entspricht, wird jedes Mal in Redis aktualisiert.
Die Überprüfungsmethode wird abgeschlossen, indem abgefragt wird, ob der Sitzungs-ID-Wert in Redis mit dem Front-End-Wert übereinstimmt.
Jetzt arbeite ich an einem Projekt, das Front- und Back-End trennt.
Dann gibt es ein domänenübergreifendes Cookie-Problem, das ich nicht lösen kann.
Das Szenario sieht wie folgt aus: Das Front-End-Projekt befindet sich unter dem Domänennamen www.a.com und das Back-End-Projekt unter dem Domänennamen api.b.com.
Das Front-End und das Back-End laufen unter unterschiedlichen Domänennamen (tatsächlich ist es auch möglich, die beiden Projekte unter demselben Domänennamen zu platzieren, dies geschieht jedoch nicht zu Lernzwecken), sodass das Cookie nicht geteilt werden kann. Mit anderen Worten, ich kann die Sitzungs-ID nicht erhalten. Dann scheint die traditionelle Methode nicht mehr möglich zu sein.
PS: Der Front-End-Server verwendet Nginx und das Back-End verwendet Spring-Boot.
Ich möchte ein einfaches Token generieren. Das Token enthält nur eine UUID, die zur Identifizierung des Benutzers verwendet wird. Ich vergleiche die UUID dieses Tokens mit der UUID in Redis, um festzustellen, ob der Wert des Bestätigungscodes korrekt ist. Ich werde also ein Ergebnis wie dieses zurückgeben
{
image : base64转码后的图片,
token : uuid
}
Der Grund, warum wir Base64-transkodierte Bilder veröffentlichen, liegt hauptsächlich daran, dass das Front-End-IMG-Tag Base64 unterstützt. Es ist kein Problem, dies direkt anzuzeigen (es ist kein Projekt, das alte Browser nicht berücksichtigt).
Aber es scheint nicht sehr sinnvoll, es auf diese Weise zu tun. Denn auf diese Weise können Sie beim Zugriff auf die Adresse des Bestätigungscodes das Bild des Bestätigungscodes nicht sehen. Es ist unpraktisch, den Verifizierungscodestil zu debuggen und anzuzeigen. Es ist nur so, dass ich ein js schreiben muss, um den SRC des IMG festzulegen.
Fügen Sie das Token in den Header der Antwort ein. js kann den Inhalt des Antwortheaders lesen. Dann kann das Bild des Verifizierungscodes auch direkt über die Adresse angezeigt werden. Aber verdammt, es fühlt sich auch dumm an. Weil ich den Bestätigungscode nicht so aktualisieren kann, wie ich es mir vorgestellt habe. Fügen Sie einfach später einen Zeitstempel hinzu und ändern Sie ihn.
Der Bestätigungscode ist mir egal. Überprüfen Sie beim Anmelden den Bestätigungscode auf dem Front-End-Server. Dann überprüft mein Back-End nur, ob das Kontokennwort korrekt ist ein Token. Bringen Sie das Token einfach jedes Mal mit, wenn Sie auf andere APIs zugreifen.
Ich weiß wirklich nicht, wie ich das machen soll, und ich kann keine relevanten Informationen finden (vielleicht stimmt etwas mit meiner Suchmethode nicht), also bitte ich um Hilfe...
Ich habe sorgfältig nachgesehen und dieses Problem sollte ein Single-Sign-On-Problem sein, oder?
你要解决的是跨域携带cookie的问题。首先要确定你跨域使用的是cors技术,cors可以基于 HTTP cookies 和 HTTP 认证信息发送身份凭证。 通过XMLHttpRequest 的 withCredentials 标志设置为 true,从而向服务器发送 Cookies。
除了前端发请求要添加withCredential外,服务器的响应头也需要添加
Access-Control-Allow-Credentials: true
。另外,响应头不能设置 Access-Control-Allow-Origin 的值为“*”,必须设为具体的源 http://foo.example。