In MVC-Umgebung bei JS-Validierung auf Datenbank zugreifen

[borisbaer]

Hallo Rolf,

Ich nehme mal an, dass dies die Top-Level Funktion ist, die vom Router aufgerufen wird. Nur in diesem Fall würde ich dein Hantieren mit $_GET und dem Setzen der Header für korrekt halten.

ich weiß nicht, ob das deine Frage beantwortet, aber im Router steht $router -> map( 'GET', 'verify', [ 'namespace' => 'user', 'controller' => 'sign-up', 'action' => 'verify' ] );.

Nicht korrekt ist, dass sie im Fehlerfall einen Redirect liefert. Das ist sinnlos, du möchtest den fetch() umleiten?! Wenn Du etwas tun willst für den Fall, dass jemand die API-URL im Browser eingibt: tu's nicht. Wer APIs aufruft und HTML erwartet, hat Pech. Falsche Parametrierung kannst Du mit HTTP Statuscodes beantworten.

Okay, das ist gut zu wissen, danke! Das habe ich geändert.

Deine read-Funktion bekommt ein Array mit den Spalten, für die zu prüfen ist, ob der Wert schon in der DB existiert? Kann man so machen - aber was soll read tun? Kollisionstest für genau ein Attribut? In dem Fall würde die Methode vielleicht doch besser "exists($column, $value)" heißen und einfach ein bool zurückgeben?

Momentan ist es noch so, dass ich eine universelle read-Funktion habe, bei der ich die Art und Weise des fetch-Befehls als Parameter festlegen kann. In diesem Fall wird tatsächlich nur true oder false ausgegeben, nicht die ganze Tabellenreihe als Objekt.

Und wer garantiert Dir, dass username oder email der zweite Parameter für deine Funktion sind? Davon solltest Du Dich entkoppeln und eine Prüffunktion schreiben, die schaut, ob einer von mehreren Parametern da ist. Ich habe sie erstmal ohne $this oder \App\Tools\Bla\Foo davor hingeschrieben - die kann man an geeignetem Ort unterbringen.

Hmm, wieso muss mir das jemand garantieren? Der fetch-Befehl des JS-Scripts hat doch klare Anweisungen. Aber wenn man die Methode sozusagen für einen Blindflug gewappnet sehen will, dann ja. Ich habe deinen Vorschlag mit hasKey aber übernommen! Vielen Dank! Warum hast du eigentlich „potenzielles Sicherheitsloch“ dort hingeschrieben?

Zu deiner read-Funktion und der Motivation, sie so zu gestalten, wie sie ist, kann ich nichts sagen. Soll sie einen User über einen beliebigen Schlüssel finden können, und gibt diesen User dann zurück? In dem Fall wäre der Rückgabewert viel zu umfangreich, du willst bestimmt nicht einen allgemeinen Userdaten-Reader für anonyme Benutzer bereitstellen. Deine verify-Schnittstelle sollte nicht mehr als einen Bool zurückgeben. "Geht" oder "Geht nicht". Nichts weiter.

Ja, wahrscheinlich werde ich die read-Funktion in mehrere mit einer spezifischen Aufgabe aufsplitten, anstatt eine zu haben, die sozusagen alles auslesen kann, was ich brauche.

Viele Grüße
Boris