Cookie mit php ohne urldecode auslesen möglich?

[skorpi]

Hallo zusammen,

wir schreiben gerade ein PHP-Programm, das sich über ein Cookie mit einer Java-Applikation unterhält. Beide Applikationen können dieses Cookie setzen, lesen und löschen.

Da wir auf dem gleichen Server mit der gleichen Domain etc. unterwegs sind, ist das prinzipiell auch kein Problem. Aber: Wenn man in PHP ein Cookie setzt (mit setcookie()), wird der Wert des Cookies automatisch urlencoded. Auf der anderen Seite wird er beim Auslesen - also z.B. beim lesen von $_COOKIE['cookiename'] - automatisch urldecoded.

Die Java-Applikation macht beides nicht. Das Ergebnis ist, dass wir das Cookie nicht korrekt setzen bzw. lesen können, wenn bestimmte Zeichen im Inhalt vorkommen.

Wir können in PHP für das setzen des Cookies setrawcookie() nutzen, dann ist das von uns gesetzte Cookie nicht urlencoded und die Java-Applikation kann es korrekt auslesen.

Was können wir aber für die andere Richtung tun? Wir haben keine Möglichkeit gefunden, ein Cookie zu lesen, ohne dass der Wert urldecoded wird. Das führt z.B. dazu, dass ein + im Cookie in PHP als Leerzeichen ankommt.

Weiß jemand, wie man ein Cookie auslesen kann, ohne das PHP automatisch urldecode macht?

Vielen Dank für die Hilfe!

Irene

[Cheatah]

Hi,

Weiß jemand, wie man ein Cookie auslesen kann, ohne das PHP automatisch urldecode macht?

warum willst Du einen Fehler in der Java-Applikation an einer völlig fremden Stelle beheben - noch dazu an einer, die sich absolut korrekt verhält?

Wenn man einen Wert in einen Kontext bringt, muss man den Wert kontextspezifisch kodieren. Wenn man einen Wert aus einem Kontext entnimmt, muss man ihn kontextspezifisch dekodieren. Passiert an irgend einer Stelle irgend etwas davon nicht, ist das Ergebnis nicht vorhersehbar. Und einen Bug zu beheben, indem man ihn an einer anderen Stelle wiederholt, ist absolut nicht zielführend - nicht überall ergibt Minus mal Minus Plus.

Repariere also die Java-Applikation, denn *sie* hat einen schwerwiegenden Mangel. Das Verhalten von PHP ist nicht nur korrekt, es ist zwingend erforderlich.

Cheatah

[skorpi]

Hallo Cheatah,

warum willst Du einen Fehler in der Java-Applikation an einer völlig fremden Stelle beheben - noch dazu an einer, die sich absolut korrekt verhält?

Mit einer solchen Reaktion habe ich irgendwie gerechnet :-).

Also:
1. programmiere ich die Java-Applikation nicht, kann also dort auch nichts ändern.
2. ist nirgendwo spezifiziert, wie ein Cookie zu dekodieren oder kodieren ist. Oder kannst du mir eine Quelle nennen, die vorschreibt, wie ein Cookie-Wert zu kodieren ist?
3. ist das Verhalten von PHP an dieser Stelle wahrscheinlich tatsächlich nicht ganz korrekt. Ich habe inzwischen bei der weiteren Recherche folgenden Mailinglisten-Eintrag gefunden:
http://www.mail-archive.com/[e-mail]/msg165061.html (wenn es dich wirklich interessiert, solltest du den thread bis zum Ende lesen).
4. geht es hier nicht um einen Krieg zwischen PHP und Java, sondern schlicht um die Lösung eines Problems. Die Java-Leute haben durchaus die Möglichkeit den Wert zu kodieren, haben aber - zurecht (siehe 3.) - angemerkt, dass das mit einem gewissen Risiko verbunden ist, weil jede Programmiersprache bei dieser Kodiererei und Dekodierei ggf. hier und da andere Dinge tut.

Nun habe ich die Hoffnung, dass sich seit 2005 an dieser Stelle etwas getan hat...

Viele Grüße,

Irene

[Alexander (HH)]

Moin Moin!

Also:

1. programmiere ich die Java-Applikation nicht, kann also dort auch nichts ändern.

Support-Call aufmachen.

2. ist nirgendwo spezifiziert, wie ein Cookie zu dekodieren oder kodieren ist. Oder kannst du mir eine Quelle nennen, die vorschreibt, wie ein Cookie-Wert zu kodieren ist?

Gute Frage. RFC2965 sagt, das der Cookie-Wert ein quoted-string nach RFC2616 ist. Das lese ich als "schreib rein, was Du willst".

