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.