• Das Erstellen neuer Accounts wurde ausgesetzt. Bei berechtigtem Interesse bitte Kontaktaufnahme über die üblichen Wege. Beste Grüße der Admin

real_escape_string in einer Schleife verwenden

Lucky777

New member
Geehrtes Forum,

ich habe ein Suchformular und möchte, dass alle Eingabedaten (Textfelder, Checkboxen etc.) mittels real_escape_string überprüft werden. Die Herstellung der Datenbankverbindung erfolgt über "new mysqli". Ich habe dazu in meiner Funktionsbibliothek folgende Funtkion geschrieben:

PHP:
function escape_all($var) {
  if(is_array($var)) {
   foreach($var as &$value) {
  	$value = escape_all($value);
   }
  } else {
   $var = $db->real_escape_string($var);
  }
  return $var;
 }

Der Aufruf sieht folgendermaßen aus:

PHP:
@$db = connect_db(); // Aufruf der Funktion, welche mittels "new mysqli" eine Datenbankverbindung herstellt

$_GET = escape_all($_GET);

Allerdings bekomme ich die Fehlerfeldung "Undefined variable" für "$db". Leider kenne ich mich in PHP nicht besonders gut aus. Weiß jemand was ich Falsch mache?
 
escape_all kennt deine variable $db nicht da sie der Funktion nicht übergeben hast
PHP:
@$db = connect_db();

function escape_all($var, &$db) {
    if(is_array($var)) {
        foreach($var as &$value) {
        $value = escape_all($value, $db);
    }
    } else {
        $var = $db->real_escape_string($var);
    }
    return $var;
}

$_GET = escape_all($_GET, $db);
 
Je nach php version passiert das nicht automatisch, schlimmstenfalls kriegt man dann ne kopie des objektes.
Ich glaube objekte werden erst seit spätem php4 bzw php5 automatisch als referenz übergeben, davor musste man sich selber drum kümmern wenn man keine Kopien haben wollte - und selbst wenns automatisch passiert geht nix kaputt wenn man explizit die referenz angibt.
 
Also dieses ganze real_escape Gedönze könnte man sich sparen, wenn man stattdessen durchgängig Prepared Statements einsetzen würde.
 
jupp, vor allem wenn man eh schon mit dem mysqli objekt arbeitet wie Lucky777 es ja scheinbar tut
 
Danke für eure Beiträge, die "skooli" Methode funktioniert tadellos.

Von "Prepared Statements" höre ich heute zum ersten mal, ich bin quasi ein Neuling. Jedenfalls danke für den Hinweis, ich werde etwas recherchieren.
 
Je nach php version passiert das nicht automatisch, schlimmstenfalls kriegt man dann ne kopie des objektes.
Ich glaube objekte werden erst seit spätem php4 bzw php5 automatisch als referenz übergeben, davor musste man sich selber drum kümmern wenn man keine Kopien haben wollte - und selbst wenns automatisch passiert geht nix kaputt wenn man explizit die referenz angibt.
Stimmt - hab' selbst nie mit PHP4 gearbeitet... und ich finde, mal sollte das auch nicht mehr tun.
In PHP5 hat man damit keine Probleme - deswegen war ich etwas irritiert.

PS: prepared statements sind zwar an sich eine tolle Sache, ABER wenn man ein paar Felder hat, die auch NULL sein können muss man sich trotzdem wieder mit den expliziten Werten der Abfrage auseinandersetzen (und würde bei einer Schleife über viele Abfragen den Vorteil des "prepared" völlig verlieren). Da ich extrem viel mit NULL arbeite bin ich deswegen nicht so der Fan davon.

PPS: OK - hab' gerade das gefunden: http://de3.php.net/manual/en/mysqli-stmt.bind-param.php#103144 ist zwar nicht besonders elegant, aber macht das Ganze doch handelbar... werde meine Präferenzen wohl etwas ändern müssen...

PPPS: Warum werden hier im Forum eigentlich alle "pr" unterstrichen mit einem Hinweis "page ranking"? Irgendwie dämlich...
 
Zuletzt bearbeitet:
PS: prepared statements sind zwar an sich eine tolle Sache, ABER wenn man ein paar Felder hat, die auch NULL sein können muss man sich trotzdem wieder mit den expliziten Werten der Abfrage auseinandersetzen (und würde bei einer Schleife über viele Abfragen den Vorteil des "prepared" völlig verlieren). Da ich extrem viel mit NULL arbeite bin ich deswegen nicht so der Fan davon.
Also vielleicht habe ich eine andere Herangehensweise beim Datenbankdesign oder den Abfragen, aber ein Problem mit NULL Spalten habe ich bislang noch nicht feststellen können. Sicherlich muss man bei den WHERE Bedigungen NULL anders abfragen, als "normale" Werte, aber die Sonderbehandlung habe ich beim direkten Zusammenklöppeln auch. Und bislang hatte ich noch nicht den Fall, dass ein Benutzer direkt nach NULL suchen konnte, wenn dann war das immer ein Spezialfall.
Und prepared Statements bedeuten ja nicht, dass man sich seine WHERE Bedingungen nicht dynamisch zusammenbauen kann.
 
NULL ist bei mir relativ häufig - mal sehen, ob ich dafür eine gute Behandlung hinbekomme, ohne mich darum immer händisch zu kümmern.
Klar muss man sich bei normalen Statements auch um NULL kümmern (man muss sich ja um alles kümmern) - wär' hald gut, wenn es eine Möglichkeit gäbe, bei der man sich um nichts kümmern muss...
 
Zurück
Oben