> The security issue only exists because of a fundamentally broken
servlet in the examples, and assumes the user will click on a URL.
That's not what I call a security problem.
There is a whole class of security problems that are driven by bad
server code and user interaction, such as reflective XSS due to poor
input validation. Low risk as Filip saz, but a security problem
none-the-less.
- Jim
Filip Hanik - Dev Lists wrote:
Jim Manico wrote:
> I guess we could throw a run time exception if the value contained
any of those. other than that, I'm not sure how to behave
I think this is the best case scenario for v0 cookies. Perhaps, if
you really want to get fancy, you can add a flag to let legacy
solutions roll back to the old/non-standard cookie handling
methodology?
no, we wont do that. we fixed the cookie behavior in this release due
to security issues filed against the old parsing.
The security issue only exists because of a fundamentally broken
servlet in the examples, and assumes the user will click on a URL.
That's not what I call a security problem.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
