Hi Kevin,
The best approach is to allow filters to be associated with specific
resource classes, which i need to look into but don't currently have
the time. IMHO i think this is another reason to perhaps base the
Jersey implementation on an IoC framework like Guice, something i am
giving very serious consideration to doing. The main concerns over
this are:
1) It may not support all we require and we may not be able to
influence to get the support we require;
2) Not clear how integration works with other IoC frameworks; and
3) Increases the dependencies and size.
2 & 3 are probably minor issues, it is 1 that concerns me most.
@*Param will not work for provider classes (essentially singletons)
you have to use UriInfo/Request/HttpRequestContext etc which does not
perform the typing.
You can match the request URI path against any template you want by
using the com.sun.jersey.api.uri.UriTemplate class and use the match
method to extract path parameters. This does of course mean duplicate
path matching which may be more preferable over duplication of
authentication checking.
Hope that helps,
Paul.
On Nov 21, 2008, at 7:40 AM, Kevin Duffey wrote:
> Hi all,
>
> I hope I am not duplicating a post from earlier.. looked back a bit
> and can't find much on filters and nothing that I read seems to
> satisfy my issue at hand.
>
> I have implemented ContainerRequestFilter, and want to use this to
> authenticate all calls. I am curious if @PathParam, @HeaderParam,
> and such work still. I can't seem to find any good info on whether
> or not the annotations work with these interfaces or only after
> they've passed the request on. For the most part I believe I can use
> this filter to authenticate all requests. I do have an issue tho
> where the specific url path provides a user id that I must use to
> match against the authentication credentials. In my Resource classes
> I have something like @Path("/users") and a sub-resource method in
> that class with @Path("{userid}/anotherpath")... and the subresource
> uses the @PathParam to get the userid. Presently, I actually
> authenticate in every single method call.. and in this particular
> case I need that passed in userid on the URI path to match against
> the Authorization header credentials. I am wondering if there is any
> way to pull this info out inside the filter without having to
> dissect the path URI myself?
>
> Worse case scenario I would just do a sort of double
> authentication.. where the filter confirms that Authorization header
> credentials is valid.. then in the specific sub-resource method, get
> the path param and and do that check there.
>
> Thanks.
>
>
>