Schlampiger Formmailer

[$xNeTworKx]

Hi,
Ich habe vor kurzem diesen Artikel gelesen :

http://www.perlunity.de/perl/newsperl/20020829124150.shtml

Ich wollte fragen was mit "....dass das Formail-Script von Matt Wright durch den "Empfänger"-Parameter im Script, von aussen genutzt werden kann, um Mails zu verschicken, indem man einfach den Post simuliert und diesen Empfänger-Tag bei jdem Aufruf ändert." gemeint ist?

Wie kann man den Post simulieren und den Empfänger bei jedem Aufruf ändern?

Ich will jetzt natürlich kein böswilliges Spamscript bauen, aber ich habe mich doch gefragt, ob nicht bei meinem eigenen Script vielleicht auch irgendwie so eine hinterlistige Möglichkeit besteht.
Also wie weis ich, ob mein Script sicher ist bzw worauf muss man besonders 8en ?

$xNeTworKx.

[Philipp Hasenfratz]

Halihallo $xNeTworKx

Ich wollte fragen was mit "....dass das Formail-Script von Matt Wright durch den "Empfänger"-Parameter im Script, von aussen genutzt werden kann, um Mails zu verschicken, indem man einfach den Post simuliert und diesen Empfänger-Tag bei jdem Aufruf ändert." gemeint ist?

Wie kann man den Post simulieren und den Empfänger bei jedem Aufruf ändern?

Ganz einfach: LWP::* ; das Perlmodul um Requests auszuführen. Man kann auch POST-Content
angeben und somit einen normalen HTTP-Request, wie er von dem HTML-Forumlar ausgeführt
wird, simulieren. Durch ändern des Empfängerfeldes
( script.cgi?empfaenger=[e-mail] ) kann somit der Empfänger frei definiert werden
und durch ein Spamscript automatisiert (eine Liste mit Adressen, zu jedem Eintrag wird
ein Request auf den Formmailer ausgeführt). Die neuen Prog verwenden auch den Referer-
Check, der jedoch auch ganz simpel umgangen werden kann (ich empfehle die Lektüre der
genannten Modul-Kategorie).

Viele Grüsse

Philipp

[$xNeTworKx]

Hallo,

Ganz einfach: LWP::* ; das Perlmodul um Requests auszuführen. Man kann auch POST-Content
angeben und somit einen normalen HTTP-Request, wie er von dem HTML-Forumlar ausgeführt
wird, simulieren. Durch ändern des Empfängerfeldes
( script.cgi?empfaenger=[e-mail] ) kann somit der Empfänger frei definiert werden

Achso, also wenn in meinem Script der Empfänger gar nicht geändert werden kann, brauche ich mir also keine Sorgen machen, so wie ich das jetzt verstanden habe?
Ich frage mich überhaupt, welchen Sinn es macht, bei einem Formmailscript den Empfänger als Variable zu definieren, da das Script sowieso immer an den selben Zuständigen sendet.

Kann ich also beruhigt sein mit meiner Subroutine?

sub sendmail    {
my ($mailadresse,$text,$name) = @_;

open (MAIL, "| /usr/sbin/sendmail -n -t") or die "Cant send mail : $!\nPlease report this error to [e-mail]\n";
     print MAIL "From: $mailadresse\n";

if ($name eq 'an xNeTworKx senden')   {
              print MAIL "To: [e-mail]\n";
      }
      if ($name eq 'an Ac1dburn senden')   {
      print MAIL "To: [e-mail]\n";
      }
              if ($name eq 'an beide senden')   {
      print MAIL "To: [e-mail]\n";
      print MAIL "Bcc: [e-mail]\n";
      }
     print MAIL "Subject: Benachrichtigung von acid4u.com\n\n";
     print MAIL "$ENV{'REMOTE_ADDR'}\n";
              if ($name eq 'an beide senden')   {
              print MAIL "(Dieses Mail wurde an xNeTworKx und Ac1dburn geschickt)\n";
      }
     print MAIL "$text\n\n";
     close MAIL;
}

[Philipp Hasenfratz]

Halihallo $xNeTworKx

Achso, also wenn in meinem Script der Empfänger gar nicht geändert werden kann, brauche ich mir also keine Sorgen machen, so wie ich das jetzt verstanden habe?

100 Punkte für dich.

Ich frage mich überhaupt, welchen Sinn es macht, bei einem Formmailscript den Empfänger als Variable zu definieren, da das Script sowieso immer an den selben Zuständigen sendet.

Macht wirklich keinen Sinn, Wright wollte lediglich die Spammer unterstützen.

