Kevin Duffey wrote:
> Hey all,
>
> I am curious if this discussion would include the ability to provide
> some sort of cross-cutting "aop" like ability to check the
> Authorization header. I haven't looked at all the latest threads, but
> one issue I am trying to figure out is how to avoid doing a method
> lookup for authorization based on the auth header, in every one of my
> API methods. Maybe Jersey supports some sort of web.xml configuration
> that allows me to specify a method to call with the Authorization
> info... so that I can remove the same lookup code I have in every one
> of my methods... or does this basically fit into the filter
> configuration discussion and thus is presently not possible?
>
Couldn't a servlet filter do this for you, since you're using a servlet
based webapp?
On the other hand, I can see how abstracting authentication could be
useful ... but an authorization check might still need a per-method call
anyway so that you know what operation you're trying to authorize.
Craig
>
> > Paul Sandoz wrote:
> >>
> >> On Oct 16, 2008, at 6:50 PM, Craig Iverson wrote:
> >>
> >>> First let me thank you for all the good work you guys are doing
> >>> with jersey and jsr-311. It's been a pleasure to develop against.
> >>
> >> Thanks!
> >>
> >>
> >>>
> >>> I have a feature request that I can add to the issue tracker if
> >>> you agree.
> >>
> >> Please. No need to ask permission to log issues :-)
> >>
> >>
> >>> I think it would be great to be able to configure a filter per
> >>> resource(s). In my case its even more than that, it would be
> >>> more beneficial to also support an exclude list. I have a case
> >>> where I only want certain filters applied to certain resources. I
> >>> really want a couple of filters to always be applied except for on
> >>> a couple of resources. The reason for the exclude list would
> >>> allow other team members to add resources without worrying about
> >>> configuring the filter for the new resource. Your thoughts?
> >>
> >> Currently request and response filters are called before resource
> >> matching is performed. Having filters apply to specific root
> >> resource classes could also make sense, but i wonder if the exclude
> >> list complicates matters, especially if there is more then one
> >> filter present in the filter chain, rather than being explicit and
> >> describing the list of resources with the list of filters e.g.
> >>
> >> Map<List<Class<??>, List<ContainerRequestFilter>>
> >>
> >> I am wondering if it is appropriate to have filters associated with
> >> resources and resource methods configured from the resources
> >> themselves. How about allowing the following:
> >>
> >> @RequestFilters({A.class, B.class})
> >> @Path("resource")
> >> public class Resource {
> >>
> >> @RequestFilters({C.class, D.class})
> >> @GET
> >> public String get() { ... }
> >>
> >> @RequestFilters({E.class, F.class})
> >> @Path("sub-resource")
> >> public Object getSubResource() { ... }
> >> }
> >>
> > Just as a comparison point, this is conceptually pretty similar to
> > how you can define interceptors on EJB session beans in the bean
> > classes themselves:
> >
> > @Stateless
> > // Class level interceptors around all method calls
> > @Interceptors({TracingInterceptor.class})
> > public class MySessionBean {
> >
> > // Method level interceptors around calls to this method
> > @Interceptors({SomeInterceptor.class, AnotherInterceptor.class})
> > public String result(String arg1, String arg2) {
> > ... business logic goes here ...
> > }
> >
> > }
> >
> > There are also some additional ideas in EJB interceptors that might
> > be worth emulating:
> >
> > * @ExcludeClassInterceptors and @ExcludeDefaultInterceptors
> > to turn off normal interceptors for a particular class or method.
> >
> > * @AroundInvoke to let you specify the logic of a class interceptor
> > inline in the same class, rather than requiring it to be separate.
> >
> > Of course, once you get into a world of multiple layers of
> > interceptors, the invocation order needs to be clearly defined as
> > well.
> >
> > Craig
> >
> >
> >> Paul.
> >>
> >>>
> >>> Craig
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> <mailto:users-unsubscribe_at_jersey.dev.java.net>
> >>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
> <mailto:users-help_at_jersey.dev.java.net>
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> <mailto:users-unsubscribe_at_jersey.dev.java.net>
> >> For additional commands, e-mail: users-help_at_jersey.dev.java.net
> <mailto:users-help_at_jersey.dev.java.net>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> <mailto:users-unsubscribe_at_jersey.dev.java.net>
> > For additional commands, e-mail: users-help_at_jersey.dev.java.net
> <mailto:users-help_at_jersey.dev.java.net>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> <mailto:users-unsubscribe_at_jersey.dev.java.net>
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
> <mailto:users-help_at_jersey.dev.java.net>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com