Hi Casper,
I think approach 2) is the right one for what you require i.e. use a
resource filter as it avoids duplication of the URIs.
A web application-wide auth filter and a resource filter would both be
useful for developers. The best way to contribute is to create an
issue and attach code (preferably with tests) as a patch. Please do :-)
In case you do not know how to implement resource filters see the code
for:
com.sun.jersey.api.container.filters.
RolesAllowedResourceFilterFactory
Paul.
On Mar 30, 2009, at 10:45 PM, Casper Bang wrote:
> Hello list,
>
> I have implemented a SecurityFilter and have HTTP Basic
> Authentication working fine with Jersey thanks to some earlier
> feedback I got. It now turns out some of my top-level resources
> (incl. an xhtml login page) should not be guarded by authentication.
> Two ideas occured as to how to proceed:
>
> 1) Extend the SecurityFilter to use some property specifying what
> does not need authentication (a la
> com.sun.jersey.config.property.WebPageContentRegex) or...
>
> 2) Extend Jersey with a few more annotations, i.e.
> @Authentication(Authentication.Basic) and @AuthenticationParam, very
> much in spirit with Jersey's existing design.
>
> I like the latter approach best (no fan of magic properties). How
> would I go about doing this, particular the actual injection of the
> @AuthenticationParam (which is readily available through the
> RequestHeader)? Would this be interesting as an extension to Jersey
> itself as a patch? Otherwise it might be less pretty but faster for
> me to simply grab the RequestHeader manually in a pre-condition check.
>
> Regards,
> Casper