You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-user@portals.apache.org by Eric Dalquist <er...@doit.wisc.edu> on 2011/01/17 17:24:07 UTC
Cookie Scopes
I've re-read 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:
1. Cookies are scoped the same way Preferences are, to the instance
of the portlet entity
2. 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
3. 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
Any thoughts on the intent in the spec?
-Eric
Re: Cookie Scopes
Posted by David Taylor <da...@gmail.com>.
On Mon, Jan 17, 2011 at 8:24 AM, Eric Dalquist
<er...@doit.wisc.edu> wrote:
> I've re-read 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
>
> Any thoughts on the intent in the spec?
Since the spec doesn't address scoping directly, I would think its up
to the portal implementation to scope (or not) as an additional
feature. But reading section 19.3.5, it almost sounds like you can't
scope since you should be getting the same behavior in servlet or
portlet request:
"The following methods of the HttpServletRequest must be equivalent to
the methods
of the PortletRequest of similar name ... getCookies()"
I would think scoping by portlet via name or path mangling on
addProperty, the PortletRequest could filter getCookies() and still be
compliant (as long as the HttpServletRequest returned the mangled name