Re: RESTful support - feedback appreciated

[Tauren Mills <ta...@groovee.com>]

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 <lh...@apache.org> 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 <ta...@groovee.com> 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?
>

Re: RESTful support - feedback appreciated

[sh...@xoxy.net]

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 - tauren@groovee.com 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 <lh...@apache.org>
> 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 <ta...@groovee.com> 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?
> >
>
>