I've been thinking about the same thing. If we were to add it without the client send any CSRF header than I would agree. It feels like it would have to be a one of two things:
1. a combination of the Knox CSRF header being added and we translate that to the service expected header 2. just a pass through where Knox CSRF is not configured and we make sure that the CSRF header provided by the client isn't blocked from the service A benefit to #1 is that it hides the possible complexities of knowing all the headers for all the services from Knox clients but this comes at the expense of complicated topology config to ensure that we have the header to translate it to configured for each service. If we made the default expected header the same across Knox and all components then maybe we could only have to rewrite the header for those services that change it from the default. On Wed, Jan 20, 2016 at 9:37 AM, Kevin Minder <[email protected]> wrote: > Would Knox automatically adding this header dilute the benefit of it? > Isn’t the point that the browser (i.e. real client) is expected to send the > header? > > > > > On 1/19/16, 7:26 PM, "larry mccay" <[email protected]> wrote: > > >All - > > > >As https://issues.apache.org/jira/browse/HADOOP-12691 gets rolled out in > >Hadoop 2.8 with uptake from hopefully coming from WebHDFS and YARN, Knox > >will likely need to be able to send expected headers to the component > >through dispatch. > > > >This will mean something like a service param to indicate the special > >header to be expected by the service and then each dispatch be able to > >recognize this and send the header. > > > >I will likely file a JIRA for this work but wanted to raise it as an issue > >that will come along with 2.8. > > > >Any thoughts, concerns or questions, insights? > > > >thanks, > > > >--larry >
