...
Contact me about your AuthzGroup set you are computing for your entities... maybe there's something not quite right there.
Further responses from Glenn Golden to Jim Pease
> Just to clarify your statement:
>
> > Anything defined "above" the file cannot be changed by the file's
> > definitions, since this is all accumulative (i.e. we give permissions
> > at any level, but we cannot take them away).
>
> Based on your example below, if I am in a role with permission to do something in AuthzGroup "/content/group/", then it doesn't matter what is set at "/content/group/XYZ/" or below?
correct.
>
> Regarding the AuthzGroup set I was trying to use...
>
> Given a reference like "/gmt/global", I would return that reference in the AuthzGroup collection, whereas given a reference like "/gmt/ XYZ" where "XYZ" is a context id, I would call addSiteContextAuthzGroup.
>
good
> Essentially, based on a global configuration of my tool, I would pass a targetRef like "/gmt/global", otherwise I would use a context specific reference like "/gmt/XYZ". The idea was that in certain cases (when dealing with "global" things) permissions would be checked against the global realm regardless of the context. Am I stepping out of the bounds of the expected use here?
>
sounds good
> Also, I've noticed in most cases that the fallback is on the site context using addSiteContextAuthzGroup. Although I mention using this above, shouldn't I be using my own context specific AuthzGroup? For example, given a reference "/gmt/XYZ", my AuthzGroup set would contain "/gmt/XYZ" instead of "/site/XYZ", since the site reference implied by that authzgroup id doesn't belong to me?
>
It is ok to include the "/site/..." AuthzGroup. Common practice is to manage permissions at the site level for all related entities.
So it appears that your only problem is that you sometimes (the global case) end up with a single AuthzGroup in the set, and the permissions helper is assuming, incorrectly, for it's "above" check, that there will be more. We can fix that.