[
https://issues.apache.org/jira/browse/TAP5-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14281386#comment-14281386
]
Massimo Lusetti commented on TAP5-1474:
---------------------------------------
I think this could get in in some form but:
- malicious software can coerce the victim's browser to do GET requests and
POST with specific type which if memory serve are:
application/x-www-form-urlencoded, multipart/form-data and text/plain.
- the rule of thumb is that GET requests are meant to be idempotent they are
not normally protected against CSRF.
- in Tapestry we don't have a full blown mechanism for serving REST requests
and typically all requests are generated by Link (in a way or the other) and
are therefore GET so is usual to have a link to a GET event handler to change
something in the storage.
So my take is this to be a overall filter/dispatcher which if activated is does
the check on all requests coming in and not something that should be activated
on a page-by-page or event-by-event handler.
I guess the trade-off performance wise is irrelevant.
Does it make sense?
> [GSoC] add out-of-the-box protection against cross-site request forgery (CSRF)
> ------------------------------------------------------------------------------
>
> Key: TAP5-1474
> URL: https://issues.apache.org/jira/browse/TAP5-1474
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-core
> Affects Versions: 5.2
> Reporter: Ulrich Stärk
> Labels: bulk-close-candidate
>
> There are several approaches to protect against CSRF. A student working on
> this task will evaluate the possible solutions, discuss with the community
> which to implement and implement and test the chosen approach.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
