On Tue, 04 Feb 2014 15:20:25 -0200, Lance Java <lance.j...@googlemail.com>
wrote:
I hate both ideas!
Encoding in the URL means a useless request and will have issues with
maximum url length.
And security, as you cited in another e-mail, but only if the attacker
manages to change the generated HTML to include the JavaScript URL, but,
if they can already change the generated HTML, security is already lost.
A token requires serverside state and relies on some form of time to
live.
Actually, the token and its corresponding state would be thrown off after
used, so it wouldn't have much of a memory load. The use of some caching
library would solve the time to live problem, and the time to live itself
would be quite short.
There are the two solutions I can see for anyone who wants to use Content
Security Policy. There's no free lunch.
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
