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.