[
https://issues.apache.org/jira/browse/HDFS-9711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15144977#comment-15144977
]
Chris Nauroth commented on HDFS-9711:
-------------------------------------
[~lmccay], thanks again. I think we're basically on the same page.
bq. What do you think about going with option #2 and also pulling the
handleHttpInteraction out into a CsrfUtils class.
The implementation of {{handleHttpInteraction}} needs access to the filter
initialization parameters like the header and the methods to ignore. I think
we'd have to refactor all of the data members of the filter into the proposed
{{CsrfUtils}} class. If the class is actually holding state like that, then
something like {{CsrfContext}} would likely be a better name.
{{RestCsrfPreventionFilter}} would then be a very thin shim calling into
{{CsrfContext}}. The DataNode wouldn't use the filter class at all. Instead,
it would work with {{CsrfContext}}. As a side benefit, the DataNode would no
longer need to stub an implementation of {{FilterConfig}}.
Do you think it makes sense to go this far with the refactoring? If so, I can
put together a new patch revision.
> Integrate CSRF prevention filter in WebHDFS.
> --------------------------------------------
>
> Key: HDFS-9711
> URL: https://issues.apache.org/jira/browse/HDFS-9711
> Project: Hadoop HDFS
> Issue Type: New Feature
> Components: datanode, namenode, webhdfs
> Reporter: Chris Nauroth
> Assignee: Chris Nauroth
> Attachments: HDFS-9711.001.patch, HDFS-9711.002.patch,
> HDFS-9711.003.patch, HDFS-9711.004.patch
>
>
> HADOOP-12691 introduced a filter in Hadoop Common to help REST APIs guard
> against cross-site request forgery attacks. This issue tracks integration of
> that filter in WebHDFS.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
