-Eric
On 1/18/11 8:30 AM, Nicholas Blair wrote:
I've been working from option 3. There are 2 key elements in the data model: IPortalCookie, which represents a single Cookie Eric is referring to (1 key to relate to all portlet cookies). IPortletCookie, which mimics javax.servlet.http.Cookie per the portlet spec, but also provides a reference to the IPortletEntity that spawned the cookie. There isn't any scoping - as far as I've gotten - so any portlet can see all Cookies (IPortletCookies) in the request. When a portlet calls: javax.servlet.http.Cookie[] PortletRequest#getCookies() Should the returned array contain all non-portlet cookies as well? The only mention in the spec is: 11.1.5.1 The portlet can access cookies provided by the current request with the getCookies method. The returned cookie array provides the portlet with all cookie properties. I read that as yes, all Cookies returned by the normal ServletRequest should be included. On Mon, Jan 17, 2011 at 9:28 PM, Eric Dalquist <eric.dalqu...@doit.wisc.edu> wrote:Hrm, that is a good point. The spec does refer to them in the same areas where it refers to using portlet request/response properties as HTTP headers which also implies no scoping. 3 would also be the easiest to implement since then the cookies have no relation to the portlet definition or entity objects. The more I think about it the more option 3 really seems to make sense. Our general plan for implementation is that uPortal will always set a specially named portal cookie with a big-random-token value in the users browser and store that token in the DB. Any time a portlet sets/reads a cookie it will actually be stored in the DB and never actually sent to the browser. The big technical reason for this is since uPortal is what the spec calls a Streaming Portal by the time portlets have started rendering there has already been content written to the browser. We'll have a background task that does purging of the portal cookie and portlet cookies from the DB to make sure these cookie stores don't just grow forever. -Eric On 1/17/11 4:40 PM, Steve Swinsburg wrote: You're right, it is confusing. From what I have read, there is no guarantee the cookies from one portlet will be available to another one (which is either 1 or 2 below) but it seems an odd use of cookies and general knowledge around the use of cookies would probably assume 3. regards, Steve On 18/01/2011, at 3:30 AM, Eric Dalquist wrote: Nick Blair is working on the cookie support for portlet 2.0 and we've come to a bit of confusion. After re-reading the portlet spec on cookies several times now and one thing is still not clear, how are cookies set by portlets scoped? It seems like there are a few options: Cookies are scoped the same way Preferences are, to the instance of the portlet entity Cookies are scoped at the definition level, essentially Portlet A can share a cookie among any number of users but Portlet B will never see it Cookies are not scoped at all. All portlets work in the same general space for cookies and a cookie set by Portlet A can be seen by Portlet B Does anyone here have thoughts on the intent in the spec or just what your gut feeling would be? -Eric -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: eric.dalqu...@doit.wisc.edu To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
smime.p7s
Description: S/MIME Cryptographic Signature
