Aufrufe über index.php; nichtexistente Variablen

[johny7]

Moin allerseits,

ich habe zwei Fragen hier:

1. Aufrufe über index.php
Ich möchte, dass alle Aufrufe meiner Website (genau genommen ein Unterverzeichnis meiner Domain) über die index.php gehen. D.h. das manuelle Aufrufen einzelner php-Dateien soll unterbunden werden. Ich dachte, man könnte vor jede betr. Datei eine Abfrage nach dem Script-Name bzw. $_PHP_SELF
schalten und wenn da etwas anderes, als index.php steht, einfach eine Relocation auf die index.php machen. Allerdings ist das bestimmt Performance fressend, wenn da bei jedem include noch so eine Abfrage gemacht wird. Gibt es eine elegantere Variante?

2. nichtexistente Variablen
Ich frage hier und da verschiedene optionale GET-Variablen ab. Wenn eine von ihnen nicht definiert wurde, gibt es immer eine Fehlermeldung. Ich verwende dann immer ein paar Zeilen vorher

  
if (!isset($_GET['mode'])) $_GET['mode']=" ";  

um folgenden Aufruf machen zu können

  
fputs ($logfile,date("Y-m-d H:i:s")." ".$_GET['session']." ".$lv['name']." content: ".$_GET['content']." ".$_GET['mode']."\n");  

Kann ich nicht einfach die Fehlermeldung bei dieser Variable unterdrücken? Ich habe es im zweiten Beispiel schon mit einem @ vor der Funktion und unmittelbar vor der Variable versucht.

Danke im Voraus für die Antworten
Grüße, JN

[ChrisB]

Hi,

1. Aufrufe über index.php
   Ich möchte, dass alle Aufrufe meiner Website (genau genommen ein Unterverzeichnis meiner Domain) über die index.php gehen. D.h. das manuelle Aufrufen einzelner php-Dateien soll unterbunden werden. Ich dachte, man könnte vor jede betr. Datei eine Abfrage nach dem Script-Name bzw. $_PHP_SELF
   schalten und wenn da etwas anderes, als index.php steht, einfach eine Relocation auf die index.php machen. Allerdings ist das bestimmt Performance fressend, wenn da bei jedem include noch so eine Abfrage gemacht wird. Gibt es eine elegantere Variante?

Scripte ausserhalb des Document-Root ablegen, so dass sie per HTTP gar nicht aufrufbar sind.

Kann ich nicht einfach die Fehlermeldung bei dieser Variable unterdrücken?

Unsauber Programmieren kannst du immer, wenn du willst.
Du *solltest* es aber nicht wollen.

MfG ChrisB

[dedlfix]

Hi!

D.h. das manuelle Aufrufen einzelner php-Dateien soll unterbunden werden. [...] Gibt es eine elegantere Variante?

• Sie außerhalb des DocumentRoot abzulegen benötigt keine Kopfstände, die man für jede Datei wiederholen muss.
• Wenn die Dateien nur definierenden (Klassen und Funktionsdefinitionen) und keinen ausführenden Code enthalten, kann ein Aufruf keinen Schaden anrichten und erzeugt auch keine Ausgabe.
• In den Dateien, deren Aufruf gestattet ist, eine Konstante definieren und deren Vorhandensein in den anderen Dateien prüfen. Wenn nicht, stirb!

Ich frage hier und da verschiedene optionale GET-Variablen ab. Wenn eine von ihnen nicht definiert wurde, gibt es immer eine Fehlermeldung.
Kann ich nicht einfach die Fehlermeldung bei dieser Variable unterdrücken?

In einer Produktivumgebung sollte sowieso display_errors ausgeschaltet sein. Die auftretenden Meldungen sollten aber nicht im Nirvana verschwinden sondern auf irgendeine Weise gesammelt und kontrolliert werden. Wenn du nicht ständig solche nichtigen Meldungen sehen willst, programmiere so, dass sie nicht auftreten. Sie zu unterdrücken ist in der Regel keine Lösung, denn du unterdrückst damit nicht gezielt sondern einfach alles.

