Druckbare Version
Hallo zusammen,
kurze Frage wegen einer Fehlermeldung die ich bekomme. Auftauchen tut diese wenn ich meinen Adminforce aufrufe.
Notice: Undefined index: check in /var/www/web36/html/adminforce/index.php on line 5
Sämtlich Dateien sind exakt so wie im grundscript hier zum Download steht. Außer natürlich die functions.lib
Wäre schön wenn mir jemand verklickert was genau da los ist.
Minki
Dein Server ist so eingestellt, dass er dir jede kleinste Warnung ausgibt:wink:
functions.lib.php, vor "?>" das einfügen:
PHP-Code:error_reporting(E_ALL & ~E_NOTICE);
Oder alternativ das komplette Script durcharbeiten, und alle Variablen vor deklarieren:
In deiner Fehlermeldung geht es um den Index in einem Array, also dann sowas wie:PHP-Code:if(!isset($foo))$foo = 0; //je nach wert, also obs nachher eine zahl sein soll, ein String, ein object, am besten gleich den richtig standardwert wählen
Man könnte natürlich auch abfragen, ob $foo existiert, ob es überhaupt ein Array ist etc.PHP-Code:if(!isset($foo['bar']))$foo['bar'] = '';
Selbst wenn PHP da Scriptsprache auch vollkommen ohne auskommt, hilft sowas a) dass man schon am Scriptanfang verwendete Variablen aufzählt, zwecks Übersicht und so b) dass PHP dadurch natürlich auch "Arbeit" abgenommen bekommt.
beim string:
$foo = (!isset($_REQUEST['foo']) ? '' : addslashes($_REQUEST['foo']));
beim integer:
$foo = (!isset($_REQUEST['foo']) ? 0 : (int)$_REQUEST['foo']);
Zitat:
Zitat von breaker
- Warum $_REQUEST:suspicious::eek:
- Warum addslashes():der:
$_REQUEST deshalb, weil es $_POST und $_GET abdeckt.....und addslashes wohl zum Escapen gefährlicher Vars :rolleyes:Zitat:
Zitat von Sebmaster
Generell sollte man restlos alles Escapen, was vom User/Admin/Netzwerken (abruf) im Script landet
Um es dann später wieder zu ent-escapen wenn man damit arbeiten will?:frusty:Zitat:
Zitat von breaker
$_COOKIE nicht vergessen!!Zitat:
Zitat von breaker
Abgesehen davon absoluter Schwachsinn, nur $_REQUEST zu verarbeiten, wenn das Script später dann $_GET bspw. nutzt :frusty:
Je nach Server Konfig haben Laufzeit Änderungen an $_GET keine Auswirkungen auf $_request etc.
Generell sollte man $_REQUEST überhaupt nicht verwenden, da es einfach zu unspezifisch ist.
Wenn ich ein Formular via POST erwarte,warum sollte ich dann dieselben Daten auch als GET annehmen?
Das mit dem escapen kommt auf den Einzelfall an, wie verarbeite ich die Variable weiter?
Wie ist der Server eingestellt? (magic_quotes_.....)
Eben deswegen ist:Zitat:
Zitat von jpwfour
Blödsinn:rolleyes:Zitat:
Zitat von breaker
Jeder so, wie er es für richtig hält...mit meiner Methode ist noch nie jemand in mein Script eingebrochen oder konnte PHP/SQL-Injection betreiben.
Wenn ich eine Var vor dem Einfügen in die DB mit addslashes entschärfe, brauche ich sie nach dem Auslesen aus der DB nicht mit stripslashes behandeln...sollte wohl klar sein. $_REQUEST deckt nicht die $_COOKIE-Klamotte ab, das wird wohl kaum in Uris übergeben ;)
Aber solange man mit register_globals = on und nicht definierten VARs arbeitet, sollte es eh egal sein, ob man escapt oder nicht, das ganze Script ist dann sowieso nur halbherzig geschrieben.
zb. wenn "if ($_GET[protected_area])" nicht deklariert wurde, gibt es schon das 1. Sicherheitsloch und die 1. Notice-Meldung und den 1. Fehler im Script.
global $protected_area; sollte man auch getrost vergessen (Leute, bald kommt PHP6 raus oO)
Ich arbeite vielmehr mit 2 Klassen, die 1. holt mir die Konfiguration aus den Dateien und gibt sie per "$var = _getCFT('require_ver', '', true);" zurück und die 2. ersetzt das "global" oder Script-interne "include/require (once)" für Variablen komplett:
$var = getINT('var', 0, true);
$var = getVar('var', '', true);
Die beiden Klassen haben auch den Vorteil, das ich nicht ständig irgendwelchen Variablen Escapen muss, weil es das automatisch macht ;)
// Edit:
Unbekannte Variablen sollte man auch nicht nur darauf prüfen, ob sie gesetzt sind, sondern den Inhalkt auch Prüfen.
if (isset($_GET['irgendwas'])) kann alles als Inhalt haben,- oder auch nichts.
PHP bietet dafür tolle Funktionen an.
Das gleiche beim Abschicken eines HTML-Formulars, wenn ich dort ein Input-Feld habe, wo eine Zahl eingegeben werden soll (und auch eine Eingegeben wird), landet sie im PHP als String (input type="text"), aber waren wir mal ab, was die neue HTML-Version mit sich bringt....ich wünsche mir ein "<input type="int>".
Scheinbar hat sich darüber noch keiner Gedanken gemacht, wie er eine INT vom HTML auch im PHP als solches behandeln kann ohne es auf die Brutale Methode "intval($_POST['var'])" zu versuchen, denn das wäre eine nicht vorhandene Funktion "string2int",- wie gut, das PHP sehr Tolerant ist, denn im C++ würde euch ständig das Programm abschmieren ;)
Irgendwie macht mir das Angst, wenn sich die Leute nicht vorher informieren:Zitat:
Zitat von breaker
http://us3.php.net/manual/en/reserve...es.request.php
Bei alten PHP Versionen ist sogar noch:
$_FILES auch dabei.Zitat:
Deine Grundgedanken sind alle korrekt, aber man muss auch immer in die "Tiefe" gehen und Feinheiten beachten.
Und hier im Forum sag ich mal ohne jetzt jemandem auf die Füsse treten zu wollen (:wink:) sind viele "Anfänger" unterwegs, da muss man eh aufpassen, dass solch Vorschläge nicht zu sehr in Theorie ausarten, weil dann eh nur noch die mitlesen/mitkommen, die das schon wissen :yes:
Zitat:
Zitat von jpwfour
Stimmt, mein fehler, das deckt sogar ncoh mehr ab :
GLOBALS, _SERVER, _GET, _POST, _COOKIE, _FILES, _ENV, _REQUEST und _SESSION.......hätte ich eigentlich wissen müssen, hab vor ca 7 Monate mal etwas geschrieben ;)
PHP-Code:
foreach ($_REQUEST as $var => $val)
{
if (!in_array($var, array('GLOBALS', '_SERVER', '_GET', '_POST', '_COOKIE', '_FILES', '_ENV', '_REQUEST', '_SESSION')))
{
unset($$var);
}
}
unset($val);