[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
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]