From a behavior perspective I can see #1 adding value. In my own words that means this:
1) There is a WebAppSecurityProvider configured with a Knox specific CSRF filter. 2) Each each service dispatch (or rewrite rules) will optionally inject the service specific CSRF headers. There are several points of complexity here: A) The service specific CSRF header should only be injected (i.e. #2) if an inbound CSRF header is verified by #1. This implies of level of cooperation between providers and dispatch that we don’t really have much precedence for yet. B) The configuration for #2 could become a usability issue. C) Will clients be hard coded to send service specific CSRF headers and never capable of sending a Knox specific one? On 1/20/16, 9:49 AM, "larry mccay" <[email protected]> wrote: >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 >>
