[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wsrp-wsia] [change request #138] Transferring information toproxied resources
Rich Thompson wrote: > I think there are security and privacy reasons why we might not want to > send a portlet's set of cookies to a resource. We also should not depend > on cookies for transferring such information. I would argue against > predeciding what information might be useful to such a resource. I also I second your argument. Regards Subbu > > Andre Kramer <andre.kramer@eu.citrix.com> > 02/14/2003 04:17 AM > > To: "'Michael Freedman'" <Michael.Freedman@oracle.com>, > wsrp-wsia@lists.oasis-open.org > cc: > Subject: RE: [wsrp-wsia] [change request #138] Transferring > information to proxied resources > > > Mike, see comments below. Hope I understood all your questions. > > regards, > Andre > -----Original Message----- > From: Michael Freedman [mailto:Michael.Freedman@oracle.com] > Sent: 13 February 2003 19:58 > To: wsrp-wsia@lists.oasis-open.org > Subject: Re: [wsrp-wsia] [change request #138] Transferring information to > proxied resources > > There are a couple of problems with what you suggest: > a) cookies use isn't limited to session identification. Cookies are > also used to hold state rather then ids. > [Andre Kramer] The WS-I basic profile says that cookies must be opaque to > the consumer so they really are more likely ids if we conform. > > b) if you are suggesting that the producer only URL encode the > session when using a resourceURL then the solution suffers from not being > able to restablish a session that timeouts before the resource is > activated. Basically, J2EE doesn't prevent you from carrying the session > ID in both cookies and URLs -- it isn't designed that way -- rather its > designed to work using one method or the other consistently. > [Andre Kramer] Yes, resource URLs for timed out sessions would fail to > get the session data. We are back in the Web world. One can configure > session timeout to be something sensible? > > c) if you are suggesting the producer session encode via the URL vs. > cookies for all support then the solution suffers from not being able to > establish the ID in a load balanced environment. WSRP only provides such > support for cookies. > [Andre Kramer] No, hope I'm not. But one can session encode the *same* id > as carried in the JSESSIONID cookie. Note, this is not encodeURL from the > Servlet API, only something like it. > > As for your suggestion that the producer has access to the userContext and > Template data via the session I see a couple of problems: > a) first, I added this change request for those portlets that don't > use sessions [i.e. are stateless]. We shouldn't require a portlet use > sessions merely to attain access to this information as we don't in our > regular interactions. > [Andre Kramer] In my opinion, the case where there is no producer session > and the producer has not indicated templatesStoredInSession is outside of > our wsrp spec. Just normal Web URLs & resources. > > b) second, doesn't the "I store this information in session" pertain > to the portlet session not the producer/cookie session? I recall we > discussed at one point that a conequence of optimizing the producer so > that it used cookie session INSTEAD of portlet sessions is that such > information wouldn't be cached [in session]. Did we change the meaning of > this to mean either the portlet session or the cookie session? If not, > those producers coded run optimized in consumers wouldn't have access to > this information even if they used cookies/sessions. > [Andre Kramer] At the f2f, we added a invalidSession fault that allows a > http session based producer to require stached data be re-sent. [This was > missing even for Portlet sessions.] The commentary on invalidCookie also > asks a consumer to re-sent data so (hopefully sensible) consumers will not > get a double fault. > > -Mike- > > Andre Kramer wrote: > Do we really need to forward cookies from the consumer? The Servlet API > has > a method to encode the session identifier in URLs (note: other means for > tracking a session may be in place). Why not encode the JSESSIONID in the > resource URL? Implementations can then convert this value to a cookie and > forward the http request locally (producer side, with JSESSION cookie set, > sort of like a reverse Web proxy). > > [This encodes a random identifier in the URL and so does not leak > sensitive > information, if that was a concern.] > > We already have PortletDescription.userContextStoredInSession and > PortletDescription.templatesStoredInSession so a producer already has all > the machinery to: > > 1) reference a session from a resource URL > 2) inject the session ID into the load balancing > 3) make sure the session is provisioned with WSRP data > > Therefore I don't think we need add anything. > > Also, what about direct URL requests from the Web browser? Should they not > be able to reference the producer session data also? The above scheme > would > work for both Web user agent and consumer resource requests (and even > re-directs). > > regards, > Andre > > -----Original Message----- > From: Rich Thompson [mailto:richt2@us.ibm.com] > Sent: 12 February 2003 20:05 > To: wsrp-wsia@lists.oasis-open.org > Subject: Re: [wsrp-wsia] [change request #138] Transferring information > to proxied resources > > > I think we can just extend this one, basically a new section between 10.3 > and 10.4 with forward references from sections 10.2.1.1.4 and 10.2.2.7. > Something like "Using Resources". > > Rich Thompson > > > > > Michael Freedman <Michael.Freedman@oracle.com> > 02/12/2003 01:47 PM > > To: wsrp-wsia@lists.oasis-open.org > cc: > Subject: Re: [wsrp-wsia] [change request #138] Transferring > > information to proxied resources > > > I had already assumed that cookies had to be provided according to > cookie domain rules -- but yes its probably worth the clarification. > Also just remembered that in addition to this information we probably > need a way to transfer the rewrite templates to the resource as well so > it can generate new links that are proxied. Can you just make a note to > extend this item or should I open a new one? > -Mike- > > Rich Thompson wrote: > > > Document: Spec > Section: 10.3.3 > Page/Line: New section > Requested by: Mike Freedman > Old text: > New text: New section describing how userContext/Profile information is > passed to resources. > > Reasoning: Specification doesn't define how a portlet can transfer > userContext/Profile information to proxied resources. As I don't recall > ever discussing it I want to find out if it should be left as is -- i.e. > an exercise for the portlet developer or we should define special http > headers to carry this information. The problem with the former [current > model] is that this information will commonly be carried all the way back > > > > to the client and appear in plain text in the browser URL -- folks may > freak seeing their UserId of personal profile information in a browser > URL. If we define specific headers to carry this we not only make it > > easy > > for the portlet developer as they don't have to encode/decode URLs but > also achieve more safety as this information is only represented between > the consumer and the producer. Note: if we go this later route we will > probably want to add a boolean or two to the resourceURL > > consumer/producer > > mechanism so they can control whether this information needs to be past > > or > > not [optimization]. > > [RT] Good point on providing this type of guidance. There are significant > > > > security and privacy issues in having this information appear either in > the URL or headers. Another alternative would be to suggest using an > indirection in the URL which allows the resource to locate the > > information > > (likely an indication of the sessionID). This allows locating any > information the Portlet is willing to make available. Should we also > discuss whether cookies have to be connected back to the proxied resource > > > > the same as to the Portlet? > > ---------------------------------------------------------------- > 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] | [Elist Home]
Powered by eList eXpress LLC