Kann ich also beruhigt sein mit meiner Subroutine?

Ja. Aber Mails über den SMTP senden finde ich persönlich schöner und
plattformunabhängiger ;)

Viele Grüsse

Philipp

[$xNeTworKx]

Hi,

ok danke, alles klar.

Ja. Aber Mails über den SMTP senden finde ich persönlich schöner und
plattformunabhängiger ;)

Ich weis, ich verlasse mich dabei auf ein anderes Programm, also sendmail, aber ich habe bisher damit nie Probleme gehabt, wobei ich sicher nicht sendmail verwenden würde, wenn ich ein Open source Script schreiben würde.
Das Script ist aber nur für den persönlichen Gebrauch, also wüsste ich nicht was gegen sendmail spricht :)

$xNeTworKx.

[Alain]

Moin, Ich benutze auch den mailer.pl von Matt . Ich hab mich desshalb auch mal gefragt warum auf der contact seite noch meine mail als variable eingegeben werden muss? Wenns ja immer zum selben empfänger geht,wieso hat der Matt diese variable nicht ins mail-programm einbezogen schon wegen dem spahm? Der referer check ist auch nicht das wahre,weil man ganz gut auch lokal eine mail über das skript schicken könnte es sei denn man bezieht auch diese refer "-" variable mit ein.

Grüsse vom Alain

[$xNeTworKx]

Hallo,

Ich benutze auch den mailer.pl von Matt .

Wenn das vielleicht so rübergekommen ist, ich benutze nichts von Matt Wright, weder einen Forummailer, noch irgend etwas anderes, weil 1. schreib ich es lieber selbst und 2. würde ich an deiner Stelle die Finger von Scripts lassen, bei denen nicht in den ersten Zeilen ein -w oder "use strict" vorkommt.

$xNeTworKx.

[$xNeTworKx]

..., bei denen nicht in den ersten Zeilen ein -w oder "use strict" vorkommt.

Falsch formuliert. Ich will eigentlich sagen, dass auf jeden Fall "use strict" drin stehen sollte, und mindestens use warnings oder -w.
Wenn nicht, schmeiß das Script am Besten in den Müll.

$xNeTworKx.

[Philipp Hasenfratz]

Halihallo $xNeTworKx

..., bei denen nicht in den ersten Zeilen ein -w oder "use strict" vorkommt.

Falsch formuliert. Ich will eigentlich sagen, dass auf jeden Fall "use strict" drin stehen sollte, und mindestens use warnings oder -w.
Wenn nicht, schmeiß das Script am Besten in den Müll.

Ich stimme dir eigentlich zu. "Eigentlich" deshalb, da es nicht direkt mit use strict
und use warnings zusammenhängt, dass Scripts "auf den Müll" sollten, sondern weil ein
Unterlassen derselben meist ein Fingerprint/-abdruck derjenigen ist, die von Perl
etwas weniger Ahnung haben bzw. nach dem Prinzip "möglichst schnell, hauptsache es
funktioniert" vorgehen. Es gibt natürlich noch weitere Kriterien, die für mich Anlass
zum "vermüllen" von Scripts sind, z. B. print "$var" oder $var=5; if("$var"=="5"), ja
sogar print "hello" ist schlecht, da aperformant (bitte einfache Quotes verwenden)...
Aber zurück zu use strict; und use warnings; :
Diese beiden (+ Tainted-Mode sei hier noch genannt) dienen dazu Fehler[1] im Script
vorzeitig und _schneller_ zu finden und den Style des Scripts zu verbessern. Sind also
primär für den Erstellungszyklus wichtig; natürlich muss ein Script oftmals überarbeitet
und erweitert werden, dies ist oftmals die Ursache, dass die genannten Schalter meist im
Script verweilen, obwohl, und darauf möchte ich hinaus, sie gar nicht mehr nötig wären
und eventuell (untested[tm]) sogar Performance _verschwenden_. Wäre wirklich mal
interessant zu wissen, ob ein "use strict" Performance braucht, natürlich muss der
Perlinterpreter einige Tests [s. [1]] durchführen und verbraucht somit CPU-Zeit, auf der
anderen Seite können für Variablen bereits beim Start-up und in der compilation-phase
Platz auf dem Heap reservieren werden. Es wird wohl also vom jeweiligen Kontext
abhängen. Basierend auf _dieser_ Argumentation gäbe es aus Sicht der Performance
wirklich nur einen Schluss:
Zum Erstellen und Debuggen von Scripts wird use strict; und use warnings; eingesetzt,
jedoch im "laufenden System" entfernt. Somit müssen vom Interpreter keine Tests mehr
durchgeführt werden und die Variablen können dennoch in der compilation-phase
eingerichtet werden. Wie gesagt: Dies basiert auf der ungetesteten Annahme vom letzten
Absatz und ist in der Praxis wohl auch nicht sehr wichtig, da es sich lediglich um
einige ms/ns handeln kann.

