I love Shiro.
That being said I believe it is ill suited to situations like the one you
describe. We sell a ECM / DMS product where customers may store millions of
documents. If we were to store every document's permissions with the user or
role that would not only mean millions of permissions attached to every role
but would also introduce race conditions when trying to modify a role's
permissions inside the database - multiple users modifying permissions for
the same role simultaneously.
Because of that, we chose to write our own permission system to control
access to documents individually: Per-document-permissions are not stored
with the user or role but with the document itself. Every document has a
java.util.Map<String, String> as property which consists of role names as
keys and a java.util.BitSet as values (represented as a String). The bits of
the BitSet are an enum of the form
public enum Bit {
v, r, w, d;
}
where v allows for viewing (whether the document exists), r allows for
reading (open document to read its contents), w allows for writing / editing
the document and d allows for deleting the document.
We use Shiro permissions to control which class methods or JSF components
(like buttons etc.) a role may access - so basically for everything not
particular to a specific document - and then additionally check whether a
role may perform the requested action on the specific document using our own
permission system.
--
View this message in context:
http://shiro-user.582556.n2.nabble.com/Row-level-Access-Control-Tips-tp7581124p7581128.html
Sent from the Shiro User mailing list archive at Nabble.com.
