MySQL Loginsystem

[dedlfix]

Hi!

Insbesondere interessiert mich, ob ihr die verwendeteten Zugriffsarten und statischen Funktionen auch so angewendet hättet.

Erlaubt ist was gefällt, funktioniert und keine Fehler aufweist. Zusätzlich kannst du dir ja (gedanklich) Begründungen geben, warum du etwas auf eine Weise machst und nicht eine Alternative verwendest.

Auch würde ich gerne wissen, ob man auf statische Methoden auch anders als mit KLASSENNAME::METHODENNAME() zugreifen kann.

Innerhalb einer Klasse gibt es self, das den Klassennamen verkörpert, quasi ein statisches Pendant zu $this.

  	$sections\_to\_escape=array('USER\_TABLE', 'LOGIN\_TABLE', 'LOGIN\_DENIED\_TABLE', 'RIGHTS\_TABLE');  
  	$escape\_amount=4;  

Und wenn du mal vergisst, beim Erweitern des Arrays den Zähler anzupassen? Besser count($sections_to_escape) statt einer händisch eingefügten Zahl. Das verdeutlicht auch gleich was es mit dem Wert auf sich hat, ohne dass man nachzählen muss.

  	for ($i=0; $i<$escape\_amount; ++$i)  

Allerdings würde ich generell auf eine extra Variablen verzichten und das count() gleich in die for-Schleife einbauen. Das bisschen Geschwindigkeit, das beim erneuten Zählen pro Schleifendurchlauf draufgeht, geht im Grundrauschen unter. Und da du eigentlich an den Werten interessiert bist und der Zähler egal und nur Hilfsmittel zum Indexieren ist, plädiere ich für ein foreach. Das was du beim separaten count() gespart hast (wenn es dir dabei um Performance ging), geht übrigens durch das pro Iteration dreimalige Auflösen-Müssen von sUserAuthSystem::$settings[$sections_to_escape[$i]] wieder drauf.

Wie Ihr sehen könnt, habe ich auch beschlossen, das escapen der Indentifier bereits in der Einlesefunktion durchzuführen - dann muss ich bei den SQL-Anfragen nicht mehr daran denken.

Keine gute Idee. Das richtige Maskieren ist lebenswichtig. Deshalb darf man es nie vergessen oder sich auch nur das Darüber-Nachdenkenmüssen sparen wollen. Wenn du mal irgendwann über einen anderen Weg als über die Einlesefunktion kommen willst, und dich nicht mehr richtig erinnerst, dass nur deshalb die SQL-Abfrage sicher ist, dann ...

Ein Kontextwechsel und die Behandlung dafür sollten eine Einheit bilden, damit die Übersichtlichkeit nicht darunter leidet.

Lo!