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] | [List Home]


Subject: RE: [wsrp-wsia] Minutes for 06 March 2003 Meeting


What if the user bookmarks the resource URL? Must the consumer do an
initCookie() first and fake some call to store a UserContext in the (new)
JSESSSION? And we did not yet say cookies have to be shared both ways (SOAP
<--> http GET/POST). What if the consumer sends different UserContexts for
two portlets sharing the http session? I think such interplay with our WSRP
context does mean we need to (if we don't fix it now) re-visit this post
1.0.

For now, I would make resource URLs work the same way as URLs that come
direct from the Web user agent (don't rely on cookies; encode the session id
in URLs; and hope you can get at all the Web Application / J2EE / Portlet /
WSRP data). Post 1.0 (taking Rich's advice on 1.0), I see a
getPortletResource operation as a *contract* for this functionality.

regards,
Andre

-----Original Message-----
From: Subbu Allamaraju [mailto:subbu@bea.com]
Sent: 13 March 2003 13:51
To: Michael Freedman
Cc: wsrp-wsia@lists.oasis-open.org
Subject: Re: [wsrp-wsia] Minutes for 06 March 2003 Meeting


Michael Freedman wrote:
> JSR 168 requires that resources running in the same portlet application 
> have access to the portlet application's session and user identity and 
> "role" information.
> 
> For sessions, it is anticipated that the JSession cookie will commonly 
> be used by JSR 168 applications to maintain the session.   It is 
> reasonable to assume that resources, which commonly will have additional 
> references back to the application will want to assume such cookie 
> support is maintained.
> 
> For user information, at the last JSR 168 F2F we discussed how this user 
> identity and "role" information can be provided by the portal vs. the 
> underlying J2EE security system implying that there be an ability to 
> send such information [basically the UserContext] to the portlet 
> applications resources.

As we discussed during the F2F, one of the implementation possibilities 
is to map the contextId/categories to J2EE security  identity/roles. But 
I'm not sure if this places extra requirements on WSRP.

If the resources exist on the producer domain, the current cookie 
support in WSRP would be enough to obtain the resource within the same 
J2EE session (since the web container would recognize the cookie and let 
the consumer join the same user session), and user identity. Once the 
web/J2EE container authenticates a user, it should be able to associate 
the session with the authenticated identity on all subsequent requests 
for the same session. Hence there is no need to send user context ID and 
roles for resource requests.

So, it is not clear to me why a JSR168 producer would require additional 
protocol support?

Regards,

Subbu

> 
>     -Mike-
> 
> Subbu Allamaraju wrote:
> 
>> Michael Freedman wrote:
>>
>>> Rich,
>>>   Are you suggesting we defer the discussion of updating the portlet 
>>> API to support access/retrieval of resources or are you also 
>>> suggesting we defer the discussion of modifying the existing proxy 
>>> resource mechanism to allow user context/cookies to be passed when 
>>> the resource is invoked?  I hope its not the later as JSR 168 needs 
>>> such function -- and asking that the information be carried on the 
>>> URL itself suffers not only from the privacy/exposure issue but also 
>>> from the long URL issue.
>>
>>
>>
>> Could you clarify why this is a JSR168 requirement?
>>
>> Subbu
>>
>>
>>
>> ----------------------------------------------------------------
>> 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]