Re: [wsrp-interop] on initCookies and sessionID

[Michael Freedman <Michael.Freedman@oracle.com>]

I think the confusion here is that "entity session" isn't an 
implementation specific term.  In reality WSRP only defines one type of 
session.  This is an "entity session".  I.e. a session [ID] scoped to a 
particular entity for a particular user [session].  Because we define 
cookie support, a feasible alternative mechanism is available to the 
producer developer for maintaining server state -- namely the http 
session.  If a producer chooses to use the http session to maintain 
entity/producer state that is fine but it is [generally] unrelated to 
the "entity session".  Where a relationship may exist is in those 
implementations that represent "entity sessions" as keys within the http 
session state system.  If these keys are not the entity ID themselves 
then the producer must return these keys as the entity session ID.  If 
the producer can compute the entity session key [e.g. its the entity ID] 
it should not return any entity session ID [if there is no consumer 
information that is stored at the entity session level -- e.g. 
templates] otherwise it should return the actual entity session id/key. 
 Returning the cookie ID is silly because it never represents the 
"entity session" -- at best it can represent the bucket within which the 
entity session is represented.  Producers should be encouraged to return 
the real entity session ID as that's the intent of the spec.
      -Mike-

Subbu Allamaraju wrote:

>
> Comments inline.
>
> Regards,
>
> Subbu
>
> Michael Freedman said the following on 11/19/2003 11:50 AM:
>
>> I have a slightly different view/expansion to Rich's reply:
>> Q1. Is there any required relationship between the cookies returned 
>> by initCookie and the sessionID returned by the markup interface calls?
>> A1. No, however it is common for producers that utilize both cookies 
>> and entity sessions to maintain their entity sessions within the 
>> cookie [http session].  I.e. the entity session is a child of the 
>> http session. This relationship, if it exists is unknown to the 
>> consumer. [Note: In Rich's response he refers to perUser 
>> initCookies... I find this confusing -- from my point of view it 
>> doesn't matter whether the initCookie is perUser or perGroup just 
>> whether there is a cookie or not].
>
>
> It seems you're referring to some implementation specific term 
> ("entity session") here. But I agree, that it is one of the possible 
> implementations.
>
>> Q2. If a call returns an InvalidCookie fault, should the consumer 
>> discard the sessionID?
>> A1.  It need not but it may.  A consumer can discard cookies or 
>> entity sessions whenever it feels it needs to do so.  Obviously we 
>> discourage consumers from doing so as state is lost and this may 
>> impact the presentation to the end user.  Time will tell but my 
>> intuition is that most producers that use both cookies and entity 
>> sessions will do so as I described above i.e. having a parent/child 
>> relationship between the two [think JSR 168].  Thus I feel its 
>> reasonable for the consumer to choose 
>
>
> Again this seems implementation specific.
>
>> to discard the entity sessions when the cookie becomes invalid, 
>> particularly in the end case described by Rich where the new entity 
>> session can't be created on demand but rather an InvalidSession fault 
>> has to be returned.
>>
>> Q3. If a call returns an InvalidSession fault, should the consumer 
>> call initCookie again?
>> A3. Definitely not.  Enfitity sessions are finer scope than cookies.
>>
>> As for Subbu's reply.  Yes, its feasible for an entity to use the 
>> cookie id to represent all entity session ids however this is very 
>> peculiar and not something we should encourage.  We shouldn't 
>> encourage it because the ID doesn't really represent the entity 
>> session.  More likely the 
>
>
> Why not encourage or discourage such an implementation? The session ID 
> pertains to (in some implementation specific manner) a session 
> maintained by the producer.
>
>> entity ID itself is the real "entity session" in this case as its 
>> likely the key off of the shared session to get to the per entity 
>> state.  It would be better if such a producer never returned an 
>> entity session.  In any case, even if a producer is silly enough to 
>> do as Subbu suggests, 
>
>
> I wound not call such an implementation "silly". We're not judging 
> implementation choices here.
>
> IMO, it is fair to implement session handling in the way Alejandro 
> described. There is some fuzziness in the spec when it comes to 
> cookies and sessions.
>
>> the consumer still does the right thing -- i.e. works as described 
>> above/in Rich's note.  I.e. if the consumer doesn't discard entity 
>> sessions when the cookie is reinited then it must be prepare to 
>> receive either an InvalidSession fault [for the end case described by 
>> Rich where you need access to the templates] or a new session id 
>> [i.e. the new cookie id returned returned as the new entity session id].
>>          -Mike-
>>
>>
>>
>> Subbu Allamaraju wrote:
>>
>>>
>>> I would like to note that a Producer requring perUser init cookies 
>>> may choose to use the same cookie for both cases (ie return a 
>>> session cookie in response to an initCookie call, and return the 
>>> same session ID in the pbia response).
>>>
>>> In this case, my interpretation is that
>>>
>>> (a) Producer returns InvalidCookie fault when the cookie from the 
>>> request (when HTTP binding is used) is no longer valid.
>>>
>>> (b) Poducer never returns InvalidSession fault (since this has the 
>>> same affect, atleast for the Producer), and reinvoking initCookie() 
>>> and resupplying data stored in sessions lets the Producer/portlet 
>>> recover from session loss.
>>>
>>> For the consumer,
>>>
>>> (a) If the Consumer is strict about cookies, it does not send 
>>> expired cookies to the Producer. So, after the cookie times out, it 
>>> automatically invokes initCookie().
>>>
>>> (b) If the Consumer is not strict, it may send an expired cookie to 
>>> the Producer. The producer then returns InvalidCookie fault.
>>>
>>> Subbu
>>>
>>>
>>> Rich Thompson said the following on 11/19/2003 05:52 AM:
>>>
>>>>
>>>> My take on the answers:
>>>>
>>>> First, overall comments: Private sessions between the end-user and 
>>>> particular instances of a portlet are modeled in the protocol via 
>>>> sessionID. It was also recognized that various systems have reasons 
>>>> to use a cookie to carry session information, though these types of 
>>>> sessions are not always unique to a portlet instance. As a result, 
>>>> these two tend to closely parallel each other while never being 
>>>> linked.
>>>>
>>>> Q1. Is there any required relationship between the cookies returned 
>>>> by initCookie and the sessionID returned by the markup interface 
>>>> calls?
>>>> A1. No, though if the CookieProtocol is perUser then they do carry 
>>>> the same semantics.
>>>>
>>>> Q2. If a call returns an InvalidCookie fault, should the consumer 
>>>> discard the sessionID?
>>>> A2. No, the cookies are independent of the private sessionID and 
>>>> are not necessarily related to a session at all.
>>>>
>>>> Q3. If a call returns an InvalidSession fault, should the consumer 
>>>> call initCookie again?
>>>> A3. same as A2.
>>>>
>>>> Sorry if the fault descriptions are confusing:
>>>>  - InvalidSession fault is used only when the private session has 
>>>> timed out and required data had been cached in the session 
>>>> (templates or UserContext). If the session did not contain such 
>>>> data or it is also available via the supplied data on the 
>>>> invocation, the Producer can simply create a new session and 
>>>> include it in the returned data structure for future invocations 
>>>> from the Consumer.
>>>>  - InvalidCookie fault is used only when the cookies established by 
>>>> initCookie become invalid. This signals to the Consumer the need to 
>>>> invoke initCookie again. Since some Producers will establish a 
>>>> session related to these cookies, it would be wise for the Consumer 
>>>> to resend templates and UserContext when reinvoking the operation 
>>>> that caused the InvalidCookie fault as this can avoid the next 
>>>> invocation returning an InvalidSession fault.
>>>>
>>>> Rich
>>>>
>>>>
>>>> *Alejandro Abdelnur <Alejandro.Abdelnur@Sun.COM>*
>>>> Sent by: Alejandro.Abdelnur@Sun.COM
>>>>
>>>> 11/18/2003 07:02 PM
>>>>
>>>>     To
>>>>     wsrp-interop@lists.oasis-open.org
>>>> cc
>>>>     Subject
>>>>     [wsrp-interop] on initCookies and sessionID
>>>>
>>>>
>>>>   
>>>>
>>>>
>>>>
>>>>
>>>> One of the engineers in my group (punished with implementing WSRP) 
>>>> came
>>>> to me with the following questions and I could not find an answer for
>>>> her. I would like to know what is your opinion on this and how are you
>>>> handling this scenario.
>>>>
>>>> Thanks
>>>>
>>>> Alejandro
>>>>
>>>> * Producer requires initCookie.
>>>> * Consumer uses more than one portlet from the producer for
>>>>   the portal page of a user.
>>>> * initCookie has been called upfront.
>>>> * performBlockingInteraction and/or getMarkup have returned a 
>>>> sessionID
>>>>
>>>> Q1. Is there any required relationship between the cookies returned by
>>>> initCookie and the sessionID returned by the markup interface calls?
>>>>
>>>> Q2. If a call returns an InvalidCookie fault, should the consumer
>>>> discard the sessionID?
>>>>
>>>> Q3. If a call returns an InvalidSession fault, should the consumer 
>>>> call
>>>> initCookie again?
>>>>
>>>> If the answer is 'no' to all the questions, then the following 
>>>> sections
>>>> of the spec make things more confusing:
>>>>
>>>> P27/L27 "If the Producer returns an InvalidSession fault message after
>>>> returning a sessionID, the Consumer MUST NOT resupply that 
>>>> sessionID on
>>>> a subsequent invocation and SHOULD reinvoke the operation that caused
>>>> the fault message without any sessionID and supply any data that may
>>>> have been stored in the session."
>>>>
>>>> P44/L6 "If at any time the Producer throws a fault message
>>>> (“InvalidCookie”) indicating the supplied cookies have been 
>>>> invalidated
>>>> at the Producer, then the Consumer MUST again invoke initCookie() and
>>>> SHOULD reprocess the invocation that caused the fault message to be
>>>> thrown and include any data that may have been stored in a session
>>>> related to a cookie"
>>>>
>>>> P77/Table,Row=InvalidCookie "InvalidCookie Used only when the
>>>> environment at the Producer has timed out AND the Producer needs the
>>>> Consumer to invoke initCookie() again and resend data that may have
>>>> been stored in sessions related to a cookie."
>>>>
>>>> P77/Table,Row=InvalidSession "Used only when a Producer session has
>>>> timed out AND the Producer needs the Consumer to invoke resend data
>>>> that may have been cached in the session."
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> To unsubscribe from this mailing list (and be removed from the 
>>> roster of the OASIS TC), go to 
>>> http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/leave_workgroup.php. 
>>>
>>>
>>
>>
>>
>> To unsubscribe from this mailing list (and be removed from the roster 
>> of the OASIS TC), go to 
>> http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/leave_workgroup.php. 
>>
>>
>
>