Perl Variable überschreiben.....

[MatzeA]

Servus,

bei folgendem code bekomme ch einen Fehler.

Pfad + Name der Konfigurations

require "./config/wmbbconf.cgi" ;

Laden der Übergabe Werte:

my $query     = new CGI;
my $date      = &date();

my $aktion    = $query->param('aktion');

Parameter werden von der Formularseite ausgelesen

if ($aktion eq "view")
{

$titel="Meldungen Übersicht";

-> Hier raucht er ab.
Die Variable $titel wurde schon in der wmbbconf.cgi deklariert.
Die Fehlermeldung:

Global symbol "$titel" requires explicit package name at /web/cgi-bin/deploybb/wmbb.cgi line 27.

Was will er nun? Wie soll ich den globalen Package Namen angeben?
Hab mal typischerweise kein Buch da um das mal schnell nach zu schlagen.

Vielen Dank für die Hilfe.

Gruss Matze

[Erwin]

Servus,

bei folgendem code bekomme ch einen Fehler.

Pfad + Name der Konfigurations

require "./config/wmbbconf.cgi" ;

use strict;
use vars qw($title);

-> Hier raucht er ab.

Die Variable $titel wurde schon in der wmbbconf.cgi deklariert.

Nicht dort deklarieren, s.o., sollte tun.

Erwin

[MatzeA]

Servus,

Nicht dort deklarieren, s.o., sollte tun.

Muss jedoch, da nur in wenigen Fällen diese Variabe überschrieben werden soll, das wiederum abhängig davon, wo das Programm sich gerae findet.
Ebenfalls wollte ich alle vom "Anwender" änderbaren Werte in dies Konfigurationsdatei halten.

Aber so könnte es gehen oder?

use vars qw($title);

$title = $titel;

es wird über required noch ein weiteres Script eingebunden bzw. mehrere, in denen die ganze Logic verteilt ist.
Ob das nun zu einem Problem wird?
Ausserdem, warum sollte ich diese in der Konfiguration angegebenen Variablen nicht ändern können, schliesslich kann ich deren inhalt ja auch auslesen.

Gruss Matze

[Erwin]

Servus,

Aber so könnte es gehen oder?

use vars qw($title);

$title = $titel;

Sollte auch tun, wenn $title _nur_ in der Library deklariert ist.

Gruss, Erwin

[MatzeA]

Servus,

ja jetzt geht es, nachdem ich
use strict;
im 1. Script raus geschmissen habe.

Danke

Gruss Matze

[Erwin]

Servus,

ja jetzt geht es, nachdem ich
use strict;
im 1. Script raus geschmissen habe.

Nana, du hast meine Botschaft nicht ganz verstanden ;-)

use vars qw(); ist ja nur die eine Seite...

aber

use strict;

hilft ungemein bei der Fehlersuche und führt zu einem sauberen Code.

Gruss, Erwin

PS: Früher hab ich auch immer gesagt, strict ist was für Müslifresser. Das stimmt nach wie vor, heißt aber nicht, dass strict nicht nur ausschließlich von Müslifressern verwendet wird ;-)

[MatzeA]

Servus,

Nana, du hast meine Botschaft nicht ganz verstanden ;-)

Ich weiss, das ist nicht die feine englische aber ich muss noch schnell das Titelhandling einbauen.
Der kann sich jedoch an den unterschiedlichsten Stellen ändern.
Die einfachste Methode ist nun mal diese Variable sofern notwendig direkt dort zu ändern, wo es notwendig wird.

Das Script entsprechend zu bearbeiten ist leider zu aufwendig. Da müsste ich zig Aufrufe abändern und übergaben etc. einbauen.

Gruss Matze

[Struppi]

Das Script entsprechend zu bearbeiten ist leider zu aufwendig. Da müsste ich zig Aufrufe abändern und übergaben etc. einbauen.

Sinnvollerweise baut man solche initialisierungswerte in ein HASH exportiert das aus dem ini Modul und greift dann auf die Keys zu.

Struppi.

[Struppi]

Hallo Struppi

Das Script entsprechend zu bearbeiten ist leider zu aufwendig. Da müsste ich zig Aufrufe abändern und übergaben etc. einbauen.

Sinnvollerweise baut man solche initialisierungswerte in ein HASH exportiert das aus dem ini Modul und greift dann auf die Keys zu.

ungefähr so:

ini.pm
package ini;

require Exporter;
@ISA = qw(Exporter);
@EXPORT =  qw(%INI);

%INI = (
titel => 'der Titel'
....
);

im Hauptmodul:

use ini;

print $INI->{titel};

Struppi.

[MatzeA]

Servus,

ja die Idee hat was werde ch den so machen.

Gruss Matze

[Alexander Foken]

Moin Moin !

Zwei kleine Anmerkungen:

1. Für CGIs ist das aktuelle Verzeichnis UNDEFINIERT! Die meisten Webserver setzen es auf das Verzeichnis mit dem CGI, aber das darf man bestenfalls unter "nette Gefälligkeit" verbuchen.