Lo!

[johny7]

Moin allerseits,

In einer Produktivumgebung sollte sowieso display_errors ausgeschaltet sein. Die auftretenden Meldungen sollten aber nicht im Nirvana verschwinden sondern auf irgendeine Weise gesammelt und kontrolliert werden. Wenn du nicht ständig solche nichtigen Meldungen sehen willst, programmiere so, dass sie nicht auftreten. Sie zu unterdrücken ist in der Regel keine Lösung, denn du unterdrückst damit nicht gezielt sondern einfach alles.

Ich will nicht alles unterdrücken. Kann ich denn nicht festlegen, dass z.B. das Nicht-Vorhandensein der Variable $wiitzbold ignoriert wird? Wie gesagt, bei if(@$wiitzbold)... funktioniert das. Ich sehe im Script dann natürlich, was gemacht wird. Nur bei meine_funktion("hallöle,asd".@$wiitzbold); funktioniert das nicht.

Grüße, JN

[fastix®]

Moin!

Ich will nicht alles unterdrücken. Kann ich denn nicht festlegen, dass z.B. das Nicht-Vorhandensein der Variable $wiitzbold ignoriert wird?

Dann frag doch vorher danach:

if (isset($wiitzbold)) {
   meine_funktion("hallöle,asd".$wiitzbold)
} else {
   # mach doch was Du willst.
}

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[fastix®]

Moin!

In einer Produktivumgebung sollte sowieso display_errors ausgeschaltet sein.

[x] Dagegen.

Man sollte als Kunde ruhig sehen, was für einen Dreck man sich mit mancher Software auf den Server lädt. Ich hatte mal den Fall, dass sich ein bekanntes CMS nicht mal installieren ließ, weil die Fehlermeldungen wegen nicht gesetzter Variablen das Senden von Headern unterbanden. Ich habe dann dem Kunde mitgeteilt, dass ich nicht nur nicht für die Fehlerfreiheit der Software eintrete sondern sogar davon ausgehe dass diese fehlerhaft und regelrecht gefährlich ist und ihn gebeten zu entscheiden ob es beim Auftrag (Installation dieses CMS) bleibt. Als der Kunde dann ein paar Wochen später seltsame Javascripte (die PDFs von einem chinesischen Server in einem IFRAME  luden) auf seinen Seiten fand habe ich ihm dann recht trocken entgegen können...

Klar ist nur eines: Da wo keine Fehler sind hat auch ein display_errors(E_ALL) nichts zu melden.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[dedlfix]

Hi!

In einer Produktivumgebung sollte sowieso display_errors ausgeschaltet sein.
[x] Dagegen.

Man sollte als Kunde ruhig sehen, was für einen Dreck man sich mit mancher Software auf den Server lädt.

Die Kunden des Kunden gehen diese Meldungen nichts an. Sie können damit nichts anfangen und sollen es auch nicht. Man kann es ja gern mal mit display_errors=on testen, aber nicht damit laufen lassen. Ebenso sind Konstrukte, die beispielsweise mysql_error() ausgeben nicht produktiv-geeignet.

Fehler gehen nur einen Administrator was an und sollten ihm zugänglich gemacht werden, aber wie gesagt nicht dem Laufpublikum.

Lo!

[suit]

Fehler gehen nur einen Administrator was an und sollten ihm zugänglich gemacht werden, aber wie gesagt nicht dem Laufpublikum.

Jein - bestimmte Fehlermeldungen helfen dem Endbenutzer sehrwohl, wenn sie sinnvoll ist.

z.B. "Leider ist unser Angebot zur Zeit überlastet, versuche es später erneut." im Design der Seite hilft einen normalen Benutzer durchaus mehr weiter als die Default-Fehlermeldung des Webservers die dann von seinem Browser verscheiert wird ohne zu sagen, was sache ist.

Irgendwelche PHP-Fehlermeldungen sollte der Benutzer hingegen nicht sehen.