1) why is the class "final"? ==> pls remove that Similarly, please make the variables like allowedHttpHeaders "protected" instead of "private final" or is there some "rationale" behind this (coding guidelines mandating this)?
(In reply to Ralf Hauser from comment #0) > 1) why is the class "final"? > ==> pls remove that Interesting: it's been final since the class was first introduced. markt would have to comment on that decision. My guess is that, since this is a security-related class, it's best to have the configuration as immutable as possible. > Similarly, please make the variables like allowedHttpHeaders "protected" > instead of "private final" or is there some "rationale" behind this (coding > guidelines mandating this)? See above. Rather than making the members protected, there should be a protected constructor, and the fields can therefore remain final.
Other security classes are not final. And an attacker would also have to alter the web.xml to have the subclass used at all to begin with. IMHO, putting such a class as "final" is also against the open source spirit: "No one after me will be smarter than and adding more value with sub-classing it" or are there other reasonings behind this?
(In reply to Ralf Hauser from comment #2) > Other security classes are not final. > And an attacker would also have to alter the web.xml to have the subclass > used at all to begin with. > > IMHO, putting such a class as "final" is also against the open source spirit: > > "No one after me will be smarter than and adding more value with > sub-classing it" or are there other reasonings behind this? There is no need for such an antagonistic comment. A review of the history of the file shows that the explanation is as simple as the class was marked as final in the contribution from the original developer. It is always easier to start off with a more restrictive API and relax it as necessary, than to start with everything open and try and lock it down later. The fields are private (and final where marked) by design. Getters are provided (which for the collections also allow modification). If you'd like additional getters (or setters) then please make your case. The expectation is that the configuration is set on init and remains unchanged for the lifetime of the Filter. Changing that expectation is not impossible but is likely to be a very invasive change.
final removed in - trunk for 9.0.0.M18 onwards - 8.5.x for 8.5.12 onwards - 8.0.x for 8.0.42 onwards - 7.0.x for 7.0.76 onwards
Tested in 8.5.14 --> works fine. Thx for the clarifications that make my comment obsolete - sorry.