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 <>
Sent by:
11/19/2003 01:43 PM
To
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 <>*
>> Sent by:
>> 11/18/2003 07:02 PM
>>
>> To
>>
>> 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.