[1] unter Fehler verstehe ich auch globale Variablen in gewissen Fällen;
Mehrfachdefinitionen derselben, Nichtdeklaration/-iniziierung etc.

Viele Grüsse

Philipp
   <!-- dem gerade langweilig war und sich mit philosophischen Fragen zu Perl
beschäftigte ;-)

[Andres Freund]

Hi

interessant zu wissen, ob ein "use strict" Performance braucht,

Ja, ich hab es mal bei einem Sxipt getested, ist allerdings schon ein wenig her. Da ich damals Benchmark nicht kannte, hab ich einfach in einer while Schleife das ganze Script ein paar tausend mal durchgeführt. War so um 0,2%-0,4%langsamer, allerdings weiß ich nicht mehr was für ein Script das wasr, mit dem ich das getested habe.
Ich komentiere daher inzwischen wenn alles mal ohne Fehler läuft use strich; aus.

Noch ein bisschen OT an xnetwork:

Ich weiß, dass es nicht hierhergehört, ich bin aber durch Zufall(ich hab nach hostern geschaut) an einen Post von dir im artfiles Forum gekommen. Da man dort aber nicht als nicht artfiles-Kunde nicht posten kann und du auch nirgends eine Mail Adresse angegeben hast, konnte ich dier es nur so mitteilen.
Man kann sehr wohl auch mit Perl sessions über die url benutzten. Z.B. mit Apache::Session. Weitere Fragen bitte stellen ,-).

mfg Andres Freund

[Philipp Hasenfratz]

Halihallo Andres

interessant zu wissen, ob ein "use strict" Performance braucht,

Ja, ich hab es mal bei einem Sxipt getested, ist allerdings schon ein wenig her. Da ich damals Benchmark nicht kannte, hab ich einfach in einer while Schleife das ganze Script ein paar tausend mal durchgeführt. War so um 0,2%-0,4%langsamer, allerdings weiß ich nicht mehr was für ein Script das wasr, mit dem ich das getested habe.
Ich komentiere daher inzwischen wenn alles mal ohne Fehler läuft use strich; aus.

Danke für die Info; hatte (noch) keine Zeit zum Testen, wobei ich gestehen muss, dass
ich auch gar nicht weiss, wie ich das machen sollte, denn (womit ich beim Thema bin) :
Es gibt, soweit ich mir das bisher überlegt habe, kein genaues Messinstrument, um zu
wirklich aussagekräftigen Benchmark-Werten zu kommen. Das Messergebnis würde von zuvielen
Faktoren abhängen. Nehmen wir z. B. deine Messmethode (sorry, wenn ich deine Messung
kritisiere); es wird eine Schleife im Thread generiert, somit ist der Parsetree immer
schon existent und Speicher allokiert (reserviert), bei einer neuen Variable (ob my oder
nicht) muss also nicht notgedrungen Speicher allokiert werden und dies verfälscht
das Ergebnis, wo ich ja davon ausgegangen bin, dass Speicher von definierten Variablen
bereits beim Start-up (im gewissen Sinne eine "weitere Optimierung des Parsetrees")
reserviert werden können (dieses "Feature" würde die Messmethode nicht berücksichtigen).
Gehen wir von einer iterierenden Ausführung von Test-Scripten aus, sodass jedesmal ein
neuer Prozess gestartet wird und somit der Start-up auch in das Messergebnis einfliesst,
haben wir das Problem, dass viel Zeit für OS-Operationen verbraucht wird, um den
Perlinterpreter/Dateien zu laden (das muss ja auch nicht immer _genau_ gleich lange
dauern). Ich bin aufgrund dieser Gedanken zum Schluss gekommen, dass es keine
Möglichkeit über  Perl gibt, um zu einem signifikanten Messergebnis zu kommen. Ich bin
mir noch nicht sicher, glaube jedoch, dass eine Analyse des Quelltextes von Perl und
Tests auf dieser Ebene die einzige Möglichkeit ist, ein relevantes Testergebnis zu
erhalten.
Nun gut, das "use warnings" zu testen ginge vielleicht, da dies notgedrungen "on-the-
fly" passiert und somit ein einigermassen relevantes Messergebnis über Perl ermöglicht.

