Linuchs: COOKIES mit PHP und Javascript setzen und lesen

problematische Seite

Moin,

seit 2008 setze und lese ich Cookies mit PHP und Javascript. Manchmal dachte ich, ich hätte diese Kunst verstanden.

Doch heute bricht wieder alles zusammen. The COOKIE['my_ORT'] zum Ort „Berkach“ mag nicht weichen, wenn ich erfolgreich den Ort „Wallerstädten“ gefunden habe.

Auf der problematischen Seite kann ich einen Ort als Text, z.B. „Berkach“ eingeben oder beim Tippen aus Vorschlägen wählen. Wenn ich einen Vorschlag anklicke, habe ich auch die eindeutige ort_id. Ein Text, etwa „Neustadt“ kann viele Treffer erzielen.

Ich suche die id oder den Text in der Datenbank und wenn genau ein Treffer erzielt wird, setze ich the COOKIE['my_ORT']:

  if ( @mysql_num_rows( $res_zentrum ) == 1 ) {
    // korrekte Suche setzt Cookie
    $cookie_ende   = time() +90 *24 *60 *60;  // 90 Tage
    setcookie( 'my_ORT', $row_zentrum['id'], $cookie_ende, '/' );
  }

Aber das funktioniert nur einmal. Ich erwarte aber, dass the COOKIE beim nächsten Treffer mit einem neuen Wert überschrieben wird.

Womöglich habe ich mich im Gestrüpp von http und https sowie in den Verzeichnissen verlaufen. Die COOKIE-Dokumentation ist schwammig, lädt zum lustigen Testen ein.

Ich möchte Folgendes erreichen:

COOKIE['my_ORT'] möge für alle Seiten von http://remso.eu, http://www.remso.eu, https://remso.eu und https://www.remso.eu gelten.

Wie finde und ändere ich this COOKIE aus der Sicht von PHP und aus der Sicht von Javascript?

