Thanks for your input. Regarding the javascript in my proposed concept, for protection of input actions that are rendered through a HTML form a hidden input is the best solution to protect the action behind against CSRF. Javascript is not necessary in that case.
The solution in the wiki by Martijn Brinkers has some drawbacks as stated in the end of article, that can be avoided if a hidden input is used, but the solution works also for action links that issue a HTTP GET request. What is not clear for me is that this solution works for all form and bean based components. This solution seems only to work for actionLink, right - or am I missing something? I'm currently digging into the details of Tapestry and different protection mechanisms against CSRF. As far the most reasonable solution for me is like Andreas Andreou suggested to provide a component mixin, that could be added to all components that are rendered as a HTML form, e.g. Form Components and Bean related components. In the template an additional element has to be explicetely added, that holds the secure token and is rendered as HTML hidden input field. This solution could maybe extended to provide a more general usage pattern, e.g. a site configuration parameter that enables CSRF protection for all form based components without further coding required, or a page scope enabling of this mechanism maybe useful. In a further step it might be useful to protect HTML anchor rendered components also. I will prepare a project proposal with a rough timeline. Who would like to mentor this project - is it Ulrich Stärk? I would like to double check the project proposal with the mentor before I submit it. Best Regards, Markus -- View this message in context: http://tapestry.1045711.n5.nabble.com/GSoC-CSRF-Protection-tp4274965p4279297.html Sent from the Tapestry - Dev mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
