Re: [wsrp] userContext usage across all ports/operations

[Atul Batra <atul.batra@Sun.COM>]

Thanks for bringing up approach/possibility (c). I should have
included that.

A related question here - so when looking at (c), would we not
consider clonePortlet() in that bucket as well? Since it is the explicit
cousin of the implicit clone in pbia() and now handleEvent(), it may
make sense to include since presumably the Consumer may call
this operation upfront triggered via a user action, instead of going
the implicit route. (then some may well argue that why leave behind
copyPortlet(), and so on and so forth). Perhaps, something to
discuss.

Atul

Subbu Allamaraju wrote:

> This is a good catch, and it is definitely worth reviewing this before 
> V2 is finalized.
>
> Strictly speaking, only those operations that personalize the user 
> experience ought to have userContext, which IMO, are getMarkup, pbia, 
> and handleEvents.
>
> Subbu
>
> Atul Batra wrote:
>
>>
>>
>> In reviewing the new v2 operations (draft 11), I noticed that
>> we may have some inconsistency in terms of some operations
>> including userContext as part of their arguments, and some not.
>>
>> Just as an example
>>
>> - register() does not include, but setRegistrationLifetime() does
>> - destroyPortlets() does not include, but clonePortlet() does
>> - getPortletLifetime() does not include, but setPortletLifetime() does
>> - etc
>>
>> The key point here is that userContext is being included in
>> operations beyond those that pertain to only end-user triggered
>> invocations, and so, they should be done so in a uniform
>> manner.
>>
>> I think we've had this inconsistency even in v1, and that the scope
>> becomes broader with the added operations in v2.
>>
>> I recall that we have broadly revisited the rational behind having
>> userContext itself in the post-v1 timeframe, so perhaps it's time to
>> review once more before we send v2 out.
>>
>> In terms of potential approaches, I can think of two at the moment
>>
>> a) we completely remove userContext from all operations. I'm
>> listing this for the sake of completeness and realize that this is
>> probably not doable/appropriate at this point.
>>
>> b) we consider adding userContext to almost ("almost" since,
>> for example, it may not make sense for initCookie() to have this,
>> or perhaps it does and this would map/default to an "admin" user
>> for implementations?) all  the operations for the sake of consistency.
>>
>> We have discussed  prior that true "identity propagation"
>> will take place outside the umbrella of WSRP (for example, via
>> the WS-Security Usernametoken profile 1.0 standard, etc), but
>> that there may be implementations that may rely on the userContext
>> mechanism to differentiate invocations from different end-users.
>> Particularly, for operations in the markup port. Additionally, some
>> Producer implementations may even use this facility to track for
>> audit trails, etc (hence consistency may be even more important).
>>
>> (note that although I am calling out userContext on the whole,
>> this boils down to userContextKey; userCategories are more
>> relevant to the markup oriented operations).
>>
>> Comments?
>>
>> Regards,
>>
>> Atul
>>
>>
>>  
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  You may a link to this group and all your TCs 
>> in OASIS
>> at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in 
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php