users@jersey.java.net

Re: [Jersey] ResourceFilter best practices: Exception mapping, setting custom security context and passing auth context

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Wed, 30 Dec 2009 10:45:03 +0100

On Dec 28, 2009, at 4:03 AM, Mahesh Venkat wrote:

> Hi,
>
> I am trying to define best practices for using Resourcefilters in
> areas like exceptions, setting custom security context and passing
> authorization context.
>
> Here is sample code:
>
> a) Exceptions: Should we throw exception in Resourcefilters or
> capture them as Error entities and set them in CointainerResponse or
> HttpContext.
> I wrote a ResourceFilter to handle oauth validation and throw an
> exception for invalid credentials. I am observing that the
> exceptions thrown in the resourcefilter aren't mapped to any
> exceptions in the ExceptionMapper. Here is my code snippet:
>

It is necessary to throw an exception to break the request filter
chain and return a response mapped from the exception. The same
exception mapping rules apply if the exception was thrown from a
resource method.

For a full description of filter behavior see here:

   https://jersey.dev.java.net/nonav/apidocs/latest/jersey/com/sun/jersey/api/container/filter/package-summary.html



> /* -------------override methods of ResourceFilter
> ---------------------------------*/
> @Override
> public ContainerRequestFilter getRequestFilter() {
>
> try
> {
> context = RestInterceptor.restAuthContext
> (httpRequest, httpResponse);
> usrContext = context.getUserContext();
> if (usrContext == null){
> logger.log(Level.INFO,
> "ResourceFilterFactory : RestFilter : getRequestFilter: UserContext
> is NULL ");
> throw new MappableContainerException(new
> InvalidCredentialException(" Invalid User Context or Session "));
> }
> } catch (Exception exc) {
>
> throw new MappableContainerException (new
> InvalidCredentialException(" Unable to retrieve User Context "));
> }
> logger.log(Level.INFO, "ResourceFilterFactory :
> RestFilter : getRequestFilter : set Yodlee UserContext as a http
> request attribute");
> httpRequest.setAttribute(CommonDefs.USER_CONTEXT,
> usrContext);
> httpRequest.setAttribute(CommonDefs.CONTEXT, context);
> logger.log(Level.INFO, "ResourceFilterFactory :
> RestFilter : getRequestFilter : set RestSecurityContext in
> ContainerRequest ");
> containerRequest.setSecurityContext(new
> RestSecurityContext(usrContext));
> return this;
> }
>
> b) For positive cases: if we set custom securitycontext in the
> ContainerRequest or HttpContext is it available in the resource
> methods when referred to by @Context SecurityContext?

Yes. See:

   https://jersey.dev.java.net/nonav/apidocs/latest/jersey/com/sun/jersey/spi/container/ContainerRequest.html

And, also see the AtomPub contacts server sample:

   http://download.java.net/maven/2/com/sun/jersey/samples/atompub-contacts-server/1.1.4.1/atompub-contacts-server-1.1.4.1-project.zip


> I would like to retrieve the custom securitycontext in a resource
> method. From the custom securitycontext I want to extract the
> authorization context set in a custom Principal object.
>
> Alternatively:
> c) pass a validated authorization context as attributes in
> HttpServletContext or use setParameters?
>

IMHO reusing SecurtyContext is a good solution. If you want to get
direct access to the Principle (or a sub-class of) you could implement
your own injection provider to extract it out of the SecurtyContext.

Paul.