> @RequiresAnyPermissions for SHIRO-175 since there's a fair bit of
> logic that would need to be duplicated. The AnnotationHandler
> hierarchy pretty much assumes that a specific type of handler deals
> with only one type of annotations.
Should this be rethought then? The single-annotation-per-handler was
just an implementation strategy - we could probably add new support if
there should be an additional solution.
For example, the Spring support module has a single method interceptor
that uses one or more AnnotationHandlers to support more than one
annotation per method.
> The simplest way to include OR
> logic would be to add a parameter to the annotations to indicate the
> logical type that should be used (e.g. Logical.AND or Logical.OR), AND
> probably being the default since that's how it's currently interpreted
> (though I think OR as a default might be more useful but then again,
> AND is the more secure default assumption). The drawback is that if
> you want OR logic, you'd always have to explicitly name the value
> parameter as well (e.g @RequiresRoles(value={"admin", "user"},
> logic=Logical.OR). Is that a reasonable price to pay?
I think to retain the current semantics (AND behavior) we would have
to do this. I think the logical type addition is a good idea - it
doesn't require us to add new annotations and the existing handlers
can be easily updated.
> One other thing is that currently the value parameter is defined as
> plain String rather a string array, forcing us to parse the String
> ourselves. I think that's just a mistake and I'll fix that as part of
> the issue.
Wouldn't this break backwards compatibility? But I do agree that
having the String array is a better approach.
>
> I already implemented extending all annotations to allow
> @Target(ElementType.TYPE) (but haven't committed) with accompanied
> tests.
+1
Looks good!
Les
