Re: [wsrp-interop] on initCookies and sessionID

[Alejandro Abdelnur <Alejandro.Abdelnur@Sun.COM>]

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.
>