nicht angemeldet
Perl - Aufruf mit Paramter
Ahoi,
ich möchte ein Perlscript in einem Link aufrufen also so:
<a href="formular.pl">Blupp</a>
Und nun möchte ich dem Script ein paar Parameter mitgeben.
1. Wie mache ich das am besten ?
2. Mit welcher Umgebungsvariablen lese ich das dann aus ?
Danke für Hilfe.
Gruß
Klonkrieger
-
Hi, Klonkrieger
ich möchte ein Perlscript in einem Link aufrufen also so:
<a href="formular.pl">Blupp</a>Und nun möchte ich dem Script ein paar Parameter mitgeben.
- Wie mache ich das am besten ?
- Mit welcher Umgebungsvariablen lese ich das dann aus ?
Und täglich grüßt das Murmeltier - jetzt schon das zweite Mal ;-)
-> </archiv/2002/3/8010/#m44372>
LG Orlando
-
Hallo,
ich möchte ein Perlscript in einem Link aufrufen also so:
<a href="formular.pl">Blupp</a>Und nun möchte ich dem Script ein paar Parameter mitgeben.
- Wie mache ich das am besten ?
- Mit welcher Umgebungsvariablen lese ich das dann aus ?
Danke für Hilfe.
Gruß
Klonkriegerz.B. so:
Datenstrom einlesen
sub read_data
{
# Datenstrom lesen (POST)
if (lc($ENV{'REQUEST_METHOD'}) eq 'post')
{
read (STDIN,$eingabe,$ENV{'CONTENT_LENGTH'});
@eingabe=split(/&/,$eingabe);
foreach $i (0..$#eingabe)
{
$eingabe[$i]=~ s/+/ /g;
$eingabe[$i]=~ s/%(..)/pack("c",hex($1))/ge;
($feldname,$wert)=split(/=/,$eingabe[$i],2);
if ($feldname)
{
${lc($feldname)}=$wert;
}
}
}
# Datenstrom lesen (GET)
if (lc($ENV{'REQUEST_METHOD'}) eq 'get')
{
$eingabe=$ENV{'QUERY_STRING'};
@eingabe=split(/&/,$eingabe);
foreach $i (0..$#eingabe)
{
$eingabe[$i]=~ s/+/ /g;
$eingabe[$i]=~ s/%(..)/pack("c",hex($1))/ge;
($feldname,$wert)=split(/=/,$eingabe[$i],2);
if ($feldname)
{
${lc($feldname)}=$wert;
}
}
}
}wenn Dein <input name="blablabla" value="test"....> lautet,
ist $blablabla == "test" !!!
Ich benutze das immer so, es gibt zwar andere Möglichkeiten über cgi, aber das Modul nutze ich nicht so gerne. Der Vorteil hierbei ist eben auch, daß es direkt in der im HTML benannten Variablen landet.Reiner
-
Hoi,
z.B. so:
[...]
Ist das 'use strict'-faehig? Ich glaube nicht, oder?
wenn Dein <input name="blablabla" value="test"....> lautet,
ist $blablabla == "test" !!!
eq ;-)
Ich benutze das immer so, es gibt zwar andere Möglichkeiten über
cgi, aber das Modul nutze ich nicht so gerne.Warum?
Der Vorteil hierbei ist eben auch, daß es direkt in der im HTML
benannten Variablen landet.Das ist IMHO kein Vorteil, sondern ein Nachteil. ich sag dir auch
warum: damit kann ich als User dir beliebige Variablen in den
Namespace von 'main' hauen. Dadurch wird, wenn du nicht verdammt
aufpasst, das manipulieren deines Scriptes sehr einfach.Gruesse,
c.j.k-
Hallo,
z.B. so:
[...]
Ist das 'use strict'-faehig? Ich glaube nicht, oder?
das mußte ja kommen.
Bau es halt um, wenn Du das benötigst.Der Vorteil hierbei ist eben auch, daß es direkt in der im HTML
benannten Variablen landet.Das ist IMHO kein Vorteil, sondern ein Nachteil. ich sag dir auch
warum: damit kann ich als User dir beliebige Variablen in den
Namespace von 'main' hauen. Dadurch wird, wenn du nicht verdammt
aufpasst, das manipulieren deines Scriptes sehr einfach.Ok, wenn mir jemand Variablen vorgaukelt, die ich sonst nochmal brauche.
Dann natürlich. Aber da ich die Abfrage ganz am Anfang mache, würden die Werte später überschrieben...
Oder was meinst Du?Reiner
-
-
Moin moin!
[quotes rearranged]
Ich benutze das immer so, es gibt zwar andere Möglichkeiten über cgi, aber das Modul nutze ich nicht so gerne.
Ich auch nicht, aber es gibt einen Grund, warum CGI.pm immer empfohlen wird, naemlich damit solcher Code wie Deiner nicht verwendet wird. Auf den ersten Blick faellt mir auf:
Datenstrom einlesen
sub read_data
{
# Datenstrom lesen (POST)
if (lc($ENV{'REQUEST_METHOD'}) eq 'post')
{
read (STDIN,$eingabe,$ENV{'CONTENT_LENGTH'});
@eingabe=split(/&/,$eingabe);Hier wird nicht die Moeglichkeit gelassen, die einzelnen Parameter mit ; statt & zu trennen. Das ist zwar kein MUST, aber immerhin ein SHOULD.
foreach $i (0..$#eingabe)
{
$eingabe[$i]=~ s/+/ /g;
$eingabe[$i]=~ s/%(..)/pack("c",hex($1))/ge;
($feldname,$wert)=split(/=/,$eingabe[$i],2);Hier fliegt das Script auf die Schnauze, wenn ein Feldname ein = enthaelt. Die Decodierung muss *nach* dem split fuer Feldname und Wert separat erfolgen.
if ($feldname)
Hier versagt es, wenn ein Feldname eine einfache 0 ist.
{
${lc($feldname)}=$wert;
}Und hier werden noch viel mehr moegliche Feldnamen ausgeschlossen. Christian hat ja schon was dazu gesagt. Wenn jemand einen Feldnamen schickt, der kein gueltiges Perlsymbol ist, dann war's das fuer Dein Script.
# Datenstrom lesen (GET)
if (lc($ENV{'REQUEST_METHOD'}) eq 'get')Was bitte ist mit HEAD requests?!
Ausserdem ist so das POSTen an eine URL mit Querystring nicht moeglich. (Weiss aber nicht, ob CGI.pm das kann.)wenn Dein <input name="blablabla" value="test"....> lautet,
ist $blablabla == "test" !!!
Der Vorteil hierbei ist eben auch, daß es direkt in der im HTML benannten Variablen landet.Vorteil? "Vorteil" ist nicht ganz genau das Wort, das mir zu Namespace pollution und potentiellen Sicherheitsluecken einfaellt.
So long
--
Rule of thumb -- every time Microsoft use the word "smart," be on the lookout for something dumb.
-- http://www.fourmilab.ch/webtools/demoroniser/-
Hallo,
Du hast vollkommen recht.
Aber was Benamsung und etwaiger Fehler bzw. nicht gültigen Zeichen anbelangt:
Ich schreibe das Script, das abfeuert auch selbst...
Kann nur ein Problem bei Sicherheitsrelevanten Dingen werden, also daß jemand von woanders her abfeuert. Aber bei sowas nutze ich auch andere Abfragen.
Recht hast Du auf alle Fälle auch mit dem Split VOR dem Dekodieren. Das habe ich noch nie näher betrachtet.Ich werde das alles nochmal überarbeiten.
Danke!
Reiner
-
Re Reiner!
Kann nur ein Problem bei Sicherheitsrelevanten Dingen werden, also daß jemand von woanders her abfeuert. Aber bei sowas nutze ich auch andere Abfragen.
Ich sehe da vor allem ein Problem mit den vordefinierten Variablen in Perl. Z.B. kann Dir jemand einen zusaetzlichen Parameter uebergeben, de dann $\ (output record separator) aendert. Beim naechsten print schreibst Du dann den uebergebenen Wert zusaetzlich. Schon sind deine Datendateien korrumpiert. Und bei der Variablenvielfalt in Perl (siehe perldoc perlvar) waere ich mir nicht so sicher, ob es nicht vielleicht jemand irgendwie hinkriegt, beliebigen Code auszufuehren...
So long
--
Rule of thumb -- every time Microsoft use the word "smart," be on the lookout for something dumb.
-- http://www.fourmilab.ch/webtools/demoroniser/-
Hi nochmal!
Ein weiteres moegliches Szenario waere dieses: In kleineren Scripts ist es ueblich, am Anfang eine kleine Config-Sektion zu machen, wo der Benutzer direkt die Inhalte von Variablen setzt. Nun uebergibt Dir jemand einen zusaetzlichen Parameter mit genau dem Namen einer dieser Config-Variablen, in der der Name einer Datei steht, die Du im weiteren Verlauf zum Lesen oeffnen musst (bei einem Forum oder Gaestebuch ist das ja ueblich). Wenn Du jetzt noch vergessen hast, im open-Befehl "< $dateiname" statt einfach nur $dateiname anzugeben (beides hat ja gewoehnlich die gleiche Wirkung, und oft wird der Einfachheit halber die zweite Variante verwendet), dann kann ein Angreifer ein beliebiges Programm ausfuehren, in dem er $dateiname auf etwas wie '| /usr/bin/mail [args]' setzt. Also fuer mich waere das Grund genug, solche Schwachstellen von Anfang an zu vermeiden. Dann kann man auch mal woanders einen Fehler machen (wie z.B. das "<" bei open vergessen), ohne dass gleich ein Sicherheitsloch entsteht.
So long
--
Rule of thumb -- every time Microsoft use the word "smart," be on the lookout for something dumb.
-- http://www.fourmilab.ch/webtools/demoroniser/
-
-
-