Ich bereite mich darauf vor, die abgespeckte Version der rollenbasierten Zugriffskontrolle in meiner Anwendung zu implementieren. Ich überlege, wie / was ich in meinem Dokumentspeicher modellieren könnte, was zufällig mein Ding mit mongoose.js ist lib ". Aber diese Frage sollte für jeden Dokumentenspeicher gelten.
Es scheint ziemlich normal zu sein, dass die Entscheidung zwischen der Verwendung von eingebetteten Objekten und Referenzen bei der Verwendung eines Dokumentenspeichers angesichts der konkurrierenden Faktoren der Verdopplung und der Leistung eine Herausforderung darstellt und was nicht. Ich versuche, die RBAC so einfach wie möglich zu halten und nicht verschachtelte Collections / Ref IDs zu verwenden, was eine Menge Loops bedeuten würde, über die Verwendung von Mungos, etc.
Frage:
Ich bin bereits darauf aus, Sammlungen für Benutzer, Berechtigungen und Rollen zu haben. aber macht es Sinn, Operationen und Ressourcen zu modellieren, oder einfach key / vals für diese?
Siehe das Codebeispiel unten oder jsfiddle , das helfen sollte, das Problem zu klären. Beachten Sie, dass es nicht die Art ist, wie ich dies implementieren möchte, sondern nur eine Möglichkeit, Beziehungen zu untersuchen!
%Vor%BEARBEITEN: Angenommen, die Rollen müssen auf App-Basis bearbeitet werden können. Daher möchte ich Administratoren möglicherweise erlauben, die Zugriffsrechte zu kontrollieren. Deshalb möchte ich eine Datenbank verwenden.
Alles in der Anwendung zu tun, was nicht funktioniert, vorausgesetzt, dass es bestehen und möglicherweise geändert werden muss. Ein Kompromiss in dieser Richtung ist jedoch nur die Rollensammlung:
%Vor%Und dann könnte ich Änderungen wie Entfernung, etc., wie folgt machen (vorausgesetzt, ich habe bereits einen Verweis auf ein Rollenobjekt, das von Mongo zum Zeitpunkt des Aufrufs abgerufen wurde):
%Vor%Ich habe kürzlich mongoosejs mit einem Benutzer / Rollen / Berechtigungen benötigt, die ich mit Drywall.js hatte - die tatsächlichen Berechtigungen sind Schlüssel / Wert basiert. Sie können für Gruppen freigegeben und auch auf Administratorebene granular überschrieben werden.
Obwohl es nicht genau RBAC ist, hoffe ich, dass die Überprüfung eines anderen Ansatzes Ihnen hilft, Ihrem Ziel näher zu kommen.
Projektübersicht:
Mongoose Schemata:
Genauer gesagt:
Ich bin daran interessiert, zu sehen, was Sie daraus machen.
Ihr Design hängt fast ausschließlich vom Verhalten Ihrer Anwendung ab. Was ich basierend auf den Informationen, die Sie hier angegeben haben, empfehlen würde, die Daten in Schlüssel / Werten zu behalten, nicht in der Datenbank - CRUD-Operationen werden sich nicht ändern, also gibt es keinen Grund, das in die db zu schreiben. Die "Ressourcen" sind Klassen, die Sie bereits in Ihren Code eingebaut haben, sodass Sie sie auch nicht in der Datenbank duplizieren müssen.