Re: Issue #2126 - Flash scope cookie enables data exploits

From: Andy Schwartz <>
Date: Fri, 24 May 2013 05:54:27 -0700 (PDT)

Hi Manfred -

It probably does make sense to discuss this with the EG again. Though before we do that, let's try to get some more info about the user requirements. I updated the issue tracker with some questions along these lines.


----- Original Message -----
Sent: Thursday, May 23, 2013 9:41:23 AM GMT -05:00 US/Canada Eastern
Subject: Re: Issue #2126 - Flash scope cookie enables data exploits

Hi Andy,

There has been a user that specifically asked it not to be part of the
session so they
could use the Flash without being bound to a session.

Maybe this should go back to EG level to clarify session or no session?


On 5/23/2013 5:08 AM, Andy Schwartz wrote:
> Hi Manfred -
> Unfortunately I don't have much time to discuss now (more time next
> week), but I wanted to suggest that we strongly consider re-parenting
> the Flash implementation on top of the HttpSession instead of
> re-inventing session-like functionality on top of Application.
> We've discussed this on the expert group more than once, though I
> could only locate this thread in the archives:
> Arjan mentioned this in the issue tracker as well, along with some
> words of caution:
>> arjan tijms added a comment - 16/Feb/12 12:35 PM
>>> Another solution could be to (optionally) store flash data in the
>>> HTTP session and thus piggyback on the security of the JSESSIONID.
>> I just noticed the same thing was proposed as a solution for
>> JAVASERVERFACES-1449, but as it appears some users are strongly
>> against ever using the session for flash data:
>>> I just contacted my user advocate at Garmin corporation, who
>>> advocated for a
>>> "never use the session" option for the flash. I'll try to get a
>>> quote from them to
>>> sway the EG.
> I don't remember seeing the follow up from this.
> The case for avoiding HttpSession use would have be extremely
> compelling given that doing so means re-implementing much of the
> functionality provided by HttpSession at the JSF layer. JSF should be
> leveraging the underlying platform rather than replacing bits of it.
> Arjan
> Andy
> On 5/21/13 3:38 PM, Manfred Riem wrote:
>> Hi all,
>> We are about to start work on issue #2126, see
>> Please let us know if you have any insights on how to tackle this one.
>> Regards,
>> Manfred