W większości aplikacji internetowych model zabezpieczeń jest definiowany w warstwie logiki biznesowej, a nie w warstwie danych.
Na przykład moja zdolność do edycji postu na Stack Overflow nie jest kontrolowana przez moją zdolność do odczytu / zapisu do tabeli "posts" - w rzeczywistości prawdopodobnie nie mógłbyś nawet zaprojektować schematu bazy danych, który pozwoliłby na zaimplementowanie na poziomie bazy danych bezpieczeństwo na tym poziomie. Zamiast tego istnieje warstwa logiki biznesowej, która porównuje moje uprawnienia z akcją, którą próbuję wykonać (zakładam); bezpieczeństwo jest zaimplementowane w warstwie logiki biznesowej.
Szczerze mówiąc, nie widzę prawie żadnej korzyści z przekazywania poświadczeń do warstwy bazy danych - gdybym w jakiś sposób ominął logikę biznesową do kontrolowania, kto może edytować posty SO, kontrolki bazy danych "odczyt/zapis" nie zapobiegłyby temu, a audyt nie naprawdę ci pomóc.
Widzę WIELE niedogodności - nie tylko fakt, że podzielisz logikę autoryzacji na dwie (logikę biznesową i bazę danych) i wprowadzisz wszelkiego rodzaju zabawne tryby awarii z synchronizacją kont w warstwie logiki biznesowej i w warstwie bazy danych (użytkownicy zmieniający swoje hasło lub opuszczenie strony internetowej). Nie potrafię sobie wyobrazić, jak byś rozsądnie testował i debugował to wszystko — co się stanie, jeśli użytkownik końcowy otrzyma błąd związany z jego uprawnieniami do bazy danych?
