Ok, so my bundle has to provide its own MaskBuilder, its own
PermissionMap, and instantiate a new AclVoter. Thank you.

There is still one thing I don't get : the masks provided by my custom
MaskBuilder are similar to those provided by the default MaskBuilder,
so how can we differentiate them (I mean: at the AclProvider level)?

If my MaskBuilder provides a MASK_ACTIVATE = 8, and my PermissionMap a
permission PERMISSION_ACTIVATE with this single MASK_ACTIVATE, how
will
the AclProvider make the difference between my PERMISSION_ACTIVATE
mask with a value of 8, and a default "8" mask which means
PERMISSION_DELETE?


I hope I don't bother you with stupid questions: I have the intuition
this paradigm is suitable for all Acl needs... but I don't see how
yet. ;)




On Jan 3, 6:14 pm, Johannes <[email protected]> wrote:
> The default AclVoter has only one permission map for all classes, but
> you can add as many voters as you like with custom permission maps
> which might only process objects of a certain class. In most cases
> though, you should be fine with extending the BasicPermissionMap, and
> the MaskBuilder class.
>
> Kind regards,
> Johannes
>
> On 3 Jan., 18:01, Keven <[email protected]> wrote:
>
>
>
>
>
>
>
> > Like the Spring Security Acl, Sf2 Security Acl permissions are stored
> > in a bitmask. It means that no more than 32 (sometines 30) permissions
> > can be part of a acl, minus 7 native permissions included in the
> > BasePermissionMap => 23 to 25 free permission "slots".
>
> > In a big (but not enormous) application, this can be fille very
> > quickly, particularly if some bundles bring domain object classes and
> > related custom permissions.
>
> > Is that possible to have multiple permission maps in the same
> > application, where each stores only the permissions for a single
> > domain object class?
> > If not, how can we handle more than ~25 permissions, avoiding
> > collision between several bundles?
>
> > (AFAIK Spring Securit doesn't bring any solution for this problem)

-- 
If you want to report a vulnerability issue on symfony, please send it to 
security at symfony-project.com

You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en

Reply via email to