Mischen von Sicherheitslogik mit Modellen in Ruby on Rails?

Question

Ist es ein schlechter Entwurf, Code zu mischen, der sich mit Sicherheitslogik im Modell beschäftigt?

Beispiel eine Seite in dem BEFORE_SAVE Rückruf zum Bearbeiten

• Der aktuelle Benutzer aus der current_user Methode in der Controller-Schicht gepackt ist.
• Exception werfen, wenn current_user.has_permission? :edit_page falsch ist
• Die editor_id-current_user.id
• Die Änderung in einer separaten Tabelle angemeldet ist gesetzt

Das Modell ist nicht die einzige Sicherheitskontrolle in der Anwendung. Die Benutzerschnittstelle prüft vor Ansichtsbearbeitungsansichten auf Berechtigung. Das Modell wirkt als Barriere gegen alle Fehler auf der View/Controller-Ebene.

Hinweis: Der einzige Verstoß zwischen den Modell- und Controller-Ebenen ist die current_user Methode. Die Anwendung, an der ich arbeite, wird niemals anonyme Benutzer zulassen.

Answer 1

Ich denke nicht, dass es schlechtes Design ist, Sicherheitslogik in das Modell zu bringen. Sie stellen Geschäftslogik dort und Sie könnten Sicherheitslogik als eine Art Geschäftslogik betrachten. Sie wollen sicherlich nicht alles in der Steuerung oder der Ansicht, Sie wollen den skinny controller, fat model Ansatz folgen.

Ihre Modelle sollten als zusammenhängender Teil der Anwendungslogik allein stehen. Sie sollten Ihre Modelle vollständig von der Rails-Konsole aus steuern können. Die Sicherheitslogik im Modell erleichtert außerdem den Komponententest.

Answer 2

Ich würde sagen, es hängt davon ab, ob Ihre Modelle direkt zugänglich sein sollen. Wenn ja, dann sollte das Bewusstsein für Sicherheitsbedenken gewahrt werden, wahrscheinlich über ein Mixin, da solche Bedenken wahrscheinlich etwas zu den Hauptanliegen des Modells orthogonal sind.

Wenn die Modelle unsichtbar sein sollen und Sie bereits Ihre Sicherheitslogik in Ihren Controllern haben, würde ich die Modelle in Ruhe lassen.

Answer 3

Das Modell in einem MVC-Framework soll vollständig Ihre gesamte Geschäftslogik enthalten. In einer gut entworfenen MVC-Anwendung sollten Sie zumindest theoretisch in der Lage sein, Ihre Modelle in einem anderen Kontext wiederzuverwenden, ohne Ihre Geschäftslogik neu implementieren zu müssen.

In jedem Fall kann ich denken, Autorisierung, Eingabe-Validierung und Audit-Protokollierung sind sehr auf jeden Fall Geschäftslogik, und so sollte in Ihrem Modell behandelt werden.

Auf der anderen Seite, denke ich, Authentifizierung, Verschlüsselung, kryptographische Hashing, etc. sind nicht Teil des Modells. Diese Sicherheitsaspekte sind nicht Teil der Kerngeschäftslogik, sie sind normalerweise Teil der Anwendungsschnittstelle.