[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrp-wsia] Change request #138: Transferring UserContext toproxied resources
I would agree that this would be inappropriate as a MUST for two reasons:
1. Consumers aren't required to support cookies today. Part of the
extended discussion yesterday centered on whether an additional metadata
flag would be appropriate (e.g. ServiceDescription.UsesCookies). This
would clue a non-cookie supporting Consumer into whether or not End-Users
would likely receive expected results if Portlets from a Producer setting
this flag to true are aggregated into the Consumer's pages.
2. We have extended the Web model for cookies to extend to the SOAP
connection to the Producer. The contract for this is only best effort ...
we should not be changing that contract.
Rich Thompson
Andre Kramer <andre.kramer@eu.citrix.com>
03/14/2003 09:40 AM
To: wsrp-wsia <wsrp-wsia@lists.oasis-open.org>
cc:
Subject: RE: [wsrp-wsia] Change request #138: Transferring
UserContext to proxied resources
It's not just the singular / plural. It's also when cookies can be set. I
would agree that in practice one can set more than one cookie, and at any
time, but should one require these to all be always returned? Essentially,
from what may well be different Web clients (Soap stubs and
HttpURLConnection objects in different processes)? Normally, I would only
assume best effort on returning all cookies for safety (as cookies
optimize
Web applications) and I'm not convinced we need to depart from this just
for
http resources such as images.
regards,
Andre
-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: 14 March 2003 14:08
To: wsrp-wsia
Subject: RE: [wsrp-wsia] Change request #138: Transferring UserContext
to proxied resources
Hmm ... the language in both 5.1.18 and 6.4 does use cookie in the
singular, but how would one practically restrict the Producer from only
returning one cookie on the call to initCookie()? Perhaps as a corollary
this language should be updated to refer to "any cookies" (i.e.
acknowledge that a plurality is possible).
I think the only substantive change in this proposal is solidifying the
discussion of a couple weeks ago that drove toward a conclusion that
cookie domain and security settings should be respected and their
availability broadened from the portlet instance to include any referenced
resources.
I think this is a reasonable v1 solution (covers the 90+% of usage) though
it should be revisited for v2 in order to remove the dependence on HTTP as
the transport layer.
Rich Thompson
Andre Kramer <andre.kramer@eu.citrix.com>
03/14/2003 06:35 AM
To: wsrp-wsia <wsrp-wsia@lists.oasis-open.org>
cc:
Subject: RE: [wsrp-wsia] Change request #138: Transferring
UserContext to proxied resources
Well, previously, we focused on the one cookie (a J2EE or ASP session
identifier cookie). Multiple cookies (some with data values) transferred
between SOAP and Web clients is a different kettle of fish. Have we
thought
through the implications of having multiple (SOAP and Web) clients active
in
parallel, load balanced (serialized) and re-used for different portlets in
the same producer application session? (Remember portlets can demand
different sets of userCategories to be backed into cookies.) If the data
cookie is just the UserContext.userContextKey then effectively we have one
session (session as key into database) cookie...
regards,
Andre
-----Original Message-----
From: Michael Freedman [mailto:Michael.Freedman@oracle.com]
Sent: 14 March 2003 00:55
To: wsrp-wsia
Subject: [wsrp-wsia] Change request #138: Transferring UserContext to
proxied resources
This note is intended to both motivate the change request and to propose
a solution that the few who stayed after school on this mornings
conference call reached consensus on.
Motivation for this change request:
JSR 168 defines the concept of a portlet application. A portlet
application is a set of portlets [akin to our producer] + the set of web
resources accessed/rendered by the application during usage. These web
resources can be either static or dynamic. When dynamic they are
expected to be servlets or derived from them. I.e. web resources are
accessed via http.
JSR 168 requires that dynamic web resources running in the context of
the portlet application be presented with the same information as to who
the request user is and what roles this user has. JSR 168 permits
portals to provide this information to the portlet rather then requiring
it be established and maintained by the J2EE security system. I.e. JSR
168 sees as valid and useful the ability of the portal in conjunction
with the JSR 168 portlet container to use the WSRP UserContext to
satisfy the requirement of providing a uniform representation of the
user and its roles/categories to both the portlets and its web resources
in a portlet application.
The change request I opened observed WSRP didn't define sufficient
mechanism to ensure this UserContext could be passed when appropriate to
the proxied resource and suggested we address this. To date, there have
been 4 types of solutions offered:
a) rely on the producer to maintain this information in
[session] state. I.e. as JSR 168 assumes the web resource and portlet
run in the same session context then problem is solved if the JSR 168
container merely "caches" the needed information in its session. The
problem with this solution is its overly restrictive. It requires the
JSR container to be session based merely to satisfy the JSR requirement.
This essentially denies stateless portlets in a JSR 168 container with
the corresponding loss of load balanced scalability. Basiaclly, the
problem with this approach is one of completeness. Though it is a
correct technical solution it doesn't cover all our use case. Therefore
additional mechanism needs to be supplied to handle the non-session
case. The following three scenarios attempt to address this other
situation.
b) require the producer encode this information directly into
the proxy resource URL. The problem with this solution is that these
URLs ultimately get back to the client. There would likely be
significant privacy/security concerns with being able to see this
information in plain text in a client. Though encryption techniques
could be used you potentially run into URL length issues.
c) define a mechanism whereby the portlet/producer can request
the UserContext be sent to the proxy resource by encoding this desire in
the proxy resource URL. I.e. as the portal has the UserContext
information all we need to do is provide a token to the producer to
include in its proxy resource URL that indicates the information should
be added when the portal calls the proxied resource. Defining such a
mechanism requires we define a standard way this information be passed
to the resource. WSRP specific headers were suggested. Though this
solution satisfies the technical requirements we are trying to achieve
here, concern has been expressed that we shouldn't be defining standard
http usage in a web services environment.
This leads to the fourth option which the group who talked after the
meeting today reached consensus would be the best solution for version
1.0.
d) require the portlet/producer [that isn't using the session
solution mentioned in (a)] to encode the UserContext information in a
cookie. This cookie would be separate from any session cookie [if the
later exists]. In addition, to make this work, we would require that
those consumers dealing with cookies manage cookies for proxied
resources in the following manner: consumers would pass to the proxied
resources those cookies being maintained on behalf of the specific user
of the specific portlet where the proxied resource is in the specific
cookie's cookie domain.
Basically, the proposal for this change request is to NOT define any
specific behavior related to what/how portal/portlet UserContext
information is passed to proxied resources. Rather, we merely
extend/clarify the cookie support mechanism we already define to cover
proxied resources. And we will then rely on producers to leverage this
cookie mechanism [for the time being] to address its data transport
issues. As we discussed extending the cookie support mechanism pretty
thoroughly 2 weeks ago and at that time reached a point of consensus
that adding such support was okay my hope is we can close this change
request quickly. I.e. I propose we formally adopt extending the cookie
support semantics to cover proxy resources as discussed here and on the
call 2 weeks ago and then leave the UserContext data management as an
exercise for the producer/JSR 168 container developer.
-Mike-
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]