It's a tough one, but I find myself being drawn toward option (i) as a
SecurityContext (or AuthorizatonInfo,SecurityInfo?) would be tightly focused
on authorization information in the same manner as UriInfo and HttpHeaders.
It's keeps things consistent with the patterns that are already in place. My
concern with a unified injectable is that it could grow unwieldy in future
iterations of the spec. So cast my vote for option (i). Marc, would it be
helpful to write up the interface and docs for this?
Ryan-
On 9/10/07, Marc Hadley <Marc.Hadley_at_sun.com> wrote:
>
> On Sep 7, 2007, at 4:37 PM, Ryan McDonough wrote:
> >
> > I can certainly see the point whereby injecting container resources
> > can be a
> > problem for cases where you may not be using a servlet container. I
> > think
> > there is still value in being able to inject container specific
> > interface
> > into resources for the instances where you may want that
> > functionality. In
> > this case however, I think that adding some principal and role
> > information
> > to the UriInfo interface maybe a better approach as it will provide
> > some
> > consistency. So we could have:
> >
> > class PeopleResource {
> >
> > @HttpContext UriInfo uriInfo;
> >
> > @UriTemplate("{id}")
> > PersonResource getPerson(@UriParam("id) String id) {
> > if ( uriInfo.isUserInRole("paidSubscriber")) {
> > return PaidPersonResource(id);
> > } else {
> > return CheapSkatePersonResource(id);
> > }
> > }
> > }
> >
> > This at least provides some level of consistency regardless of
> > whether or
> > not you are running a servlet container.
>
> Having thought about it some more I think I agree with you. I'm not
> sure that adding those methods (isUserInRole, etc) to UriInfo is the
> best approach though since that interface is pretty tightly focussed
> on providing information about the request URI.
>
> Currently we've defined three injectable resources: UriInfo,
> HttpHeaders and PreconditionEvaluator. I think we have a couple of
> choices if we add security context to the mix:
>
> (i) Define a new SecurityContext (I'd be open to other names)
> interface that can be injected just like the others listed above.
> (ii) Provide some kind of unified injectable that provides access to
> UriInfo, HttpHeaders etc and includes the additional methods.
>
> Option (i) is the path of least disruption since its purely additive
> and it follows the current pattern of having discreet interfaces for
> logically separate data. Option (ii) offers the possibility of
> unifying request information into a single access point and provides
> a place to put additional methods that either don't fit anywhere else
> or don't deserve their own dedicated interface.
>
> Opinions ?
> Marc.
>
> ---
> Marc Hadley <marc.hadley at sun.com>
> CTO Office, Sun Microsystems.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
>
--
Ryan J. McDonough
http://www.damnhandy.com