>
> Yes, for 1.0.1 I only suggested adding ElementType.Type for @Target,
> that should be perfectly backwards compatible right?
If we add that in 1.0.1, and they rely on the behavior that it triggers and
then downgrade to 1.0.0, then their software could break because that
behavior won't be enabled, right?
> > about adding expression support to annotations using a proper grammar.
> > Something like:
> > @SecurityCheck("perm(user:read:{0}.id) && (role[admin] ||
> role[developer])")
> > public void someSecureMethod(User user) { ... }
> > where {0} represents the first method argument, {1} the second, etc.
>
> I have to say the syntax looks super ugly :P.
Haha, I definitely don't have any preferences on syntax - anything that
makes sense/looks good would be nice :)
> It's easy to extend Shiro and it might be better
> to see first what users come up with.
>
Sure - this isn't a high priority at the moment. We'll see if anyone wants
to take a crack at this.
>
> > As for the existing annotations, I believe they're both supposed to be
> > aggregating - i.e. 'ALL' for both of them. My personal preference is
> that
> > we keep the existing annotations and have retain 'ALL' semantics.
> > @RequiresRoles(new String[] { "dev", "teamLead"}) to me definitely reads
> as
> > I should have both the 'dev' and 'teamLead' roles in order for the method
> to
> > execute. @RequiresAnyRoles (again, to me) sounds like a good alternative
> > for 'OR' semantics.
>
> Agree. Javadoc for @RequiresRoles says "Requires the currently
> executing Subject to have one or more specified roles" so at least I
> could read it as "any of these roles". Maybe best to rewrite it as
> "Requires the currently executing Subject to have all of the specified
> roles" and be done with it. We can then keep the existing annotations
> for ALL semantics and introduce @RequiresAnyXXX in 1.1.
>
+1 Sounds good to me!
Les
