Yes, a servlet filter could... I was thinking more along the lines of some sort of annotation that you can pass the Authorization header to and the method being invoked along with the authorization header could be passed in, allowing a single method to control whether or not the user is authorized to make a request to the requested method. Not sure where to draw the line tho... when does this start becoming annotation hell and no longer convenient.
________________________________
From: Craig McClanahan <Craig.McClanahan_at_Sun.COM>
To: users_at_jersey.dev.java.net
Sent: Monday, October 20, 2008 1:49:18 PM
Subject: Re: [Jersey] Filter configuration feature
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
For additional commands, e-mail: 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