[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp-wsia] Minutes for 06 March 2003 Meeting
I would further argue that additional support is also not required for Portlets operating without a session. If cookie support is required to extend to resources, then we have enabled the sharing of any information the Portlet wants to make available without additional extensions to our protocol. We may want to revisit this for v1.1 for the purpose of making it more convenient, but I fail to see a need to press it into v1. Rich Thompson Subbu Allamaraju <subbu@bea.com> 03/13/2003 08:50 AM To: Michael Freedman <Michael.Freedman@oracle.com> 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]