wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp] initCookie perUser semantics
- From: Rich Thompson <richt2@us.ibm.com>
- To: OASIS WSRP TC <wsrp@lists.oasis-open.org>
- Date: Fri, 31 Mar 2006 14:38:32 -0500
I agree this is off topic.
I share many of your sentiments, but
don't think inventing another equivalent is the answer. I would advocate
improving user-agents such that the user has better control than simply
turning all cookies on or off. In other words, I am willing to accept cookies
from yahoo, my bank, etc but would prefer to reject them from ad sites
and sites visited once while doing research, etc. I would also like to
have the choice of restricting the domain rule if it appears to be broader
than my preference.
Rich
Rex Brooks <rexb@starbourne.com>
03/31/06 09:56 AM
|
To
| Rich Thompson/Watson/IBM@IBMUS, OASIS
WSRP TC <wsrp@lists.oasis-open.org>
|
cc
|
|
Subject
| Re: [wsrp] initCookie perUser semantics |
|
This is slightly off topic, so please excuse me.
As one of the resident Consumers in the TC, I have to point out that
the whole issue of Cookies puts me in a bad spot. As an end-user I
keep running into places where I have to re-enable cookies to get
things I need or want and each time it raises my blood pressure a
notch for a few minutes. I had hoped that by the time we got to v2.0
cookies would have been retired, but I was way wrong about that. I
also thought we would get to v2.0 last year, like the rest of us.
Clearly there are too many uses for a mechanism like cookies, but
when I find myself getting my back up over them, I have to expect
that I am hardly alone in the user community, so I find the necessity
burdensome. I understand the necessity for a mechanism, I just hate
that it is cookies, which I expect will only get worse as Ajax rolls
over us. What we have is a very low, lowest common denominator for
keeping track of end users in multi-step processes and we just keep
using cookies because they are convenient.
Perhaps some of your companies might take up the issue of finding
another mechanism, or founding a new TC to create a reliable,
asynchronous, short-term, non-transferable or reusable client id
mechanism or agent that is destroyed with its session. I, for one,
would be happy to then allow a form of cookie only for a clearly
prescribed, non-transferable, longer term client id mechanism usable
only with specific, secure (wss user token?) client permission. I
wish I could say that I believed clients would one day rise up and
kill cookies, but I've been wrong in too many expectations to really
believe that.
Now, as a consumer, I do need to point out that Consumers like rules,
not choices. I may not like a rule, but at least I can rely on it,
whereas a choice practically guarantees I will always choose the more
inconvenient choice and waste time and deliver the wrong thing to
both end user and producer.
Rex
At 7:33 AM -0500 3/31/06, Rich Thompson wrote:
>We already have the other semantics captured in AS023 & AS024.
This
>assertion could explicitly refer to them in the step 1 portion;
>perhaps using:
>
>"If the Consumer uses a Producer who has set requiresInitCookie
to a
>value other than "none", it shall: 1. Invoke initCookie
from such a
>Producer for each new end-user in accordance with AS023 and AS024
>2. Return the set cookie(s) only for this end-user
>(see AS006, AS023 and AS024)."
>
>This keeps the assertion focused on connecting the cookie back to a
>particular end-user and leaves the semantics of cross-portlet
>sharing of cookies entirely to the assertions focused on that issue.
>
>Rich
>
>Richard Jacob <richard.jacob@de.ibm.com>
>
>03/31/06 06:49 AM
>To
>Subbu Allamaraju <subbu@bea.com>
>cc
>OASIS WSRP TC <wsrp@lists.oasis-open.org>
>Subject
>Re: [wsrp] initCookie perUser semantics
>
>
>
>
>
>That's not correct.
>We need to consider the "perGroup" initCookie requirement.
>If the producer requires initCookie per group then the Consumer must
invoke
>initCookie() once per User/per Group.
>I think the statement "If the Consumer uses a Producer who has
set
>requiresInitCookie to a
>value other than "none", it shall:" is to generic and
needs to consider
>every requiresInitCookie flag setting.
>
>Mit freundlichen Gruessen / best regards,
>
> Richard Jacob
>______________________________________________________
>IBM Lab Boeblingen, Germany
>Dept.8288, WebSphere Portal Server Development
>WSRP Technical Lead
>WSRP Standardization
>Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
>Email: mailto:richard.jacob@de.ibm.com
>
>
>
> Subbu Allamaraju
> <subbu@bea.com>
>
To
> 03/30/06 07:17 PM
OASIS WSRP TC
>
<wsrp@lists.oasis-open.org>
>
cc
>
>
Subject
>
Re: [wsrp]
initCookie perUser
>
semantics
>
>
>
>
>
>
>
>
>
>
>I remember where I got my interpretation from. See AS007 in the
>conformance spreadsheet, which reads
>
>"If the Consumer uses a Producer who has set requiresInitCookie
to a
>value other than "none", it shall: 1. Invoke initCookie
for each
>portlet from such a Producer for each new end-user 2. Return
the set
>cookie(s) only for this end-user (see AS006, AS023 and AS024)."
>
>We need to fix the first item. I suggest the following:
>
>"If the Consumer uses a Producer who has set requiresInitCookie
to a
>value other than "none", it shall: 1. Invoke initCookie
from such a
>Producer for each new end-user 2. Return the set cookie(s) only
for
>this end-user (see AS006, AS023 and AS024)."
>
>Subbu
>
>Rich Thompson wrote:
>>
>> I think the primary reason this question tends to come up
is
>> implementations that are mapping the portlet session to
the http
>> session, which is also the key many clustering systems use
relative to
>> repetitive routing to a node within the cluster. The solution
which
>> gives per portlet per user is to use a cookieProtocol of
perGroup and
>> then put each portlet in its own group. The spec is pretty
clear that a
>> cookieProtocol of perUser means once for each user, independent
of the
>> number of portlets accessed.
>>
>> Rich
>>
>>
>> *Richard Jacob <richard.jacob@de.ibm.com>*
>>
>> 02/07/06 09:40 AM
>>
>>
>> To
>> Subbu Allamaraju <subbu@bea.com>
>> cc
>> OASIS WSRP TC <wsrp@lists.oasis-open.org>
>> Subject
>> Re: [wsrp] initCookie
perUser semantics
>>
>>
>>
>>
>>
>>
>>
>>
>> it's once per all portlets or per group if required by producer.
>> Also only per user if per user is really requested.
>> It's not once per portet (otherwise the groups session thingie
would not
>> work).
>>
>> Mit freundlichen Gruessen / best regards,
>>
>> Richard Jacob
>> ______________________________________________________
>> IBM Lab Boeblingen, Germany
>> Dept.8288, WebSphere Portal Server Development
>> WSRP Team Lead & Technical Lead
>> WSRP Standardization
>> Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
>> Email: mailto:richard.jacob@de.ibm.com
>>
>>
>>
>> Subbu Allamaraju
>
>> <subbu@bea.com>
>>
To
>> 02/06/06 11:48
PM OASIS WSRP TC
>>
<wsrp@lists.oasis-open.org>
>>
cc
>>
>>
Subject
>>
[wsrp]
initCookie perUser semantics
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Could someone clarify if the initCookie operation should
be called once
>> per user's session for each portlet on a producer, or once
for all
>> portlets on a producer?
>>
>> From earlier discussions, I vaguely recall that perUser
implies that
>> the initCookie should be called once per portlet per user's
session on
>> the consumer.
>>
>> Thanks
>>
>> Subbu
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
>> ---------------------------------------------------------------------
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
>
>
>
>
>---------------------------------------------------------------------
>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
--
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]