Zitat von fkerber:

Sehe ich das richtig, dass du keine Prepared-Statements verwendest?

Gründe u.a.:
*) Besserer Schutz vor SQL-Injections

grade erst gesehn

Ja, im Code selber nutze ich sowas nicht, bzw. in einer etwas anderen Form vielleicht doch ... das ist aber alles in der Datenbankklasse integriert.

Einzig und alleine über die Feldnamen könnte man die "Schutzmaßnahmen", mittels bestimmter Prefixe absichtlich abschalten, aber von extern kommt man da nicht ran.


Ein Insert war z.B. so möglich.

markieren

Code:

function User_Set($Name, $Password, $Rights) {
  global $Config;
  $Config['DB']->Insert('UserTable', array(
    'Name'    => trim($Name),
    'Password' => $Password,
    'Rights'  => $Rights));
  return $Config['DB']->LastResult;
}

oder

markieren

Code:

return $Config['DB']->Insert('UserTable', array(
  'Name'    => trim($Name),
  'Password' => $Password,
  'Rights'  => $Rights));

oder auch sowas

markieren

Code:

if ($DB->Update('Irgendwas', array('feld' => 12345))) ...

hier würde der "feld ..."-Teil direkt übergeben
(hab halt keinen Query-Parser integriert)

markieren

Code:

if ($DB->Update('Irgendwas', 'feld = 12345')) ...
if ($DB->Update('Irgendwas', array('feld = 12345', 'x' => 0))) ...

man kann nur ein paar "grundlegende" Funktionen (mir reichen diese aber meistens aus) aufrufen, ihnen irgendwelche WHERE-, Feld- oder Daten-Listen mitgeben und dieses wird dann intern zusammengesetzt und z.B. über mysql_real_escape_string abgesichert/maskiert.

Zitat von himitsu:

zusammengesetzt und z.B. über mysql_real_escape_string abgesichert/maskiert.

So hab ich das bislang auch gemacht. Allerdings haben mich die PS überzeugt. Ich denke, ich werde meinen Code entsprechend umstellen.

Guck dir mal die PDO-Referenz an. Da siehst du was mit Prepared Statements gemeint ist

BTW (auch @Mithrandir): ich kann hier nur die Verwendung eines ORM (wie z.B. Doctrine) empfehlen.

Greetz
alcaeus

Zitat von alcaeus:

ich kann hier nur die Verwendung eines ORM (wie z.B. Doctrine) empfehlen.

Nu' hab ich ja schon 'ne fertige Datenbankklasse implementiert und komme eigentlich auch gut damit klar. Was wäre denn der Vorteil, ganz grob umrissen, den ich mit Doctrine hätte? Denn immerhin bedeutet das ja auch, dass ich mich in ein neues System einarbeiten müsste. Daher tue ich mich auch noch schwer, auf symfony umzuschwenken, zumal das System nahezu komplett ist.
Auf der anderen Seite könnte ich mir aber auch vorstellen, dass symfony einiges vereinfachen könnte. Hab mir mal das Tutorial mit der Job-Website durchgelesen. Grob erinnert mich so ein PHP-Framework an die VCL in Delphi.

Der Vorteil von Doctrine? Nu ja, nehmen wir an du hast eine Tabelle "Student" mit folgenden Spalten: id, lastname, firstname, birthday, matr.
Du hast entsprechend eine Klasse "Student" mit den Properties id, lastname, firstname, birthday, matr. Jedesmal wenn du Daten aus der Datenbank holst, werden automatisch die Objekte erzeugt, so dass du direkt damit arbeiten kannst:

markieren

PHP-Quellcode:

$student = Doctrine::getTable('Student')->findOneById($studentId);
if (!$student) {
// ...
}
$student->notifyAboutExams();

Das ist jetzt ein etwas stupides Beispiel, aber der Vorteil ist ganz eindeutig: jeder Datenbankzeile wird automatisch eine Objektinstanz zugewiesen.

Zusaetzlich gibts dann noch Plugins (Behaviors), welche dir Aufgaben abnehmen, z.B. das automatische Befuellen von Create- und Update-Timestamps, Soft-Delete, I18N (so dass du z.B. eine Kategorie hast, den Titel aber in beliebig viele Sprachen hinterlegst), uvm.

Zusammen mit Symfony kommt dann hinzu, dass dir diese Model-Klassen automatisch generiert werden, genauso wie die Formulare zur Datenmanipulation. Du hast also sehr schnell dein Skeleton anhand dessen du die Applikation zusammenbaust. Ist ein sehr interessanter Ansatz

Greetz
alcaeus

Ok, das klingt wirklich nicht schlecht. Ich werde wohl erstmal bei meinem alten System bleiben, mir aber in den kommenden Monaten mal Doctrine/Symfony genauer angucken. Danke für die Erklärung.

eigentlich 'ne recht nette Sache

markieren

Code:

function loadClass($name) {
  // zum Schutz, damit man hier kein Sicherheitsloch reinbekommt
  $name = str_replace(array('/', '\\', ':'), '_', $name);

  if ((($file = __DIR__ . "/includes/$name.inc.php") && file_exists($file))
       || (($file = __DIR__ . "/includes/$name.php") && file_exists($file)))
    require_once $file;
}

spl_autoload_register('LoadClass'), true);

schon hätte man einen Miniatur-Autoloader für ein kleines Projekt

nun nur noch alle Klassen nach /includes/ , jeweils in eine Datei mit dem Namen {Klassenname}.php

und schon kann man sich alle include/require sparen.

Moin,

Zitat von himitsu:

$name = str_replace(array('/', '\\', ':'), '_', $name);

mitdenken bitte. Versuch mal folgenden Code auszufuehren (jede Klasse einzeln):
class Foo\Bar { } class Foo/Bar { } class Foo:Bar { } Ersteres ist unter PHP 5.3 eine Namespace-Definition, da ist die Ersetzung echt doof (wobei ich jetzt auch keine Zeit habe zu gucken, was da dem Autoloader uebergeben wird). Alles andere wird dir der Parser wieder rueckwaerts an Kopf werfen, entsprechend kannst du die Ersetzung auch rauswerfen. Schliesslich ist da ja nichts drin was User-generated ist. Falls doch, zurueck an den Planungstisch und das Anwendungskonzept neu erstellen.

Ich empfehle uebrigens das Zend-Naming-Scheme:
<NS>_Class_Where_Parts_Represent_Folders. Vom include_path ausgehend wuerde er die Klasse in <NS>\Class\Where\Parts\Represent\Folders.php suchen. <NS> ist dabei dein "Namespace" (nicht zu verwechseln mit echten Namespaces). Der wurde eingefuehrt um Kollisionen zu vermeiden, wie z.B. zwischen dem heutigen Zend_Date (frueher nur "Date") und der PHP-Standard-Klasse Date. Bei dir koennte es z.B. FNSE_Controller_Abstract heissen.

Greetz
alcaeus

PS: mit User-generated meine ich bspw. sowas:

markieren

PHP-Quellcode:

$foo = $_GET['foo'];
$bar = new $foo();