Re: [wsrp-interop] on initCookies and sessionID

[Rich Thompson <richt2@us.ibm.com>]

I would also encourage Consumers to
block all invocations targeting portlets within a particular group once
it is known that the cookies being passed to that group are invalid. Re-establishing
those cookies and then processing the blocked invocations with the new
cookie set makes for the cleanest set of calls (i.e. consistent state).

Rich

Michael Freedman <Michael.Freedman@oracle.com>

11/19/2003 02:57 PM

To
cc	wsrp-interop@lists.oasis-open.org
Subject	Re: [wsrp-interop] on initCookies and sessionID

This can only be done if templates [or other consumer
supplied state] 
isn't stored in the entity session.  Note: Currently we only have
the 
concept of storing this in the entity session not in relationship to a
cookie session.  If the producer needs to formally represent entity
sessions [because of needing to re-receive consumer supplied state] then
it should return the entity session key it is using within the http 
session to hold the entities state.  Often this will be the entity
ID 
itself [but need not be].  

In any case I don't understand how things get weird/out-of-sync in 
Alejandro's case as the systems should work anyway. [Though I would 
encourage you to review any producer code that gets you into this 
scenario as it sounds quite peculiar to have entity sessions dependent
on http sessions yet an inconsistent path through checking which is 
valid].  Anyway things should work on the consumer because all an
InvalidSession means to a consumer is toss the entity session [ID] and
recall me passing current/new consumer state [like templates]. Thus if
Portlet A from the producer returns invalidCookie while Portlet B 
returns invalidSession, the consumer will in response to Portlet A fire
off a new initCookie and in response to Portlet B resend the old the 
cookie with new template data/no entity session ID.  This later will
now 
throw an InvalidCookie as its not an entity session problem anymore. 
 When the consumer gets the second invalid cookie if the initCookie is
still in process the consumer waits for it to complete and then recalls
both Portlet A and Portlet B with the new cookie or if already completed
[and having called Portlet A again] merely recalls Portlet B with the 
new cookie.  Note: if the consuemr already has the new cookie from
Portlet A by the time it is ready to resend in response to Portlet B's
invalid session it is fine to send the nwe cookie at this point and 
avoid the second fault.
     -Mike-

Subbu Allamaraju wrote:

>
> Good point. It does simplify Alejandro's scenario for the Consumer.
>
> Subbu
>
> Rich Thompson said the following on 11/19/2003 11:58 AM:
>
>>
>> I would encourage the Producer in such a scenario to only use
the 
>> cookie and never return a sessionID. This eliminates duplicate
>> information that can cause all sorts of issues.
>>
>> Rich
>>
>>
>> *Alejandro Abdelnur <Alejandro.Abdelnur@Sun.COM>*
>> Sent by: Alejandro.Abdelnur@Sun.COM
>>
>> 11/19/2003 01:43 PM
>>
>>     
>> To
>>     wsrp-interop@lists.oasis-open.org
>> cc
>>     
>> Subject
>>     Re: [wsrp-interop] on initCookies and sessionID
>>
>>
>>     
>>
>>
>>
>>
>>
>> This was exactly the scenario we are facing. The problem is that
>> things  get weird (out of synch) if the consumer invokes
the producer 
>> in  parallel for 2+ portlets and one of the throws a cookie
or a 
>> session  fault.
>>
>> Alejandro
>>
>> On Wednesday, November 19, 2003, at 06:08  AM, 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.
>>
>>
>>
>
>
>
> 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.