OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-wsia message

[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


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 
would not want to design for v1 how a Portlet could specify to the 
Consumer the various pieces of information that should be transferred in 
any of several techniques. I would prefer giving guidance for how 
cooperating portlets/resources can transfer how to connect to the 
information at the Portlet (logically a URI) via a URL parameter.

Rich Thompson




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>
 




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC