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