Section 4.4 of the JAX-RS specification defines an ExceptionMapper interface that appears to do what you want: http://jsr311.java.net/nonav/releases/1.1/spec/spec3.html#x3-510004.4 <http://jsr311.java.net/nonav/releases/1.1/spec/spec3.html#x3-510004.4>
On Tue, May 24, 2011 at 2:00 PM, Tauren Mills - [email protected] wrote: > Les, > > Sorry for the late reply... I guess my thoughts on integrating with > REST were more related to dealing with and customizing error > conditions. For instance: > > @GET > @Path("process") > @RequiresPermissions("payments:process") > public Response processPayments() { > billingService.processPendingFuturePayments(); > return Response.ok().build(); > } > > If a user without "payments:process" permissions hits this REST > endpoint, they will get back a 500 error with a plain text stack trace > and such. I would like to be able to respond instead with a 401 and a > JSON object that describes the error condition in a way that a client > can process it. > > What I've been doing instead is moving the Shiro annotation to my > service methods instead. Then I can catch the exception inside my > jersey resource method and respond appropriately: > > @GET > @Path("process") > public Response processPayments() { > try { > // this service method has shiro annotation > billingService.processPendingFuturePayments(); > return Response.ok().build(); > } catch (UnauthorizedException e) { > return Response.status(Response.Status.UNAUTHORIZED) > .build(); > } > } > > This seems kind of messy to me. I'm sure there is a better solution, > but I haven't taken the time to find it. I thought perhaps your REST > efforts might address this, but maybe it is out of scope. There may > even be some Jersey feature I could use to solve this. > > This does bring up another question -- should the REST resource or the > service method be secured with a shiro annotation? If my service > methods may be called from somewhere other than the jersey resource, I > should secure them. But what if my jersey resource does something else > (not that they do)? It seems strange to not secure it as well. But > this means that the shiro authorization code would run twice for rest > calls. Any thoughts? > > Tauren > > > On Tue, Apr 5, 2011 at 9:34 AM, Les Hazlewood <[email protected]> > wrote: > > Hi Tauren, > > > > I'm not sure Shiro would need to integrate with Jersey or other JAX-RS > > framework: they're annotation-based, so if you define Shiro > > annotations on the same methods that are JAX-RS-annotated, you'd have > > a Shiro-secured REST endpoint. Unless I'm missing something? > > > > There is also the out-of-the-box HttpMethodPermissionFilter (aka the > > 'rest' filter) that can secure URL endpoints for REST apps even if > > you're not using a REST framework like Jersey. > > > > Is there anything else necessary? > > > > Les > > > > On Mon, Apr 4, 2011 at 9:25 PM, Tauren Mills <[email protected]> wrote: > >> Les, > >> I think it's great you are working on REST support. Is your work going > to > >> integrate with REST frameworks such as Jersey? > > > >
