Dans la plupart des applications Web, le modèle de sécurité est défini au niveau de la logique métier, et non au niveau des données.
Par exemple, ma capacité à modifier un message sur Stack Overflow n'est pas contrôlée par ma capacité à lire/écrire dans la table "posts" - en fait, vous ne pourriez probablement même pas concevoir un schéma de base de données qui vous permettrait d'implémenter au niveau de la base de données sécurité à ce niveau. Au lieu de cela, il y a une couche de logique métier qui compare mes privilèges avec l'action que j'essaie de prendre (je suppose); la sécurité est implémentée au niveau de la couche logique métier.
Franchement, je ne vois presque aucun avantage à transmettre les informations d'identification à la couche de base de données - si d'une manière ou d'une autre j'avais contourné la logique métier pour contrôler qui peut modifier les messages SO, les contrôles de "lecture/écriture" de la base de données ne l'empêcheraient pas, et l'audit ne le ferait pas ça ne t'aide pas vraiment.
Je vois BEAUCOUP d'inconvénients - notamment le fait que vous allez diviser votre logique d'autorisation en deux (logique métier et base de données), et introduire toutes sortes de modes d'échec amusants avec la synchronisation des comptes sur votre couche de logique métier et votre couche de base de données (les utilisateurs changent leur mot de passe ou quitter le site Web). Je ne peux pas commencer à imaginer comment vous pourriez tester et déboguer sainement tout cela :que se passe-t-il si un utilisateur final reçoit une erreur liée à ses privilèges de base de données ?