Zudem sollte ich vielleicht zuerst meine These belegen, dass "eingeführte" (my/our/use
vars) Variablen (unter Berücksichtigung des Kriteriums, dass sie im Main-Scope definiert
sind) wirklich schon beim Start-up allokiert werden; wer weiss, vielleicht hat Larry
nicht daran gedacht, bzw durch Messungen bereits bewiesen, dass es gar nicht effizient
wäre.

Viele Grüsse

Philipp

[Andres Freund]

Hi,

Stimmt schon aber ich hab ja gesagt, dass das ein wenig her ist, damals wusste ich noch gar nicht was kompillieren bedeuted.
Aber ich habe damals ein Script mittels require eingebunden, was ja erst in der Laufzeit ausgeführt wird (ich wusste damals nicht einmal wie man ein mit use nutzbares Script schreibt). Daher müsste doch das eingebundene Script immer kompiliert werden (solange man nicht unter Mod-Perlarbeited)? Oder ist Perl so intelligent das zu verhindern?
Man könnte auch ein Scipt mit einem Destructor aufrufen und das dann prüfen, aber das hätte den Nachteil das die Geschwindigkeit nochmal anders ist als in "normalen" Perl da objektorientiertes ein guten Teil langsamer ist als das normale, daher auch  nicht viel informativer.
Wie genau "use benchmark" ist weiß ich nicht... ist wahrscheinlich eher dazu da die Geschwindigkeit einzelner Scriptteile zu testen.

mfg Andres

[Philipp Hasenfratz]

Halihallo Andres

immer wieder auf dem HalliHallo Tripp :-)

Stimmt schon aber ich hab ja gesagt, dass das ein wenig her ist, damals wusste ich noch gar nicht was kompillieren bedeuted.

Das hatte ich schon verstanden, deshalb habe ich es ja auch nur als Beispiel genommen,
um auf die Gefahren hinzuweisen und zu "beweisen", dass es sich als schwierig heraus-
stellen könnte, ein passendes Messverfahren zu konzeptionieren.

Aber ich habe damals ein Script mittels require eingebunden, was ja erst in der Laufzeit ausgeführt wird (ich wusste damals nicht einmal wie man ein mit use nutzbares Script schreibt). Daher müsste doch das eingebundene Script immer kompiliert werden (solange man nicht unter Mod-Perlarbeited)? Oder ist Perl so intelligent das zu verhindern?

Ist es, ja :-)
require überprüft, ob die entsprechende Datei bereits required worden ist. Ist dem so,
wird gleich zurück zum Hauptprogramm gesprungen. Man könnte also ein Verzeichnis an-
legen, mit ca. 500'000 gleichen Perl-Programmen mit entsprechenden Zahlenwerten hinten
angesetzt; dann eine Schleife, wie du es vorschlägst, jedoch immer nur eines dieser
500'000 Programme requiren, welches noch nicht required worden ist (eg.
require 'prog'.$schlaufen_index;).

Man könnte auch ein Scipt mit einem Destructor aufrufen und das dann prüfen, aber das hätte den Nachteil das die Geschwindigkeit nochmal anders ist als in "normalen" Perl da objektorientiertes ein guten Teil langsamer ist als das normale, daher auch  nicht viel informativer.

In wie fern glaubst du, dass der Destructor dir helfen könnte? - Das ist in Perl
eine Methode, wie jede andere, welche einfach automatisch aufgerufen wird; per se
hat sie jedoch nichts mit dem zerstören der Daten zu tun, das wird durch den
Garbage Collector gemacht.

Wie genau "use benchmark" ist weiß ich nicht... ist wahrscheinlich eher dazu da die Geschwindigkeit einzelner Scriptteile zu testen.

Stimmt. Für das, was wir testen wollen eben nicht sehr geeignet, da man wohl, wie ich
bereits sagte, eine Stufe weiter unten (C/Quelltext-Ebene) ansetzen müsste.

Viele Grüsse

Philipp

[Andres Freund]

Hi

In wie fern glaubst du, dass der Destructor dir helfen könnte? - Das ist in Perl
eine Methode, wie jede andere, welche einfach automatisch aufgerufen wird; per se
hat sie jedoch nichts mit dem zerstören der Daten zu tun, das wird durch den
Garbage Collector gemacht.

Ich meinte, dass ich in dem "pseudo Destruktor" alle Variablen auf undef setze, damit muss dann wenn die Variablen neu definiert werden neuer Speicher "alloziert" werden, damit kann man zumindest diesen Unterschied, der ja ein rel. großen Teil von use Strict ausmacht, so einigermaßen nachvollziehen.
Aber noch eine Frage, Idee: eigentlich könnte das Script in bestimmten Teilen auch schneller sein, da nicht nachgeprüft werden muss ob irgendwelche Variablen autvivikaiert (aus Programmieren mit Perl) werden müssen, und dies demnach nicht zur Laufzeit geschehen muss. Ich weiß nicht ob das so ist, aber könnte doch sein, vielleicht weißt du darüber mehr.

