Hello Shiro devs,Here some questions/thoughts/ideas on WildcardPermission. Multi-instances resolution I was playing a bit with WildcardPermission, and especially multi-instances ones (e.g: "news:edit:1,2,3";).I think there is something wrong or at least counter intuitive in how they're managed.For instance, let's imagine a role with the following attached permissions:If on a bulk edition, I want to check if the current subject has the permission "news:edit:1,2,3";, the result will be false.From a low-level sight it is true, as never "news:edit:1"; nor "news:edit:2,3"; imply "news:edit:1,2,3".But from a high-level point of view, it is quite silly. I shouldn't have to care how multi-instances permissions are stored,it's the overall result of the authorization info attached to the current subject that should matter.I think the problem is that in a certain way, multi-instances wildcard permissions break the Permission definition.From class Javadoc:/ "A Permission is the most granular, or atomic, unit in a system's security policy [...]"/,which is clearly not the case here as they're compound of their different instances.If "news:edit:1,2"; exists it means that "news:edit:1"; and "news:edit:2"; exist too. Possible workarounds (in increasing order of nonsense): 1- Don't bother and fix some convention Multi-instances permissions are ok for provisioning authorization info with, and are not for querying.i.e: I can affect "news:edit,delete:1,2,3"; to a role, but I mustn't check it directly from a subject. This way I shouldn't care/fear how my multi-instances permissions are stored/fetched from authorizing realms.And maybe a javadoc line of the subtilities of their use in WildcardPermission. 2-a. Ok, so permissions are atoms, and we know atoms can be broken down, so why not permissions? Introduce a sub-interface of Permission like "SplittablePermission":For the WildcardPermission implementation, it explodes all the instance paths it contains, producing something like:/"news:edit,delete:1,2,3".split() = [ news:edit:1 / news:edit:2 / news:edit:3 / news:delete:1 / news:delete:2 / news:delete:3 ]/Implementation should be quite straight-forward (using guava here): Then Permission checking should be modified accordingly (but hopefully to shiro good design: seems located to a single place in AuthorinzingRealm), thus instead of: We may have something unpretty like: Introduced overhead should be marginal when not using multi-instances permissions, and performance better than first workaround when using them. 2-b. Now permissions are radioactive atoms, let's them decay A variant, which I think is more in the Permission class spirit: a permission only having a true meaning when processed against another one.Introduce a sub-interface of Permission like "BreakablePermission":The purpose of the method is to return all permissions of input p that are not implied by himself.Returning one length array with original or equivalent permission than input means: not implied at all.Returning zero length array or null means: totally implied.Properties of this "operator" should be:For WildcardPermission, decomposition is extracting non satisfied multi-instances paths. Results could be:/"news:edit:1".notImplied("news:edit,delete:1,2";) = [ news:delete:1,2 / news:edit:2 ]"news:delete:1,2".notImplied("news:edit,delete:2";) = [ news:edit:2 ]/etc.In the same way, AuthorizingRealm should be modified to:Introduced overhead should be larger than previous version due to computation of non implied sub-paths. WildcardPermission to String WildcardPermission.toString() produces strings that are not usable as wildcard string patterns:/news:edit,delete -> "[news]:[edit,delete]"/Even if it's not in the API contract, it will be nice if it produces suitable string usable directly as pattern:Or/And maybe add a "resolveString" in the PermissionResolver to handle conversion Permission -> String (as it can be often needed when permissions are built from an UI). "Any" character In addition to the "*" wildcard character, add an "?" anything character:When implying a permission, "Any" character should behave exactly as the wildcard (implying everything):When implied, everything should implies the "Any" character (where the wildcard is only implied by itself):For instance: Use case: Taking a News CRUD application with fine-grained permission based security and heavy possibility of configuration for dynamic data-rights.We have a secured interface like:In such cases it could be pretty cumbersome to guarantee a minimal consistency within the configured data-rights and nonfunctional situations may occur (in this case not really, but in more complex system...),e.g: I'm authorized to update, and delete this news but not to see it: I've "news:update,delete:X";, but not "news:view:X".In this situation we may would like to have some kind of implicit permission, i.e: based on other permissions. If I can delete or update News X, I've necessarily the right to view it.Instead of implementing that with a custom Permission classe, we can use "?" ANY character, rewriting the interface to:Meaning: if the user is authorized to do anything secured on this news, he can view it.------------ I can propose patch(es) (if I find how to do it properly) for some of these "proposals". By the way, Making security funny is quite an accomplishment, great job Shiro!Regards,PouicAnd sorry for my English.*TL;DR:*- Carefull when using multi-instances wildcards.- Any '?' character in wildcard pattern could be nice.- Shiro rocks!
-- View this message in context: http://shiro-developer.582600.n2.nabble.com/Multi-instances-WildcardPermission-tp7577912.html Sent from the Shiro Developer mailing list archive at Nabble.com.