2. CGI-Resourcen haben im CGI-Verzeichnis nichts verloren, schon gar nicht mit cgi-Extension und wohl möglich auch noch ausführbar. Das öffnet u.U. riesige Sicherheitslücken, wenn jemand die URL dieser Resourcen raten und Eigenheiten der Resourcen nutzen kann.

Zu 1:
Absoluten Pfad in require angeben.

Zu 2:
Resourcen möglichst außerhalb der Webserver-Verzeichnisse ablegen, wo das nicht geht, das Verzeichnis mittels .htaccess oder Ähnlichem "verrammeln": "order deny,allow" und "deny from all" sollten es tun.

Alexander

[Erwin]

Moin Moin !

Zwei kleine Anmerkungen:

1. Für CGIs ist das aktuelle Verzeichnis UNDEFINIERT! Die meisten Webserver setzen es auf das Verzeichnis mit dem CGI, aber das darf man bestenfalls unter "nette Gefälligkeit" verbuchen.

Ja hab ich auch: hier gehts um PERL ;-)

Aber:
require "./config/wmbbconf.cgi" ;

könnte tatsächlich zum Problem führen, wenn das Script mal von einem anderen Verzeichnis aus oder vom cron aufgerufen wird: Das geht mit Sicherheit schief.

Absolute Pfade verwenden - hin, use lib(); her.

Wer sowas dynamisch haben will muss sich was einfallen lassen, zb sowas
http://perlbase.xwolf.de/cgi-bin/perlbase.cgi?dis.4.3

Erwin

[MatzeA]

Servus,

Zwei kleine Anmerkungen:

1. Für CGIs ist das aktuelle Verzeichnis UNDEFINIERT! Die meisten Webserver setzen es auf das Verzeichnis mit dem CGI, aber das darf man bestenfalls unter "nette Gefälligkeit" verbuchen.

Nein ist nicht undefiniert:
Mein Problem war nur ein kleiner Auszug.

$0 =~ /^(.*)[/\].*/ && chdir ($1) ;
Das kommt noch weiter oben.

2. CGI-Resourcen haben im CGI-Verzeichnis nichts verloren, schon gar nicht mit cgi-Extension und wohl möglich auch noch ausführbar. Das öffnet u.U. riesige Sicherheitslücken, wenn jemand die URL dieser Resourcen raten und Eigenheiten der Resourcen nutzen kann.

»»

Das ist völlig egal, dazu müsste man 1. das Script kennen und 2. Geht es hierbei nur um die Anzeige und sortierung.
Selbst wenn jemand das Script direkt aufrufen würde, würde er entweder Fehler produzieren oder eben irgendwas bekommen ohne damit was anfangen zu können.

Zu 2:
Resourcen möglichst außerhalb der Webserver-Verzeichnisse ablegen, wo das nicht geht, das Verzeichnis mittels .htaccess oder Ähnlichem "verrammeln": "order deny,allow" und "deny from all" sollten es tun.

Nix anderes habe ich gemacht.
Der einfacheit halber, habe ich das Zeug zusammen gelassen.
Gruss Matze

[Alexander Foken]

Moin Moin !

Ok, ich klappe den "mahnenden Zeigefinger" wieder ein. ;-)

2. CGI-Resourcen haben im CGI-Verzeichnis nichts verloren, schon gar nicht mit cgi-Extension und wohl möglich auch noch ausführbar. Das öffnet u.U. riesige Sicherheitslücken, wenn jemand die URL dieser Resourcen raten und Eigenheiten der Resourcen nutzen kann.
   »»

Das ist völlig egal, dazu müsste man 1. das Script kennen und 2. Geht es hierbei nur um die Anzeige und sortierung.
Selbst wenn jemand das Script direkt aufrufen würde, würde er entweder Fehler produzieren oder eben irgendwas bekommen ohne damit was anfangen zu können.

Es geht ja weniger um das Bekommen. Unter ganz widrigen Umständen könnte man ein ausführbares Perl-Fragment im CGI-Verzeichnis dazu bringen, Sachen zu veranstalten, die Du nicht haben möchtest. Ein schönes Beispiel: gzip_cnc vor Version 1.11 hat als netten Nebeneffekt die Quelltexte aller Scripte ausgegeben, wenn man es "richtig falsch" aufgerufen hat (siehe http://www.schroepl.net/projekte/gzip_cnc/security.htm). Damit konnte man dann weitere fehlerhafte Scripte suchen und so nicht nur den gesamten Webserver kopieren, sondern auch noch Daten auf dem Server manipulieren.

Alexander

[MatzeA]

Servus,

das mit dem Zeigefinger ist soweit schon ok.
Nur bezüglich Sicherheit, bin ich auch deswegen etwas nachlässiger, da sich das Script ohnehin nur im "sichern" Intranet aufrufen lässt.
Bei uns ist Intranet und extranet sowie Internet physikalisch abolut getrennt.

D.H. pro Umgebung 1 seperater Rechner.
Mag übertrieben klingen, aber sicherer als das ist ja eigentlich keine Firewall :-))

Gruss Matze