Cookie URLencoded?

[Rolf Rost]

Moin,

siehe Betreff. Bei eine Recherche über Cookies ist mir die Frage 'Muss der Wert eines Cookie URLencoded sein?' noch nicht ganz klar geworden. Genauer: Müssen _alle_ Zeichen des Values URLencoded sein?

Wenn ich mir die URL eines mit GET übertragenen Datenstromes anschaue, sehe ich da z.B. dass u.a. die Zeichen

. _ - & = ? *

nicht encoded sind. Leerzeichen als %30, @ als %40 u.a. hingegen schon...

Ja, welche Zeichen sind denn nun zu decoden bzw. escapen? Oder kann ich beim Setzen eines cookies gänzlich darauf verzichten?

Viele Grüße, Rolf

[wahsaga]

hi,

Ja, welche Zeichen sind denn nun zu decoden bzw. escapen? Oder kann ich beim Setzen eines cookies gänzlich darauf verzichten?

die cookie-spezifikation von netscape sagt diesbezüglich:

NAME=VALUE
This string is a sequence of characters excluding semi-colon, comma and white space. If there is a need to place such data in the name or value, some encoding method such as URL style %XX encoding is recommended, though no encoding is defined or required.

es ist also nicht als zwingend notwendig definiert, wie mir scheint - bietet sich aber m.E. trotzdem an, um probleme von vornherein zu vermeiden.

außerdem werden die wert je als HTTP header übertragen - also sehe ich keinen guten grund, warum die kodierung hier verzichtbar sein sollte, während sie es beispielsweise bei URLs nicht ist.

PHP beispielsweise erledigt die kodierung bei nutzung von setcookie() automatisch - wenn man das nicht will, muss man setrawcookie() bemühen.

um welche sprache geht's denn in deinem fall? bietet die nicht ggf. auch schon mechanismen an, dass automatisch zu erledigen, so dass du dich darum gar nicht weiter kümmern müsstest?

gruß,
wahsaga

[Rolf Rost]

hi,

NAME=VALUE
This string is a sequence of characters excluding semi-colon, comma and white space. If there is a need to place such data in the name or value, some encoding method such as URL style %XX encoding is recommended, though no encoding is defined or required.

Vielen Dank! Ich hätt bei Netscape gucken sollen ;-)

um welche sprache geht's denn in deinem fall? bietet die nicht ggf. auch schon mechanismen an, dass automatisch zu erledigen, so dass du dich darum gar nicht weiter kümmern müsstest?

Naja, es ist PERL. Guck mal in meinen Zusatz, da hab ich meinem Workaround um das encoding zu umgehen. Der eigentliche Hintergrund ist der, dass ich in diesem (und ich anderen Scripts) aus bestimmten Gründen nicht das CGI Modul verwenden kann und möchte...

Gruss, Rolf

--
http://rolfrost.de/cgi-bin/myforum.cgi

[Rolf Rost]

Noch ein bischen Code...

also bei meinem Forum umgehe ich diese Frage, bei einem POST wird lediglich die Nummer der Nachricht in einem Cookie abgelegt:

if($cookiename){
 my $ch = qq(Set-Cookie: $cookiename=$fid.$nr; path=/; expires=Fri, 25-Dec-2015 16:50:39 GMT);
 cookie_redir("$ENV{'SCRIPT_NAME'}?$par", $ch);
}
else{ redir("$ENV{'SCRIPT_NAME'}?$par") }

und beim Aufruf des POST-Forms wird der Name dann aus der Tabelle gelesen:

if($cookiename and $ENV{'HTTP_COOKIE'}){
 my ($cn, $cv) = split /=/, $ENV{'HTTP_COOKIE'};
 $cv =~ /^(\d+).(.*)$/;
 my $sth = $dbh->prepare("SELECT name FROM forum WHERE fid='$1' AND mid='$2' ");
 $sth->execute;
 my $ref = $sth->fetchrow_hashref;
 $name = $ref->{'name'};
 $sth->finish;
}

