I spoke too soon about my superclass solution... i had my app in mock mode
so it appeared to work. Back to the drawing board.
On Wed, Feb 24, 2010 at 9:51 PM, Trolly Rogers <trolly.s.rogers_at_gmail.com>wrote:
> Hi All - Hope I'm not being a pest. I just can't figure out how to handle
> some common logic needing to be applied to a common path param (at least the
> way I'd like to). I have a bunch of resources which all share a couple
> things I mentioned below. There's basically one root resource, and a number
> of sub-resources exposed via method and locator. Here's the two things they
> all have in common...
>
> 1. part of thier URIs. They all begin with /users/{id}. The id is not the
> user's user id exactly, but it is a unique way to identify the user and
> provides a great piece of scoping info keeping my URIs RESTful.
>
> 2. The {id} path param needs to be checked against the value of
> HttpServletRequest's getUserPrincipal().getName(). This name is set as part
> of our security infrastructure and ensure the {id} passed to my resource is
> in fact the right user.
>
> I thought I was on to something when I was workin' on my own
> ResourceFilterFactory impl. The thing I got hung up on was how to get the
> value of the resolved {id} path param, is this possible in a
> ContainerRequestFilter?
>
> The solution I have working now is basically having my resource classes sub
> class "UserIdAuthBasedResource" which provides a constructor forcing any sub
> classes to pass in the user id and HttpServletRequest for the common
> checking (#2). There's obvious disadvantages here (but it works), any
> suggestions?
>
> Thanks,
>
> Trolly
>