COOKIES mit PHP und Javascript setzen und lesen

[Linuchs]

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

[Matthias Apsel]

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

[MudGuard]

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

[localhorst]

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

[Linuchs]

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

[Matthias Apsel]

Hallo Linuchs,

Richtig. Ich habe ungenau gelesen.

Bis demnächst
Matthias

[Rolf B]

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

[Linuchs]

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.

[Linuchs]

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.

[localhorst]

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

[Julius]

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

[Rolf B]

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

[Linuchs]

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

[localhorst]

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

[Julius]

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

[localhorst]

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

[Julius]

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

[localhorst]

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

[Auge]

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

[Mitleser 2.0]

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.

[localhorst]

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

[localhorst]

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

[MudGuard]

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

[localhorst]

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

[Mitleser 2.0]

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.

[Mitleser 2.0]

Bleibt es bei den Bewertungen oder folgen noch Argumente?

[Linuchs]

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

[Raketenfehlerfinder]

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.“