mfg Andres Freund

[Philipp Hasenfratz]

Halihallo Andres

In wie fern glaubst du, dass der Destructor dir helfen könnte? - Das ist in Perl
eine Methode, wie jede andere, welche einfach automatisch aufgerufen wird; per se
hat sie jedoch nichts mit dem zerstören der Daten zu tun, das wird durch den
Garbage Collector gemacht.

Ich meinte, dass ich in dem "pseudo Destruktor" alle Variablen auf undef setze, damit muss dann wenn die Variablen neu definiert werden neuer Speicher "alloziert" werden, damit kann man zumindest diesen Unterschied, der ja ein rel. großen Teil von use Strict ausmacht, so einigermaßen nachvollziehen.

Stimmt. Das macht die Sache schon etwas besser, aber... Es muss eben nicht notgedrungen
neuer Speicher allociert werden; naja, hier müssen wir wohl erst definieren, von welchem
Speicher wir sprechen. Ich spreche von dem Speicher des Rechners, du sprichst wohl
vom Speicher, der intern von Perl verwaltet wird. Das sind eben zwei (p|P)aar Schuhe.
Wenn bei Perl eine Variable undefiniert wird (Achtung: undef($var), nicht $var=undef;
letzteres setzt immer noch einen Wert von $var, nämlich der Wert 'undef'), wird der
Speicher noch nicht an das OS zurückgegeben; Perl merkt sich einfach, wo noch Speicher
frei ist und speichert dort u. U. eine neue Variable, von Zeit zu Zeit wird dann
(aber dies ist willkürlich!) Speicher an das OS zurückgegeben. Der Sinn in diesem etwas
komplizierteren Prozedere ist ganz einfach: Ein Allocieren von Speicher vom
Betriebssystem kostet relativ gesehen mehr Zeit, also wenn er Perlintern verwaltet wird.
So genau weiss ich das aber auch nicht, ich kann diese Aussagen nicht beweisen; glaube
es nur so irgendwo gelesen zu haben.

Aber noch eine Frage, Idee: eigentlich könnte das Script in bestimmten Teilen auch schneller sein, da nicht nachgeprüft werden muss ob irgendwelche Variablen autvivikaiert (aus Programmieren mit Perl) werden müssen, und dies demnach nicht zur Laufzeit geschehen muss. Ich weiß nicht ob das so ist, aber könnte doch sein, vielleicht weißt du darüber mehr.

Ich hoffe, dass ich diesen Absatz richtig verstanden habe... Z. B. das
Wort 'autvivikaiert' höre ich zum ersten Mal und google anscheinend auch... :-(
Kannst du dieses noch erklären, würde mich interessieren.

Naja gut, ich versuche mal das Verstandene niederschreiben:
setzen wir _kein_ use strict und verhalten uns auch so (sprich: nirgendwo ein my...),
dann werden alle Variablen im global-scope (Modul-Scope [meistens also package main])
gespeichert. Theoretisch wäre es dann möglich, alle Variablennamen auszufiltern und
gleich zu Beginn zu allocieren; dann müsste Perl im ganzen Programm nur einen alloc
ausführen und hätte den gesamten Speicher reserviert. Das wäre zwar von Seiten der
Performance sehr gut, aber von Seiten der Speicherverwaltung absoluter Schwachsinn;
demnach glaube ich nicht, dass dies so umgesetzt wurde. Es wäre dann ja oftmals so, dass
Speicher für einige Variablen allokiert wurde, welche gar nie gebraucht werden...

Habe ich das so richtig verstanden?

Viele Grüsse

Philipp

PS: Darf ich eigentlich allokiert sagen? - Oder besser allociert? - OK, etwas
denglish... Oder gibt's das überhaupt nicht? - Wenn letzteres, dann folgendes: im C wird
der Befehl zum Speicher holen mit 'alloc' beschrieben... Soviel zur Erklärung warum ich
auf dieses "allo(c|k|ck)ieren" kam.

[Andres Freund]

Halihallo Phillip ;-)

