Zusammenspiel MVC/Ajax

[dedlfix]

Tach!

Ein Request hat zunächst einmal eine Ziel-Angabe. Die ist in der Regel nicht vom Benutzer eingegeben, sondern indirekt gewählt, zum Beispiel im href-Attribut beim Klicken eines Links oder beim Absenden eines Formulars im Action-Attribut [..].

Naiv bis leichtsinnig: Parameter liegen IMMER in den Händen der Benutzer. Eine diesbezügliche Kontrolle muss absolut wasserdicht sein, damit Deine Anwendung das macht, was Du willst und nicht das, was der Benutzer will.

Also meine Anwendungen sollen das machen, was der Benutzer will. Für den schreib ich die ja. Dass der auf meinem System nicht alles machen darf, ist eine andere Geschichte. Und die hat nichts mit der generellen Art der Auswertung der Parameter für das Routing zu tun. Sicherheitsrelevante Sperren stehen im Falle von ASP.NET MVC direkt an den Controllern oder einzelnen Actions. Die starten gar nicht, wenn der angemeldete Nutzer das nicht ausführen darf. Darum kümmert sich das Framework. Ich sage nur, welche Nutzer oder Rollen Zugriff haben.

Was die fachliche Plausibilität der Daten angeht, darum kümmert sich das Model mit seinen Validatoren. Das weiß am besten was zulässig ist und was nicht. Das kann nicht Aufgabe des Routers sein. Daten können schließlich auch auf anderen Wegen daherkommen.

Gerade PHP ist in dieser Hinsicht anfällig und auch mit einer anderen PL (Perl) muss ein Programmierer sehr gut wissen was passiert, wenn ein Benutzer Parameter überschreibt indem er beispielsweise weitere gleichnamige Parameter anhängt.

PHP ist nicht anfälliger als alle anderen Systeme auch. Auch die Frameworks für PHP prüfen Daten an den üblichen sinnvollen Stellen. Programmieren müssen immer wissen, was sie tun. In jedem System.

Und das kann nicht Aufgabe eines Routers sein: Parameterkontrolle, Benutzereingaben.

Das machen die Router der mir beannten Frameworks auch nicht. Sie werten den Request soweit aus, dass die passende Controller-Action gefunden werden kann. Das Umschreiben von Request-Daten in Objekte der Anwendung ist ja auch nicht Teil des Routing-Prozesses sondern findet zwischen diesem und der Ausführung der Action statt. Weitere Kontrollen sind - siehe oben - auch nicht seine Aufgabe.

Es wird unnötig kompliziert und schwer überschaubar, wenn das jemand so macht. Besser: Das Routing endet in der Pfadangabe (ohne Parameter).

Unübersichtlich finde ich die üblichen Lösungen nicht. Die Komplexität ist bereits in der Aufgabenstellung vorhanden, weswegen man dafür ja zu solchen Systemen wie den MVC-Frameworks greift. Sie sollen die Übersicht so gut es geht bewahren. Und das geht auch gut, solange man die angebotenen Lösungswege beschreitet.

Den Pfad von nicht routing-relevanten Daten freizuhalten, ist nicht mit den Wünschen der Realität vereinbar.

http://blog.example/thema-x-y

Man möchte aus diversen Gründen eine solche URL haben und keine solche

http://blog.example/?post=thema-x-y

Das Ausgangsszenario ist also, dass der Schlüssel zum gewünschten Beitrag im Pfad steht. Der Inhalt ist nicht für den Router relevant. Für die Lieferung der Beiträge ist ein und dieselbe Controller-Action zuständig. Sie muss den Pfad-Teil übergeben bekommen, um passend die Datenhaltung abfragen zu können.

Der Router muss nur unterschieden können, ob beispielsweise /admin/... aufgerufen wurde, dann gehts zu den Controllern des Admin-Bereichs. Der Rest geht zu der für die Beiträge zuständigen Action. (Das einfache Beispiel-Blog-System kommt mit diesen beiden Mustern aus. Entweder /admin oder Default-Routing zu den Beiträgen.) Wenn /existiert-nicht aufgerufen wird, dann geht auch dieser Aufruf zur Beiträge-Action. Das ist auch kein sicherheitstechnisches Problem. Es kann in dem Fall einfach nur kein Beitrag gefunden werden und dann gibts eine Fehlermeldung. Diese Prüfung ist eine fachliche, sie wird quasi vom Model vorgenommen, wenn die Abfrage mit diesem Wert keine Daten liefert.

Einfacher gehts nicht ...

Mir scheint, mit deinem System bist du nicht nur einfach auf starre Muster festgelegt, sie kann auch einfach nicht flexibel auf die Anforderungen reagieren (die heutzutage schon existieren). Flexibilität haben zu können, heißt nicht zwangsläufig, dass die Lösung unübersichtlich chaotisch wird.

dedlfix.