You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2017/02/01 09:52:09 UTC
[Bug 60674] New: Allow subclassing of
org.apache.catalina.filters.CorsFilter
https://bz.apache.org/bugzilla/show_bug.cgi?id=60674
Bug ID: 60674
Summary: Allow subclassing of
org.apache.catalina.filters.CorsFilter
Product: Tomcat 8
Version: 8.5.9
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: hauser@acm.org
Target Milestone: ----
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)?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60674] Allow subclassing of
org.apache.catalina.filters.CorsFilter
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60674
--- Comment #3 from Mark Thomas <ma...@apache.org> ---
(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.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60674] Allow subclassing of
org.apache.catalina.filters.CorsFilter
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60674
--- Comment #2 from Ralf Hauser <ha...@acm.org> ---
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?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60674] Allow subclassing of
org.apache.catalina.filters.CorsFilter
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60674
--- Comment #1 from Christopher Schultz <ch...@christopherschultz.net> ---
(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.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60674] Allow subclassing of
org.apache.catalina.filters.CorsFilter
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60674
--- Comment #5 from Ralf Hauser <ha...@acm.org> ---
Tested in 8.5.14 --> works fine.
Thx for the clarifications that make my comment obsolete - sorry.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60674] Allow subclassing of
org.apache.catalina.filters.CorsFilter
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60674
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #4 from Mark Thomas <ma...@apache.org> ---
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
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org