Gruß. Linuchs

  1. problematische Seite

    Hallo Linuchs,

    Ich möchte Folgendes erreichen:

    COOKIE['my_ORT'] möge für alle Seiten von http://remso.eu, http://www.remso.eu, https://remso.eu und https://www.remso.eu gelten.

    Meines Wissens geht das nicht. Ein Cookie gilt immer nur für eine Domain.

    Bis demnächst
    Matthias

    --
    Du kannst das Projekt SELFHTML unterstützen,
    indem du bei Amazon-Einkäufen Amazon smile (Was ist das?) nutzt.
    1. problematische Seite

      Hi,

      COOKIE['my_ORT'] möge für alle Seiten von http://remso.eu, http://www.remso.eu, https://remso.eu und https://www.remso.eu gelten.

      Meines Wissens geht das nicht. Ein Cookie gilt immer nur für eine Domain.

      IIRC geht es auch für mehrere Domains, solange sie alle unter einer übergeordneten Domain liegen.

      Also für www.example.org und bla.www.example.org und blubb.example.org kann man einen gemeinsamen Cookie setzen (beim Setzen .example.org angeben).

      cu,
      Andreas a/k/a MudGuard

      1. problematische Seite

        Hi,

        COOKIE['my_ORT'] möge für alle Seiten von http://remso.eu, http://www.remso.eu, https://remso.eu und https://www.remso.eu gelten.

        Meines Wissens geht das nicht. Ein Cookie gilt immer nur für eine Domain.

        IIRC geht es auch für mehrere Domains, solange sie alle unter einer übergeordneten Domain liegen.

        Also für www.example.org und bla.www.example.org und blubb.example.org kann man einen gemeinsamen Cookie setzen (beim Setzen .example.org angeben).

        Dieses Verhalten kann man beim Komponieren des Cookies steuern. Ob dann der Browser später den Wunsch erfüllt, kann man selbstverständlich nie genau wissen.

        LG
        localhost

    2. problematische Seite

      Hallo Matthias,

      Ein Cookie gilt immer nur für eine Domain.

      Lass uns klären, was du meinst. remso.eu ist eine Domain, remso.de eine andere. www.remso.eu ist eine Sub-Domain zu remso.eu.

      Hmm ... also www.remso.eu und remso.eu ist dieselbe Domain?

      Gehören die Vorsilben http:// und https:// auch zur Domain? Nein, das sind die Übertragungsprotokolle zu den Domains ???

      Demnach müssen doch http://www.remso.eu, http://remso.eu, https://www.remso.eu und https://remso.eu gemeinsame Cookies haben.

      Richtig?

      Linuchs

      1. problematische Seite

        Hallo Linuchs,

        Richtig. Ich habe ungenau gelesen.

        Bis demnächst
        Matthias

        --
        Du kannst das Projekt SELFHTML unterstützen,
        indem du bei Amazon-Einkäufen Amazon smile (Was ist das?) nutzt.
        1. problematische Seite

          Hallo Matthias,

          vermutlich begrenzt richtig. setcookie hat noch weitere Parameter, und der erste, den Linuchs weggelassen hat, heißt domain. Den muss man vermutlich auf "remso.eu" setzen, damit ein Cookie, der auf www.remso.eu gesetzt wurde, auf remso.eu sichtbar ist.

          Rolf

          --
          sumpsi - posui - obstruxi
          1. problematische Seite

            Hallo Rolf,

            habe nun domain hinzugefügt:

            $bia_domain = "remso.eu";
            $cookie_ende   = time() +90 *24 *60 *60;  // 90 Tage
            setcookie( 'my_ORT', $row_zentrum['id'], $cookie_ende, '/', $bia_domain );  // für remso.de und www.remso.de
            

            Nun habe ich zwei COOKIE['my_ORT']

            Muss mal eben raus aus Firefox (Cookies löschen), bin gleich wieder da.

            1. problematische Seite

              Habe nun COOKIE['my_ORT'] unter http://remso.eu gesetzt und finde es wieder unter

              http://remso.eu

              http://www.remso.eu

              https://remso.eu

              https://www.remso.eu

              Doch nun fällt ein anderes Problem auf (vermutlich bisher verdeckt). Bei Änderung des Ortsnamens soll Ajax Vorschläge holen. Das klappt nicht auf

              http://www.remso.eu

              https://www.remso.eu

              Fehler: Quellübergreifende (Cross-Origin) Anfrage blockiert: Die Gleiche-Quelle-Regel verbietet das Lesen der externen Ressource auf http://remso.eu/ajax/getOrte.php?such_ort_name=Wallerst%C3%A4dte. (Grund: CORS-Kopfzeile 'Access-Control-Allow-Origin' fehlt).

              Was sind nun wieder Origin? Unterschied zwischen Domain und Sub-Domain?

              Irgendwas - so meint auch selfHTML - soll in die Kopfzeile geschrieben werden. Beispiel? Ich verstehe nur Bahnhof.

              1. problematische Seite

                Hallo Linuchs,

                Du nimmst den falschen Weg.
                Nicht vier Domains parallel mit demselben Inhalt fahren!

                Leite alle Requests, die nicht z.B auf https://remso.eu laufen auf diese Domain um (mittels mod_rewrite Location Header senden).

                Du hast auch keinen Vorteil bei Suchmaschienen, wenn Du auf vier Domains denselben Inhalt anbietest, eher Nachteile.

                Außerdem dürftest Du per http (ohne TLS) inzwischen auch keine Benutzerdaten mehr transportieren, erst recht keine Logindaten!

                LG
                localhorst

                1. problematische Seite

                  Hallo localhorst, @Linuchs

                  Außerdem dürftest Du per http (ohne TLS) inzwischen auch keine Benutzerdaten mehr transportieren, erst recht keine Logindaten!

                  Um es (noch) schärfer zu formulieren: Es gibt heutzutage keinen Grund mehr, für eine öffentliche Website unverschlüsseltes HTTP zu verwenden. Vielleicht gibt es seeeeeeeehr wenige, krude Anwendungsfälle, in denen das tatsächlich notwendig ist.

                  Man sollte daher definitiv HSTS und HSTS preloading einsetzen.

                  Gruß
                  Julius

              2. problematische Seite

                Hallo Linuchs,

                das sind gleich zwei Grundsatzprobleme.

                1. Du kannst von einer https-gelieferten Seite keine http Ressourcen holen. Andersrum ist es möglich.

                2. Das Schema (http/https) ist Teil des Origin, d.h. du musst CORS Header verwenden, wenn Du von http://example.org Ajax-Requeste nach https://example.org machen willst.

                Kannst Du die Ajax-Requeste nicht schemalos machen? Also mit URL "//example.org" statt "http://example.org"? Dann wird das Schema der Webseite übernommen.

                Update: Sehe gerade: Du greifst von www.remso.eu auf remso.eu zu. Auch das sind verschiedene Origins. Wenn alle Seiteninhalte gleich sind, dann könntest Du in den Requests auch den Hostname weglassen. Also also URL /ajax/getOrte.php statt http://remso.eu/ajax/getOrte.php.

                Oder alles auf eine Domain umleiten, wie der localjörghorst schrieb.

                Rolf

                --
                sumpsi - posui - obstruxi
                1. problematische Seite

                  Hallo Rolf,

                  habe diese .htaccess

                  ErrorDocument 404 /error_404.php
                  Redirect 301 / https://remso.eu/
                  

                  in das Stammverzeichnis von remso.de (da war sie ja schon), remso.eu und remso.org geschrieben.

                  Bei remso.de und remso.org funktioniert die Umleitung, bei Aufruf von remso.eu (die FF zu http://remso.eu formt) nicht. Gibt Fehler.

                  Offenbar wird die Seite mehrfach auf sich selbst umgeleitet.

                  Also bei remso.eu geändert auf

                  ErrorDocument 404 /error_404.php
                  Redirect 301 http://remso.eu https://remso.eu/
                  Redirect 301 http://www.remso.eu https://remso.eu/
                  

                  remso.eu wird nun nach https://remso.eu umgeleitet, www.remso.eu bleibt aber http://www.remso.eu

                  Linuchs

                  1. problematische Seite

                    Hi Linuchs,

                    vor die Umleitung musst Du noch eine Rewritecondition setzen

                    • Alle Aufrufe, die nicht https://remso.eu lauten
                    • auf selbige umleiten

                    Das machst Du am besten in der VirtHost-Einrichtung. Gdht aber auch in den .htaccess der (Sub-)Domains.

                    Die richtige Syntax dafür muss ich Dir im Moment schuldig bleiben. Hold ich nach, wenn nichf jemand anderes schneller ist ;-)

                    Liebe Grüße localhost

                  2. problematische Seite

                    Hallo Linuchs,

                    ich regel die Umleitung auf eine kanonische Variante und das Erzwingen einer bestimmten Domain so:

                    RewriteEngine On
                    
                    # Domain kanonisieren
                    RewriteCond %{HTTP_HOST} !=remso.eu
                    RewriteRule (.*) https://remso.eu/$1 [R=301,L]
                    
                    # HTTPS erzwingen
                    RewriteCond %{HTTPS} !=on
                    RewriteCond %{ENV:HTTPS} !=on
                    RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]
                    

                    Der erste Block leitet alle nicht der gewünschten Domain entsprechenden Anfragen auf die kanonische um. Der zweite erzwingt HTTPS.

                    Gruß
                    Julius

                    1. problematische Seite

                      Hallo Julius,

                      Danke.

                      ich regel die Umleitung auf eine kanonische Variante und das Erzwingen einer bestimmten Domain so:

                      RewriteEngine On
                      
                      # Domain kanonisieren
                      RewriteCond %{HTTP_HOST} !=remso.eu  
                      

                      müsste das nicht so lauten?
                      RewriteCond %{HTTP_HOST} !=^remso\.eu
                      RewriteRule (.*) https://remso.eu/$1 [QSA, R=301,L]

                      HTTPS erzwingen

                      RewriteCond %{HTTPS} !=on
                      RewriteCond %{ENV:HTTPS} !=on
                      RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [QSA, R=301,L]

                      
                      Der erste Block leitet alle nicht der gewünschten Domain entsprechenden Anfragen auf die kanonische um. Der zweite erzwingt HTTPS.
                      
                      

                      Das gibt dann aber immer noch eine Definitionslücke für den Fall, dass HTTPS am Server ausgefallen ist.

                      Im Prinzip müsste man für den Fall, dass nur HTTP (ohne TLS) gesprochen werden kann, alle Module, die Userdaten und/oder Logindaten transportieren, abschalten. Das geht entweder inerhalb der einzigen Applikation, oder durch Aufteilung in zwei getrennte Applikationen.

                      LG
                      localhorst

                      1. problematische Seite

                        Hallo localhorst,

                        müsste das nicht so lauten?
                        RewriteCond %{HTTP_HOST} !=^remso\.eu
                        RewriteRule (.*) https://remso.eu/$1 [QSA, R=301,L]

                        Du hast QSA (→ Query String Append?!) ergänzt? Ja, könnte sinnvoll sein.

                        Das gibt dann aber immer noch eine Definitionslücke für den Fall, dass HTTPS am Server ausgefallen ist.

                        Nein, ich denke nicht. In diesem Randfall würde der Server auf HTTPS umleiten und nichts geht mehr. Ziel erreicht. Gleiches dank HSTS und HSTS preloading.

                        Im Prinzip müsste man für den Fall, dass nur HTTP (ohne TLS) gesprochen werden kann, alle Module, die Userdaten und/oder Logindaten transportieren, abschalten.

                        Da diese Umleitung bereits in der Konfiguration des Webservers läuft und somit HTTP nur zum Umleiten auf HTTPS benutzt wird, ist alles gut. Es gibt sogar mittlerweile Webhoster und Webserver, denen man das Umleiten nicht mehr händisch verklickern muss.

                        Gruß
                        Julius

                        1. problematische Seite

                          Hallo localhorst,

                          müsste das nicht so lauten?
                          RewriteCond %{HTTP_HOST} !=^remso\.eu
                          RewriteRule (.*) https://remso.eu/$1 [QSA, R=301,L]

                          Du hast QSA (→ Query String Append?!) ergänzt? Ja, könnte sinnvoll sein.

                          ... und das Caretzeichen, sowie den Backslash vor dem Dot. QSA war nur nützliches Beiwerk, weil der Qierystring sonst verloren geht.

                          Das gibt dann aber immer noch eine Definitionslücke für den Fall, dass HTTPS am Server ausgefallen ist.

                          Nein, ich denke nicht. In diesem Randfall würde der Server auf HTTPS umleiten und nichts geht mehr. Ziel erreicht. Gleiches dank HSTS und HSTS preloading.

                          Im Prinzip müsste man für den Fall, dass nur HTTP (ohne TLS) gesprochen werden kann, alle Module, die Userdaten und/oder Logindaten transportieren, abschalten.

                          Da diese Umleitung bereits in der Konfiguration des Webservers läuft und somit HTTP nur zum Umleiten auf HTTPS benutzt wird, ist alles gut. Es gibt sogar mittlerweile Webhoster und Webserver, denen man das Umleiten nicht mehr händisch verklickern muss.

                          Das ist sclechte UX. Der User sollte eine entsprechende Usermessage bekommen, die ihm eventuell hilft, Abhilfe zu schaffen. Es könnte auch Port 443 beim Clientnetz gesperrt sein. Habe ich noch nie ausprobiert, was der Browser dann macht.

                          Gruß
                          localhorst

                          1. problematische Seite

                            Hallo

                            Es könnte auch Port 443 beim Clientnetz gesperrt sein. Habe ich noch nie ausprobiert, was der Browser dann macht.

                            Wenn der besucher schon aus dem eigenen Netzwerk nicht herauskommt, hilft ihm ein auf dem angefragten Server bereitgestellter Hinweis nullkommanichts. Bis dahin kommt der Besucher ja nicht. Ein Hinweis auf eine (bewusst eingerichtete) Blockade im eigenen Netz muss vom eigenen Netz bereitgestellt werden.

                            Tschö, Auge

                            --
                            Ein echtes Alchimistenlabor musste voll mit Glasgefäßen sein, die so aussahen, als wären sie beim öffentlichen Schluckaufwettbewerb der Glasbläsergilde entstanden.
                            Hohle Köpfe von Terry Pratchett
                          2. problematische Seite

                            Du hast QSA (→ Query String Append?!) ergänzt? Ja, könnte sinnvoll sein.

                            ... und das Caretzeichen, sowie den Backslash vor dem Dot. QSA war nur nützliches Beiwerk, weil der Qierystring sonst verloren geht.

                            Kannst auch noch ein Dollarzeichen nach der TLD nachlegen. Für den Fall, das mal remso.eus dazu kommt und eine Sonderbehandlung braucht. Man weiß ja nie!

                            Das gibt dann aber immer noch eine Definitionslücke für den Fall, dass HTTPS am Server ausgefallen ist.

                            Nein, ich denke nicht. In diesem Randfall würde der Server auf HTTPS umleiten und nichts geht mehr. Ziel erreicht. Gleiches dank HSTS und HSTS preloading.

                            Das ist sclechte UX. Der User sollte eine entsprechende Usermessage bekommen, die ihm eventuell hilft, Abhilfe zu schaffen. Es könnte auch Port 443 beim Clientnetz gesperrt sein.

                            Bitte was? Wenn das Problem beim Client liegt, besteht doch überhaupt keine Möglichkeit mehr, am Server zu reagieren?! Ganz abseits davon kommt „Port 443 beim Clientnetz gesperrt“ im Jahr 2020 einem „mein Internet ist kaputt“ recht nah.

                            Habe ich noch nie ausprobiert, was der Browser dann macht.

                            Ich tippe auf etwas in der Art wie „Die Verbindung zum Server konnte nicht hergestellt werden“. Tut aber auch irgendwie so überhaupt nichts zur Sache.

                            1. problematische Seite

                              Du hast QSA (→ Query String Append?!) ergänzt? Ja, könnte sinnvoll sein.

                              ... und das Caretzeichen, sowie den Backslash vor dem Dot. QSA war nur nützliches Beiwerk, weil der Qierystring sonst verloren geht.

                              Kannst auch noch ein Dollarzeichen nach der TLD nachlegen. Für den Fall, das mal remso.eus dazu kommt und eine Sonderbehandlung braucht. Man weiß ja nie!

                              Stimmt. Mir will seit ein paar Wochen immer Domains unter .euro andrehen. In den diversen Listings kann ich das aber noch nichf finden.

                              Grüße
                              localhorst

                              1. problematische Seite

                                Du hast QSA (→ Query String Append?!) ergänzt? Ja, könnte sinnvoll sein.

                                ... und das Caretzeichen, sowie den Backslash vor dem Dot. QSA war nur nützliches Beiwerk, weil der Qierystring sonst verloren geht.

                                Kannst auch noch ein Dollarzeichen nach der TLD nachlegen. Für den Fall, das mal remso.eus dazu kommt und eine Sonderbehandlung braucht. Man weiß ja nie!

                                Stimmt nur fast. Mir will seit ein paar Wochen immer Domains unter .euro andrehen. In den diversen Listings kann ich das aber noch nichf finden.

                                Die Requests mit TLDs eus oder euro ... würden gar nicht auf dem Host ankommen (DNS) und auch nicht vom VirtHost bearbeitet werden (ServerAlias fehlt).

                                Beste Grüße
                                localhorst

                                1. problematische Seite

                                  Hi,

                                  Stimmt nur fast. Mir will seit ein paar Wochen immer Domains unter .euro andrehen. In den diversen Listings kann ich das aber noch nichf finden.

                                  Es gibt aber .eurovision (laut iana.org).

                                  cu,
                                  Andreas a/k/a MudGuard

                                  1. problematische Seite

                                    Hi Andreas,

                                    Stimmt nur fast. Das $ für das Ende benötigt man nicht unbedingt, es schadet aber auch nichts. Siehe anderes Posting.

                                    Mir will zwar einer seit ein paar Wochen immer Domains unter .euro andrehen. In den diversen Listings kann ich das aber noch nicht finden und außerdem ....

                                    Es gibt aber .eurovision (laut iana.org).

                                    Weis ich doch ;-)

                                    Die Sätze waren beim Korrigieren etwas durchgewürfelt worden und dann kam das Timrout für bearbeiten dazwischen.

                                    cue,
                                    localhorst

                      2. problematische Seite

                        Das gibt dann aber immer noch eine Definitionslücke für den Fall, dass HTTPS am Server ausgefallen ist.

                        Im Prinzip müsste man für den Fall, dass nur HTTP (ohne TLS) gesprochen werden kann, alle Module, die Userdaten und/oder Logindaten transportieren, abschalten. Das geht entweder inerhalb der einzigen Applikation, oder durch Aufteilung in zwei getrennte Applikationen.

                        Das scheint mir eine weitgehend akademische Betrachtung. Selbst wenn man diesen Fall betrachten möchte, würde durch den 301 und/oder HSTS nur ein Bruchteil der User davon profitieren.

                        1. problematische Seite

                          Bleibt es bei den Bewertungen oder folgen noch Argumente?

                      3. problematische Seite

                        Hallo,

                        danke an Julius und localhorst.

                        Die Umleitung von remso.de und remso.org nach https://remso.eu funktioniert mit

                        # 2020-08-03 remso.de/.htaccess
                        
                        ErrorDocument 404 /error_404.php
                        Redirect 301 / https://remso.eu/
                        

                        Leider funktionieren eure beiden Vorschläge nicht beim Aufruf von remso.eu:

                        ErrorDocument 404 /error_404.php
                        
                        # Redirect 301 / https://remso.eu/
                        
                        # 2020-08-01 https://forum.selfhtml.org/self/2020/jul/31/cookies-mit-php-und-javascript-setzen-und-lesen/1774018#m1774018
                        
                        RewriteEngine On
                        # Julius:
                        # Domain kanonisieren
                        RewriteCond %{HTTP_HOST} !=remso.eu
                        RewriteRule (.*) https://remso.eu/$1 [R=301,L]
                        
                        # localhorst:
                        # RewriteCond %{HTTP_HOST} !=^remso\.eu
                        # RewriteRule (.*) https://remso.eu/$1 [QSA, R=301,L]
                        
                        # HTTPS erzwingen
                        RewriteCond %{HTTPS} !=on
                        RewriteCond %{ENV:HTTPS} !=on
                        RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]
                        

                        Internal Server Error

                        The server encountered an internal error or misconfiguration and was unable to complete your request.

                        Please contact the server administrator at [no address given] to inform them of the time this error occurred, and the actions you performed just before this error.

                        More information about this error may be available in the server error log. Apache/2.4.25 (Debian) Server at remso.eu Port 80

                        Linuchs

                        1. problematische Seite

                          More information about this error may be available in the server error log.

                          Ich wiederhole mal den relevanten Teil:

                          „More information about this error may be available in the server error log.“