In den meisten Webanwendungen wird das Sicherheitsmodell auf der Ebene der Geschäftslogik definiert, nicht auf der Datenebene.
Zum Beispiel wird meine Fähigkeit, einen Post auf Stack Overflow zu bearbeiten, nicht durch meine Fähigkeit kontrolliert, in die Tabelle „posts“ zu lesen/schreiben – tatsächlich könnten Sie wahrscheinlich nicht einmal ein Datenbankschema entwerfen, das Ihnen erlauben würde, Datenbankebene zu implementieren Sicherheit auf dieser Ebene. Stattdessen gibt es eine Ebene der Geschäftslogik, die meine Privilegien mit der Aktion vergleicht, die ich zu ergreifen versuche (nehme ich an); Die Sicherheit wird auf der Ebene der Geschäftslogik implementiert.
Ich sehe ehrlich gesagt fast keinen Vorteil darin, Anmeldeinformationen an die Datenbankschicht weiterzugeben - wenn ich irgendwie die Geschäftslogik umgangen hätte, um zu steuern, wer SO-Posts bearbeiten kann, würden die "Lesen/Schreiben"-Steuerelemente der Datenbank dies nicht verhindern, und die Prüfung würde nicht Das hilft dir nicht wirklich weiter.
Ich sehe VIELE Nachteile - nicht zuletzt die Tatsache, dass Sie Ihre Autorisierungslogik in zwei Teile aufteilen (Geschäftslogik und Datenbank) und alle Arten von unterhaltsamen Fehlermodi einführen, indem Sie Konten über Ihre Geschäftslogikschicht und Datenbankschicht hinweg synchronisieren (Benutzer ändern ihre Passwort oder Verlassen der Website). Ich kann mir nicht vorstellen, wie Sie all dies vernünftig testen und debuggen würden - was passiert, wenn ein Endbenutzer einen Fehler bezüglich seiner Datenbankberechtigungen erhält?
