Ve většině webových aplikací je model zabezpečení definován ve vrstvě obchodní logiky, nikoli v datové vrstvě.
Například moje schopnost upravovat příspěvek na Stack Overflow není řízena mou schopností číst/zapisovat do tabulky „příspěvků“ – ve skutečnosti byste pravděpodobně ani nemohli navrhnout schéma databáze, které by vám umožnilo implementovat na úrovni databáze. zabezpečení na této úrovni. Místo toho je tu vrstva obchodní logiky, která porovnává moje privilegia s akcí, kterou se snažím provést (předpokládám); zabezpečení je implementováno na vrstvě obchodní logiky.
Upřímně řečeno nevidím téměř žádný přínos v předávání přihlašovacích údajů do databázové vrstvy – pokud bych nějak obešel obchodní logiku pro řízení toho, kdo může upravovat příspěvky SO, nezabrání tomu ani kontroly „čtení/zápis“ v databázi a auditování by to nezabránilo. opravdu vám nepomůžu.
Vidím SPOUSTU nevýhod – v neposlední řadě skutečnost, že rozdělíte svou autorizační logiku na dvě (obchodní logiku a databázi) a zavedete všechny druhy zábavných režimů selhání se synchronizací účtů napříč vrstvou vaší obchodní logiky a databázovou vrstvou (uživatelé mění své heslo nebo opuštění webové stránky). Nedokážu si představit, jak byste to všechno rozumně testovali a ladili – co se stane, když koncový uživatel dostane chybu související s jeho právy k databázi?