3. ist das Verhalten von PHP an dieser Stelle wahrscheinlich tatsächlich nicht ganz korrekt. Ich habe inzwischen bei der weiteren Recherche folgenden Mailinglisten-Eintrag gefunden:
   http://www.mail-archive.com/[e-mail]/msg165061.html (wenn es dich wirklich interessiert, solltest du den thread bis zum Ende lesen).

Dinge, die mich nicht mehr wundern ...

4. geht es hier nicht um einen Krieg zwischen PHP und Java, sondern schlicht um die Lösung eines Problems. Die Java-Leute haben durchaus die Möglichkeit den Wert zu kodieren, haben aber - zurecht (siehe 3.) - angemerkt, dass das mit einem gewissen Risiko verbunden ist, weil jede Programmiersprache bei dieser Kodiererei und Dekodierei ggf. hier und da andere Dinge tut.

Mumpitz. Jeder Text ist nach URL-Encoding und anschließendem  URL-Decoding mit dem Original identisch. Wenn nicht, sind die Routinen für encoding und/oder decoding kaputt.

Ich finde das ganze Konzept, Daten per Cookie weiterzuschleppen, etwas fragwürdig, selbst für eine kontrollierte Umgebung.

Alexander

[hotti]

hi,

Ich finde das ganze Konzept, Daten per Cookie weiterzuschleppen, etwas fragwürdig, selbst für eine kontrollierte Umgebung.

Ich auch. Da gibbts bestimmt ne andere Lösung die schiel vöner ist. Und ja, Cookies sind manipulierbar.

Viele Grüße an Alle,
Horst Haselhuhn

[skorpi]

Servus,

»» Ich finde das ganze Konzept, Daten per Cookie weiterzuschleppen, etwas fragwürdig, selbst für eine kontrollierte Umgebung.

Ich auch. Da gibbts bestimmt ne andere Lösung die schiel vöner ist.

Vorschlag?

Und ja, Cookies sind manipulierbar.

Bekannt und an dieser Stelle unproblematisch.

Gruß,

Irene

[hotti]

hi,

Vorschlag?

»» Und ja, Cookies sind manipulierbar.

Bekannt und an dieser Stelle unproblematisch.

Ok, hier mein Vorschlach, Cookie ? ja;

Mit folgenden Randbedingungen:

• Zeichenvorrat im Keks auf Zeichen beschränken, die ohne Klimmzüge von beiden Anwendungen lesbar sind [a-zA-Z0-9],
• der Cookie beinhaltet lediglich einen Key, die Daten selbst sind in einer Tabelle auf dem Server, der Cookie beinhaltet den Schlüssel dazu.

Hotti

[Cheatah]

Hi,

Gute Frage. RFC2965 sagt, das der Cookie-Wert ein quoted-string nach RFC2616 ist.

RFC 2109 ist wohl der entscheidende, was aber nichts ausmacht, da die beiden sich in dieser Hinsicht nicht unterscheiden, soweit ich die Sache überblicke.

Das lese ich als "schreib rein, was Du willst".

Ja, sofern der Wert gequotet ist, was nach meiner Erfahrung eher selten passiert. Laut den genannten RFCs ist der Wert "token | quoted-string", also bleibt "token" übrig:

token     = 1*<any CHAR except CTLs or tspecials>
CHAR      = <any US-ASCII character (octets 0 - 127)>
CTL       = <any US-ASCII control character (octets 0 - 31) and DEL (127)>
tspecials = "(" | ")" | "<" | ">" | "@"
          | "," | ";" | ":" | "" | <">
          | "/" | "[" | "]" | "?" | "="
          | "{" | "}" | SP | HT
SP        = <US-ASCII SP, space (32)>
HT        = <US-ASCII HT, horizontal-tab (9)>

(RFC 2068, 2.2)

Bleibt also effektiv jedes Zeichen von 33 bis 126, außer "()<>@,;:/[]?={}" und Doublequotes. Somit ist es nötig, beispielsweise Leerzeichen zu kodieren. Der RFC sieht offensichtlich keine Kodierung vor (außer bei quoted-string) - URL-Kodierung hat sich als sinnvoll erwiesen und eingebürgert. Ehrlich gesagt kann ich mich an kein System erinnern, mit dem ich jemals Cookies gesetzt hätte, bei dem nicht auf URL-Kodierung gesetzt wurde, auch wenn ich zugeben muss, dass mein Gedächtnis bei Dingen, die ein Jahrzehnt zurück liegen, etwas getrübt sein mag ...

Cheatah

[skorpi]

Hallo Cheatah,