Ich hoffe, dass ich diesen Absatz richtig verstanden habe... Z. B. das
Wort 'autvivikaiert' höre ich zum ersten Mal und google anscheinend auch... :-(

Hab mich auch verschrieben, der Begriff heißt Autovivifikation (sich selbst zu leben erwecken), und demnach autovivifikaisiert ;-), oder?. Man sollte halt ausreichend schlafen *g*.
Dies bedeuted dass für Variablen, von sich selbst aus, in der Laufzeit Speicher reservieren. Falls es dich interressiert, und du "programmieren in Perl" (hinten im Index nachschauen, besonders Seite 1009) nicht hast, aus dem ich die Informationen habe, kann ich den Abschnitt mal schnell abtippen, aber jetzt muss ich noch schnell meine Hausaufgaben fertig machen.

Kannst du dieses noch erklären, würde mich interessieren.

s.o.

Naja gut, ich versuche mal das Verstandene niederschreiben:
setzen wir _kein_ use strict und verhalten uns auch so (sprich: nirgendwo ein my...),
dann werden alle Variablen im global-scope (Modul-Scope [meistens also package main])
gespeichert. Theoretisch wäre es dann möglich, alle Variablennamen auszufiltern und
gleich zu Beginn zu allocieren; dann müsste Perl im ganzen Programm nur einen alloc
ausführen und hätte den gesamten Speicher reserviert. Das wäre zwar von Seiten der
Performance sehr gut, aber von Seiten der Speicherverwaltung absoluter Schwachsinn;
demnach glaube ich nicht, dass dies so umgesetzt wurde. Es wäre dann ja oftmals so, dass
Speicher für einige Variablen allokiert wurde, welche gar nie gebraucht werden...

Es wäre praktisch wenn man dieses Verhalten irgendwie erzwingen könnte. Dann könnte man in dem Fall, dass man sehr hohe Geschwindigkeit braucht, den Perl Interpreter/Compiler mit einem Switch anweisen allen Speicher auf einmal zu rservieren. Das Problem das ich sehe ist allerding, dass Perl kaum wissen kann wieviel Speicher für jede einzelne Variable benötigt wird. Ich denke mal es macht schon einen Unterschied ob ich eine 100 MB Datei einlese, oder ob es sich um eine Konfigurationsvariable handelt *fg*.
Ausserdem sehe ich da ein Problem mit anonymen Subs/arrays...

Habe ich das so richtig verstanden?

Ja, so habe ich das so ungefähr gemeint (ich kann es nicht besser ausdrücken). Ich denke dass du es auch so verstanden hast, aber noch einmal zur verdeutlichung wie ich es meinte: Ohne my muss das Programm selber erkennen, ob eine Variable jetzt Speicher braucht, oder nicht. Demnach wird für diese Autoerkennung CPU-Zeit benötigt. Mit use strict 'vars', um das es sich meiner Meinung nach hier alleine handelt, wird dieses Reservieren jetzt durch einen eindeutigen Bezeichner(my) eingeführt. Die Frage ist jetzt nur, ob Perl das überhaupt berücksichtigt.

PS: Darf ich eigentlich allokiert sagen? - Oder besser allociert? - OK, etwas denglish... Oder gibt's das überhaupt nicht? - Wenn letzteres, dann folgendes: im C wird der Befehl zum Speicher holen mit 'alloc' beschrieben... Soviel zur Erklärung warum ich auf dieses "allo(c|k|ck)ieren" kam.

Dieses Problem kenne ich, einerseits sind wir hier in Deutschland wo Deutsch geredet wird und wir auch reden sollten wenn wir verstanden werden wollen, andererseits ist IMHO im IT Bereich nun mal englich die Standartsprache sclechthin. Was ja auch irgendwie sinvoll ist.
Diese Entscheidung beinflusst dann auch die Benennung von Variablen usw..

mfg Andres Freund

[Philipp Hasenfratz]

Halihallo Andres

Ich hoffe, dass ich diesen Absatz richtig verstanden habe... Z. B. das
Wort 'autvivikaiert' höre ich zum ersten Mal und google anscheinend auch... :-(
Hab mich auch verschrieben, der Begriff heißt Autovivifikation (sich selbst zu leben erwecken), und demnach autovivifikaisiert ;-), oder?. Man sollte halt ausreichend schlafen *g*.

:-)

Dies bedeuted dass für Variablen, von sich selbst aus, in der Laufzeit Speicher reservieren. Falls es dich interressiert, und du "programmieren in Perl" (hinten im Index nachschauen, besonders Seite 1009) nicht hast, aus dem ich die Informationen habe, kann ich den Abschnitt mal schnell abtippen, aber jetzt muss ich noch schnell meine Hausaufgaben fertig machen.

Das Buch habe ich nicht. Aber google hat seine Dokumente zu "Autovivification" (das
Deutsche Kompliment wird nicht gefunden). Ich konnte mich da etwas einlesen, danke.