Das hat den Vorteil der einfachen Scalierbarkeit (brauch ich evntl. außer dem Namen auch noch die email oder den link zur HP..) und ich muss nicht unbedingt das CGI Modul einbinden.

Wer Lust hat, kann das ja mal testen, Link untenstehend, ob das mit verschiedenen Browsern geht...

Gruss, Rolf

[Struppi]

Das hat den Vorteil der einfachen Scalierbarkeit (brauch ich evntl. außer dem Namen auch noch die email oder den link zur HP..) und ich muss nicht unbedingt das CGI Modul einbinden.

Welchen Vorteil soll das bringen?

Ich gehe mittlerweile davon aus, das jedes Modul oder Programm das in einem CGI Kontext eingebunden wird die Funktionen verwenden kann ohne das Modul einzubinden.
CGI::param(...) oder CGI::cookie() kann ich (in einem CGI Skript) an jeder Stelle aufrufen.

So brauchst du dich z.b. mit eben solchen Fragen gar nicht zu beschäftigen.

Du verwendest doch auch das DBI Modul oder?

Struppi.

[Rolf Rost]

hi Stuppi,

Ich gehe mittlerweile davon aus, das jedes Modul oder Programm das in einem CGI Kontext eingebunden wird die Funktionen verwenden kann ohne das Modul einzubinden.
CGI::param(...) oder CGI::cookie() kann ich (in einem CGI Skript) an jeder Stelle aufrufen.

So brauchst du dich z.b. mit eben solchen Fragen gar nicht zu beschäftigen.

4GL Syndrom ;-)

Das CGI Modul bietet keine Funktion die einen Cookie setzt und danach umleitet. Da ich das jedoch brauche für ein Login -> Umleitung auf die Anwendung und umgekehrt, muss ich da zu Fuss rein.

Und wenn ich schon aus bestimmten Gründen eine eigene readparse() Funktion verwende um ein paar lumpige Formulareingaben einzulesen, brauch ich das CGI Modul doch nicht extras wegen eines noch lumpigeren Cookies einzuzetzen ;-)

Du verwendest doch auch das DBI Modul oder?

Ja natürlich. Aber das hat mit Cookies nun überhaupt nichts zu tun...

Gruss, Rolf

[Struppi]

Hallo Rolf Rost

hi Stuppi,

Ich gehe mittlerweile davon aus, das jedes Modul oder Programm das in einem CGI Kontext eingebunden wird die Funktionen verwenden kann ohne das Modul einzubinden.
CGI::param(...) oder CGI::cookie() kann ich (in einem CGI Skript) an jeder Stelle aufrufen.

So brauchst du dich z.b. mit eben solchen Fragen gar nicht zu beschäftigen.

4GL Syndrom ;-)

Das CGI Modul bietet keine Funktion die einen Cookie setzt und danach umleitet. Da ich das jedoch brauche für ein Login -> Umleitung auf die Anwendung und umgekehrt, muss ich da zu Fuss rein.

Nicht?

#!/usr/bin/perl -w

use CGI;
use strict;

my $cookie = CGI::cookie(
       -name => 'test',
       -value => 'etwas x beliebiges',
       -expires => '+25h',
       -path => '/',
);
my $neue_url = 'http://localhost/';

my $text = CGI::header(-cookie => $cookie, -location => $neue_url);

print $text

funktioniert einwandfrei.

Und wenn ich schon aus bestimmten Gründen eine eigene readparse() Funktion verwende um ein paar lumpige Formulareingaben einzulesen, brauch ich das CGI Modul doch nicht extras wegen eines noch lumpigeren Cookies einzuzetzen ;-)

Naja, das ist wirklich Verschwendung.
Das CGI Modul ist, wenn man es verstanden hat, ein extrem nützliches Werkzeug um HTML Ausgaben zu erstellen, seien es Formulare (sehr sehr nützlich) oder Tabellen (nie mehr ein end Tag vergessen) oder x-beliebiges HTML, alles wird mit dem Modul einfacher und du hast keinen HTML Code in deinem Perl Code, was die Übersichlichkeit enorm verbessert.