Ja, sofern der Wert gequotet ist, was nach meiner Erfahrung eher selten passiert. Laut den genannten RFCs ist der Wert "token | quoted-string", also bleibt "token" übrig:

Vielen Dank für die Info! Die können wir vielleicht nutzen, um zu verlangen, dass die möglichen Zeichen entsprechend eingeschränkt werden, also z.B. kein Leerzeichen vorkommen darf.
Wobei gerade das + Probleme macht, weil es beim Auslesen zu einem Leerzeichen gemacht wird. Aber ich weiß jetzt auf jeden Fall schon einmal genauer, wie die Recherche weiter geht :-)).

Gruß,

Irene

[skorpi]

Servus,

»» 4. geht es hier nicht um einen Krieg zwischen PHP und Java, sondern schlicht um die Lösung eines Problems. Die Java-Leute haben durchaus die Möglichkeit den Wert zu kodieren, haben aber - zurecht (siehe 3.) - angemerkt, dass das mit einem gewissen Risiko verbunden ist, weil jede Programmiersprache bei dieser Kodiererei und Dekodierei ggf. hier und da andere Dinge tut.

Mumpitz. Jeder Text ist nach URL-Encoding und anschließendem  URL-Decoding mit dem Original identisch. Wenn nicht, sind die Routinen für encoding und/oder decoding kaputt.

Offensichtlich hast du den thread oben nicht zu Ende gelesen :-)). Macht aber nix, denn: Mumpitz hin, Mumpitz her. Ich werde weder die entwprechende Java-Routine noch die entsprechende PHP-Routine umschreiben ^^

Ich finde das ganze Konzept, Daten per Cookie weiterzuschleppen, etwas fragwürdig, selbst für eine kontrollierte Umgebung.

Besserer Vorschlag?

Gruß,

Irene

[Alexander (HH)]

Moin Moin!

»» »» 4. geht es hier nicht um einen Krieg zwischen PHP und Java, sondern schlicht um die Lösung eines Problems. Die Java-Leute haben durchaus die Möglichkeit den Wert zu kodieren, haben aber - zurecht (siehe 3.) - angemerkt, dass das mit einem gewissen Risiko verbunden ist, weil jede Programmiersprache bei dieser Kodiererei und Dekodierei ggf. hier und da andere Dinge tut.
»»
»» Mumpitz. Jeder Text ist nach URL-Encoding und anschließendem  URL-Decoding mit dem Original identisch. Wenn nicht, sind die Routinen für encoding und/oder decoding kaputt.
»»
Offensichtlich hast du den thread oben nicht zu Ende gelesen :-)).

Bis gerade eben habe ich den Thread nicht einmal geöffnet. Ich lese das so, dass PHP beim Encoding oder Decoding kaputt ist. Wie gesagt, sowas wundert mich nicht mehr. Nach grobem Querlesen scheint das, was PHP anstellt, nur noch entfernt ähnlich zu dem, was der Rest der Welt als URL-Encoding bzw. -Decoding bezeichnet.

»» Ich finde das ganze Konzept, Daten per Cookie weiterzuschleppen, etwas fragwürdig, selbst für eine kontrollierte Umgebung.
»»
Besserer Vorschlag?

Datenweitergabe auf dem Server. Zum Beispiel über eine gemeinsame Session-Verwaltung. Zum Beispiel, indem ein Proxy in Sprache A benutzt wird, um auf die Anwendung in Sprache B zuzugreifen und dabei der Proxy die Daten weiterreicht, indem der HTTP-Request an B und ggf. auch die Response von B manipuliert werden (B darf dann nicht mehr direkt erreichbar sein). Zum Beispiel über RPC-Aufrufe zwischen A und B, um Statusinformationen in einem gemeinsam definierten Format (JSON, XML, URL-Encoded, ...) auszutauschen.

Alexander

[ChrisB]

Hi,

Ich lese das so, dass PHP beim Encoding oder Decoding kaputt ist.

Bzgl. was?

Nach grobem Querlesen scheint das, was PHP anstellt, nur noch entfernt ähnlich zu dem, was der Rest der Welt als URL-Encoding bzw. -Decoding bezeichnet.

Wo liest du das heraus?

MfG ChrisB

[ChrisB]

Hi,

4. geht es hier nicht um einen Krieg zwischen PHP und Java, sondern schlicht um die Lösung eines Problems. Die Java-Leute haben durchaus die Möglichkeit den Wert zu kodieren, haben aber - zurecht (siehe 3.) - angemerkt, dass das mit einem gewissen Risiko verbunden ist

Ich wünsche euch viel Spass, wenn bspw. mal ein einfaches oder gar doppeltes <CR><LF> im Value eures Cookies vorkommt.

MfG ChrisB