Es wäre praktisch wenn man dieses Verhalten irgendwie erzwingen könnte. Dann könnte man in dem Fall, dass man sehr hohe Geschwindigkeit braucht, den Perl Interpreter/Compiler mit einem Switch anweisen allen Speicher auf einmal zu rservieren. Das Problem das ich sehe ist allerding, dass Perl kaum wissen kann wieviel Speicher für jede einzelne Variable benötigt wird. Ich denke mal es macht schon einen Unterschied ob ich eine 100 MB Datei einlese, oder ob es sich um eine Konfigurationsvariable handelt *fg*.

Völlig richtig. Zumindest könnte jedoch Speicher für den SV struct allokiert werden.
Zur Info: Der SV struct ist eine Datenstruktur, womit Perl auf C-Ebene skalare Werte
abbildet (SV: Scalar Value); dieser braucht auch schon einige Bytes und wenn da
auch nur 100 Variablen sind, würde es bereits etwas bringen, da eben nur einmal, sagen
wir 100*12 Bytes = 1200 Bytes allokiert werden müssten und nicht 100 mal 12 Bytes
(die Anzahl ist das Performancefressende, nicht die Grösse des allokierten Bereichs).

Ausserdem sehe ich da ein Problem mit anonymen Subs/arrays...

Ja, diese müssen notgedrungen on the fly angelegt werden.

Habe ich das so richtig verstanden?
Ja, so habe ich das so ungefähr gemeint (ich kann es nicht besser ausdrücken). Ich denke dass du es auch so verstanden hast, aber noch einmal zur verdeutlichung wie ich es meinte: Ohne my muss das Programm selber erkennen, ob eine Variable jetzt Speicher braucht, oder nicht. Demnach wird für diese Autoerkennung CPU-Zeit benötigt. Mit use strict 'vars', um das es sich meiner Meinung nach hier alleine handelt, wird dieses Reservieren jetzt durch einen eindeutigen Bezeichner(my) eingeführt. Die Frage ist jetzt nur, ob Perl das überhaupt berücksichtigt.

Stimmt, das konnte ich nach wie vor nicht beweisen.

Viele Grüsse

Philipp

[$xNeTworKx]

Hallo @ all

Ich glaube, dass die Open Source Scripts, die kein use strict, oder dgl. haben, sowieso nie damit geschrieben wurden. ZB Das YaBB Forum. Als ich es mir mal heruntergeladen habe, und zu sehen wie es funktioniert und ein -w an #!/usr/bin/perl dranhing, bekam ich sogar einen Internal Server Error. Soviel dazu.

Noch ein bisschen OT an xnetwork:

Ich weiß, dass es nicht hierhergehört, ich bin aber durch Zufall(ich hab nach hostern geschaut) an einen Post von dir im artfiles Forum gekommen. Da man dort aber nicht als nicht artfiles-Kunde nicht posten kann und du auch nirgends eine Mail Adresse angegeben hast, konnte ich dier es nur so mitteilen.
Man kann sehr wohl auch mit Perl sessions über die url benutzten. Z.B. mit Apache::Session. Weitere Fragen bitte stellen ,-).

Oh danke für die Info. Bin übrigens bei dem Problem damals nicht weitergekommen =)
Werd mir das bei Gelegenheit mal besser unter die Lupe nehmen., danke.

$xNeTworKx.

[Alain]

Moin, naja das Matt script funktioniert ja damit #!/usr/bin/perl -w use strict; use CGI::Carp qw(fatalsToBrowser);

..., bei denen nicht in den ersten Zeilen ein -w oder "use strict" vorkommt.

Falsch formuliert. Ich will eigentlich sagen, dass auf jeden Fall "use strict" drin stehen sollte, und mindestens use warnings oder -w. Wenn nicht, schmeiß das Script am Besten in den Müll.

Ich wüsste jetzt nicht wo da das problem sein soll? Grüsse vom Alain

[Stefan Muenz]

Hallo Philipp,

Macht wirklich keinen Sinn, Wright wollte lediglich die Spammer unterstützen.

Vielleicht sollte man mal daran erinnern, dass sein Script aus einer Zeit stammt, als noch niemand das Wort "Spammer" buchstabieren konnte. Er wollte nur, dass sein Script allgemein geschrieben ist und nicht bei jedem Einsatz im Quelltext rumgepfuscht werden muss. Normalerweise ist das eine der Standardpflichten eines Software-Entwicklers. Dass solche Bestrebungen auch mal mit Sicherheitsluecken konfligieren koennen - nun ja, das gehoert eben zu den Feinheiten. Und wie gesagt - zu der Zeit, als die Matt-Wright-Scripts entstanden, war eben alles noch viel einfacher.

