Marc, I'll get this out to the group early next week.
Ryan-
On 9/10/07, Marc Hadley <Marc.Hadley_at_sun.com> wrote:
>
> On Sep 10, 2007, at 3:15 PM, Ryan McDonough wrote:
>
> > 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?
> >
> Yes, that would definitely be helpful, thanks.
>
> Marc.
>
> >
> > 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
>
> ---
> 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