RE: [wsrp-wsia] [change request #138] Transferring information toproxied resources

[Andre Kramer <andre.kramer@eu.citrix.com>]

My reply attempt bounced so I'm re-sending:

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: Michael Freedman [mailto:Michael.Freedman@oracle.com]
Sent: 12 February 2003 18:48
To: wsrp-wsia@lists.oasis-open.org
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>