Ich schreibe das uebrigens nur deshalb, weil ich es nicht leiden kann, wenn auf Matt Wright immerzu rumgehackt wird wegen der Sicherheitsluecken in seinen Scripts. Wuerde er diese Scripts heute neu anbieten, wuerde sich keine Sau dafuer interessieren. Seine Scripts sind nur deshalb so verbreitet, weil es sie schon seit Web-Gedenken gibt. Dabei hat er Pionierarbeit geleistet und seinerzeit vielen Menschen den Einstieg in die Perl/CGI-Programmierung gezeigt. Man sollte das vielleicht einfach auch mal anerkennen.

viele Gruesse
  Stefan Muenz

Kann ich also beruhigt sein mit meiner Subroutine?

Ja. Aber Mails über den SMTP senden finde ich persönlich schöner und
plattformunabhängiger ;)

Viele Grüsse

Philipp

viele Gruesse
  Stefan Muenz

[Philipp Hasenfratz]

Halihallo Stefan

Macht wirklich keinen Sinn, Wright wollte lediglich die Spammer unterstützen.

Vielleicht sollte man mal daran erinnern, dass sein Script aus einer Zeit stammt, als noch niemand das Wort "Spammer" buchstabieren konnte. Er wollte nur, dass sein Script allgemein geschrieben ist und nicht bei jedem Einsatz im Quelltext rumgepfuscht werden muss. Normalerweise ist das eine der Standardpflichten eines Software-Entwicklers. Dass solche Bestrebungen auch mal mit Sicherheitsluecken konfligieren koennen - nun ja, das gehoert eben zu den Feinheiten. Und wie gesagt - zu der Zeit, als die Matt-Wright-Scripts entstanden, war eben alles noch viel einfacher.

Ich schreibe das uebrigens nur deshalb, weil ich es nicht leiden kann, wenn auf Matt Wright immerzu rumgehackt wird wegen der Sicherheitsluecken in seinen Scripts. Wuerde er diese Scripts heute neu anbieten, wuerde sich keine Sau dafuer interessieren. Seine Scripts sind nur deshalb so verbreitet, weil es sie schon seit Web-Gedenken gibt. Dabei hat er Pionierarbeit geleistet und seinerzeit vielen Menschen den Einstieg in die Perl/CGI-Programmierung gezeigt. Man sollte das vielleicht einfach auch mal anerkennen.

Völlig richtig. Ich habe dies fälschlicherweise immer in einem zu aktuellen Kontext
gesehen.

Im aktuellen Kontext ist denjenigen Leuten und Providern zu klagen, die Scripte
verwenden, von welchen der Spam-Boom überdurchschnittlich[1]  provitiert.
Überdurchschnittlich wird von jenen Scripten provitiert, welche "altbewährt" und dadurch
weit verbreitet sind. Diese aus heutiger Sicht nicht mehr den Sicherheits-Ansprüchen
genügenden Scripten, sollten nicht mehr verwendet werden[2].
Da Matt Wrights Scripte weitverbreitet sind, sollte darauf geachtet werden, dass die
Attacken minimiert werden. Dies ist, wohl verstanden, keine Kritik an Matt Wright,
sondern an denen, die keinen Wert auf Gegenmassnahmen für Spamattacken legen
(Securityupdates; gleiche, jedoch nicht so anfällige Scripts; eigene, speziell für
den Anwendungszweck erstellte Scripte).

[1] weniger provitiert wird von denjenigen Scripts, welche gleichartig (auch
Sicherheitslücken), jedoch nicht so verbreitet sind, da von diesen weniger Spamaufkommen
ausgeht.
[2] gemeint sind hier Versionen derselben, welche gravierende Sicherheitslücken
aufweisen und bereits neue Sicherheitspatches haben.

Viele Grüsse

Philipp

[MudGuard]

Hi,

Ich frage mich überhaupt, welchen Sinn es macht, bei einem Formmailscript den Empfänger als Variable zu definieren, da das Script sowieso immer an den selben Zuständigen sendet.

Das hängt entscheidend vom Einsatzzweck des Formulars ab.
Ist es ein "Postkarten"-Script oder ein "Bitte empfehlt meine Seite weiter"-Script, wäre es nicht sehr sinnvoll, wenn es nur einen vorgegebenen Empfänger gäbe.

Wenn die Daten aber immer nur an eine Adresse geschickt werden sollten, sollte dieser nicht über http parametrierbar sein...

cu,
Andreas