Verständnisfrage zu Cookies

Hier könnt ihr alle Fragen zu SpiderBasic austauschen.
Benutzeravatar
dige
Beiträge: 1179
Registriert: 08.09.2004 08:53

Verständnisfrage zu Cookies

Beitrag von dige »

Hallo in die Runde,

ich benötige Cookies für die Client Server Kommunikation.

Mit SpiderBasic kann ich Client seitig mittels Javascript ein Keks speichern und auch wieder lesen.

Mit PureBasic kann ich Server/CGI ebensfalls ein Cookie mitschicken (WriteCGIHeader(#PB_CGI_HeaderSetCookie, ..)

Aber wie schaffe ich es jetzt, dass der Browser bei jedem Ajax Request das Cookie wieder mitsendet?

Code: Alles auswählen

#SpiderBite_Profile = "default"

;{ CGI
EnablePbCgi

#CGI_SUCCESS = "[success]"

ProcedureDll.s CGI_HoleDaten()
  Protected Result.s, k
  
  For k = 0 To CountCGICookies()-1 
    Result + CGICookieName(k)+": " + CGICookieValue(CGICookieName(k)) + #CRLF$
  Next

  ProcedureReturn Result
EndProcedure  
ProcedureDll.s CGI_HoleDaten2()
  ProcedureReturn CGI_HoleDaten()
EndProcedure

ProcedureDll.s CGI_Login (txt.s="")
  WriteCGIHeader(#PB_CGI_HeaderSetCookie  , "sessionid_1=" + txt)
  ProcedureReturn #CGI_SUCCESS
EndProcedure

DisablePbCgi
;}

Procedure SetCookie(name.s, value.s)
 ! document.cookie = v_name + "=" + v_value + "; path=/;"
EndProcedure

Procedure CGI_HoleDaten2Callback( success, Result.s )
  Debug "CGI_HoleDaten2 Result: " + Result

EndProcedure 

Procedure CGI_HoleDatenCallback( success, Result.s )
  Debug "CGI_HoleDaten Result: " + Result
  
  SetCookie("sessionid_2", "xyz")
  CGI_HoleDaten2()
EndProcedure 
 
Procedure CGI_LoginCallback ( success, Result.s )
  Debug "CGI_Login Result: " + Result
  CGI_HoleDaten()
EndProcedure
  
  
CGI_Login ("abcdefg")

Der Browser ruft zunächst CGI_Login() auf und bekommt in der Antwort ein Cookie mitgeliefert.
Wenn dann als nächstes CGI_HoleDaten() aufgerufen wird, wird aber kein Cookie mitgesendet.

Dann SetCookie("sessionid_2", "xyz") im Browser. Laut Debugger im Web-Speicher vorhanden, bis zum Sitzungsende.
Wird aber nicht mitgesendet.

Die Webseite läuft über : http://127.0.0.1:82/SpiderBasic_Compilation0.html
Der CGI Aufruf über : http://127.0.0.1:4001/cgi-bin/PbCgi.exe

Ich verstehe es nicht :(

Kann mich mal jemand bitte richtig rum aufs Pferd setzen?
"Papa, mein Wecker funktioniert nicht! Der weckert immer zu früh."
Benutzeravatar
NicTheQuick
Ein Admin
Beiträge: 8675
Registriert: 29.08.2004 20:20
Computerausstattung: Ryzen 7 5800X, 32 GB DDR4-3200
Ubuntu 22.04.3 LTS
GeForce RTX 3080 Ti
Wohnort: Saarbrücken
Kontaktdaten:

Re: Verständnisfrage zu Cookies

Beitrag von NicTheQuick »

Hast du in der Entwicklerkonsole deines Browser mitgetrackt, ob die Cookies wirklich ankommen und gespeichert werden? Und welchen Browser nutzt du? Hast du mal einen anderen probiert?
Daneben gibt es aber auch noch die Same-origin policy. Das heißt zwei Server mit der selben Domain, aber unterschiedlichen Ports, dürfen keine Daten miteinander austauschen, solange der Access-Control-Allow-Origin-Header nicht vom Backend gesetzt wird. Ich denke das eher letztes dein Problem sein wird.

Ansonsten habe ich von Spiderbasic keine Ahnung. Ich kenne nur die grundlegende Problematik mit Javascript, das von DomainA geladen wird, und dann mit einem Backend auf DomainB kommunizieren soll.
Bild
DarkDragon
Beiträge: 6264
Registriert: 29.08.2004 08:37
Computerausstattung: Hoffentlich bald keine mehr
Kontaktdaten:

Re: Verständnisfrage zu Cookies

Beitrag von DarkDragon »

Ich hatte letztens ähnliche Probleme. Vielleicht als nett gemeinter Hinweis, falls das der Fall ist: sendet der Server einen Content-Security-Policy Header mit sandbox mit? Falls ja ist die Mindestanforderung "sandbox allow-same-origin", sonst hat jede einzelne Resource die man runterlädt einen eigenen Origin und der Browser isoliert alles.

Allerdings wäre es schön, wenn wir hier die Request/Response Headers mal bekommen für die weitere Analyse. Wie NicTheQuick schon sagte kann es
an Access-Control-Allow-Origin liegen.

Hier steht (leider auf Englisch, ich weiß, aber mit vielen Bildern) wie man auf die Netzwerkkommunikation zwischen Browser und Server kommt für Google Chrome:
https://developers.google.com/web/tools ... ls/network

Im übrigen wird hier (insbesondere durch das Sequenzdiagramm) ziemlich gut erklärt was es mit CORS auf sich hat:
https://javascript.info/fetch-crossorigin
Angenommen es gäbe einen Algorithmus mit imaginärer Laufzeit O(i * n), dann gilt O((i * n)^2) = O(-1 * n^2) d.h. wenn man diesen Algorithmus verschachtelt ist er fertig, bevor er angefangen hat.
Benutzeravatar
dige
Beiträge: 1179
Registriert: 08.09.2004 08:53

Re: Verständnisfrage zu Cookies

Beitrag von dige »

NicTheQuick hat geschrieben: Daneben gibt es aber auch noch die Same-origin policy. Das heißt zwei Server mit der selben Domain, aber unterschiedlichen Ports, dürfen keine Daten miteinander austauschen, solange der Access-Control-Allow-Origin-Header nicht vom Backend gesetzt wird. Ich denke das eher letztes dein Problem sein wird.
@Nick: Danke für den Tipp! :allright: Es ist tatsächlich ein Problem, wenn die Ports unterschiedlich sind..
Ich habe das Projekt mal auf einen externen Server gehieft und siehe da, es werden jetzt sogar beide Cookies (vom Client gesetzt und vom Server) mitgesendet.

Was müsste der Server denn - zusätzlich zum Access-Control-Allow-Origin: * - senden, damit dass erlaubt wird?
"Papa, mein Wecker funktioniert nicht! Der weckert immer zu früh."
Benutzeravatar
NicTheQuick
Ein Admin
Beiträge: 8675
Registriert: 29.08.2004 20:20
Computerausstattung: Ryzen 7 5800X, 32 GB DDR4-3200
Ubuntu 22.04.3 LTS
GeForce RTX 3080 Ti
Wohnort: Saarbrücken
Kontaktdaten:

Re: Verständnisfrage zu Cookies

Beitrag von NicTheQuick »

Für die Angular-Entwicklung auf localhost:4200, lasse ich das Backend folgende Header zurückliefern. Das ist jetzt Apache-Syntax.

Code: Alles auswählen

        SetEnvIf Origin "http(s)?://(localhost:4200)$" AccessControlAllowOrigin=$0
        Header set Access-Control-Allow-Origin %{AccessControlAllowOrigin}e env=AccessControlAllowOrigin
        Header set Access-Control-Allow-Credentials true
        Header set Access-Control-Allow-Methods "POST, GET, OPTIONS, PUT"
        Header set Access-Control-Allow-Headers content-type
        Header add Access-Control-Allow-Headers authorization
Wenn also die Protokoll-Socket-Kombination http://localhost:4200 oder https://localhost:4200 eine Anfrage macht, dann wird der Header "Access-Control-Allow-Origin" mit dem der Kombi zurückgeliefert.
Die andere Header sind vielleicht gar nicht so wichtig für dich. Da kannst du notfalls auch * setzen. Aber bei "Access-Control-Allow-Origin" solltest du niemals einfach nur "*" setzen, vor allem nicht, wenn das Backend öffentlich ist. Erlaube es besser nur für alle Domains, die wirklich auf das Backend zugreifen.

Der Browser schickt zunächst einen OPTIONS-Request um herauszufinden, wie er mit dem Backend kommunizieren darf. Das steht aber viel detaillierte in dem Link von DarkDragon.
Bild
Antworten