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: 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 BDoes anyone here have thoughts on the intent in the spec or just what your gut feeling would be?-Eric-- You are currently subscribed to [email protected] as: [email protected] 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