aber wenn deine Skript nur Formulare parsen gibt es glaub ich sowas wie CGI::Lite (o.ä)

Du verwendest doch auch das DBI Modul oder?

Ja natürlich. Aber das hat mit Cookies nun überhaupt nichts zu tun...

nicht mit den Cookies, aber damit das es ein Modul für einen Verwendungszweck gibt das millionenmal im Einatz ist, von Millionen Benutzern quasi getestet wird und dadurch sich für dich solche Fragen nicht mehr stellen dürften.

Struppi.

[Rolf Rost]

hi Struppi,

my $text = CGI::header(-cookie => $cookie, -location => $neue_url);

Cool! Das hab ich doch tatsächlich übersehen ;-)

Ein sehr schöner Header:

Set-Cookie: test=etwas%20x%20beliebiges; path=/; expires=Fri, 26-Nov-2004 13:22:52 GMT
Date: Thu, 25 Nov 2004 12:22:52 GMT
location: http://localhost/
Content-Type: text/html; charset=ISO-8859-1

Prozeß erfolgreich abgeschlossen

nicht mit den Cookies, aber damit das es ein Modul für einen Verwendungszweck gibt das millionenmal im Einatz ist, von Millionen Benutzern quasi getestet wird und dadurch sich für dich solche Fragen nicht mehr stellen dürften.

Warum nicht ;-)

Danke auf jeden Fall!

Gruss an den Rest Deiner Sippe in Mainz ;-)

Rolf

[Struppi]

nicht mit den Cookies, aber damit das es ein Modul für einen Verwendungszweck gibt das millionenmal im Einatz ist, von Millionen Benutzern quasi getestet wird und dadurch sich für dich solche Fragen nicht mehr stellen dürften.

Warum nicht ;-)

Weil vermutlich lange vor dir jemand sich über diese Problem Gedanken gemacht hat, bzw. in solchen Modulen in der Regel die entsprechenden Regeln integriert sind,  da sich der Autor wohl intensiv mit den Fragen rund um CGI auseinandergesetzt hat.

Ich persönlich hätte keine Lust mich mit allen RFCs zu beschäftigen die im CGI Kontext eine Rolle spielen. Insofern würde ich gar nicht mehr ohne auskommen und glücklicherweise ist es auch pures Perl so das man sich das Modul überall mithin nehmen kann

Struppi.

[Rolf Rost]

hi,

Ich persönlich hätte keine Lust mich mit allen RFCs zu beschäftigen die im CGI Kontext eine Rolle spielen. Insofern würde ich gar nicht mehr ohne auskommen und glücklicherweise ist es auch pures Perl so das man sich das Modul überall mithin nehmen kann

Na ich erst ;-) Und ich geb gerne zu, dass ich manchmal einfach drauflos tippe und meine eigene Suppe braue, wenn ich nicht zeitnah was fertiges finde (Originalton meines Matheprofessors: Wenn wir nicht mehr weiterwissen, rechnen wir einfach drauflos...); was gelegentlich zu Lösungen führt, die ganz woanders schon lange mal gesucht wurden. Also ich hab gestern auch intensiv ins CGI Modul und in die CGI::__ geschaut und bin dann auch zu dem Schluss gekommen: Donnerwetter, das ist ja eigentlich wesentlich komplizierter, als es mir lieb ist, und das alles zu Fuss zu machen, nur damit es in die Standards passt wollte ich nun doch auch wieder nicht.

Auf jeden Fall bin ich schon seit längerem zu der Erkenntnis gekommen, dass Benutzereingaben nichts in einem Cookie zu suchen haben, es sei denn die wurden vorher ordentlich encoded, aber wenn ich in einem Script selbst dafür sorgen kann, dass da keine unerlaubten Zeichen drinstehen und die Benutzereingaben letztendlich aus einer DB gelesen werden, wo sie ohnehin landen, dann ist das auch OK ;-)

Ergo hat DBI ja doch was mit Cookies zu tun, ich korrigiere meine Aussage *g.

Viele Grüße, Rolf