Re: Adding regular expression support to CORS filter
Chris, On 9/28/20 02:40, Christopher Schultz wrote: Carsten, On 9/27/20 05:53, Carsten Klein wrote: Any comments on that? Is it worth preparing a PR? Regular expressions are fairly expensive. Yes, but my measurements of the HashSet-lookups were wrong, since hashValue() of a String gets cached, so, while measuring in a loop, the hash value gets computed only once. Setting up a fair test is challenging (using new strings in the loop causes memory allocations and GCs). I ended with additionally calling a clone of the String's hashValue() function in the loop. Now, testing an origin with HashSet.contains(origin) (current solution) takes about 19 ns for a cache-miss (empty list in bucket) and 30 ns for a cache-hit) on my box. In contrast, evaluating a regular expression takes about 120 ns; so these are about 6 times slower (NOT 25 times as stated in my last mail). The creation of a new Matcher instance each time is a significant bottleneck (in my measurement loop): reusing the same Matcher instance and resetting it with a new input string makes the test taking only about 75 ns (that's only about 4 times slower that the HashSet test). So, regular expressions are not as bad as we were thinking? If there is a way to build the code such that some subset of wildcards can be serviced without regex (and of course exact matches without using regex), then I'm at least a +0 on this. I never intended to implement tests for exact matches with regular expressions. Configured "exact" origins (those without wildcards and not enclosed between slashes) will still be tested with HashSet.contains, of course. So, there's no change (considering performance) for Tomcat setups only using "exactly" defined allowed origins. If someone uses the new "inexact" origin specifiers, will it not be comprehensible that these are more expensive (from a performance point of view)? It may seem like over-engineering, but maybe creating a Matcher interface and a Factory (I know, I know) which produces Matchers which implement the optimal strategy for a particular value would be a good way to do this. A single matcher could be used for really simple values and maybe a MultipleMatcher could be used for multiple different value-checks. Something like that will likely lead to the highest-performing filter processing. I did some tests on that. As I don't believe, that a (self-made) NFA-based solution could outperform Java's regular expression engine, I was looking for a different (simpler) algorithm. I started with a rule-driven globbing algorithm, that supports ? (any char except "."), # (any digit, using Character.isDigit) $ (any letter, using Character.isAlphabetic) as well as literal character sequences. (Actually, I followed your suggestion. Your Matchers are my Rules together with a piece of code in a switch-case block. Using real classes/instances for the matchers requires method invocations and maybe instanceof tests. Both are adding extra overhead, so I decided to use a more C-like approach.) That simple algorithm takes about 42 ns and so, is still 2 times slower than the HashSet test. I already made more than half the way down to support * and ** multi-matching wildcards. That implementation uses non-recursive backtracking, similar to the algorithms described at https://www.codeproject.com/Articles/5163931/Fast-String-Matching-with-Wildcards-Globs-and-Giti With * and ** partly in place, time consumption is about 50 ns. The code additions for making the algorithm work on the many edge cases will very likely add more nanoseconds to the test so, we may soon end at 60 ns or even more. That's almost the same time required for evaluating a regular expression (without the time needed to create the Matcher instance). The algorithm is optimized and uses only a few method calls and no OOP constructs (by using the Rules, which are like beans that specify what to match next, the whole logic can be implemented in a single method). But it's still not much faster than a Java regular expression test. I don't believe, that it's worth to (self-)implement such a rather complex (error prone) and hard to understand (and maintain) algorithm, if it's not significantly faster than real Java regular expressions. Anyhow, if performance should not degrade due to using wildcards in the allowed origins, the goal is not just to be better than Java regular expressions, but to be close to the HashSet test (~19 ns). And, if real regular expressions shall be used as well (enclosed between slashes), that all will not help much for these. That's why I wanted to combine this with a HashMap-based (LRU-)cache, so that regular expressions must only be evaluated if the current request's origin is not yet in the cache. This cache's performance nearly equals the performance of the HashSet test (depending on whether real LRU is used or not). That way, the time required for testing a regular expres
Re: Adding regular expression support to CORS filter
Carsten, On 9/27/20 05:53, Carsten Klein wrote: > Any comments on that? Is it worth preparing a PR? Regular expressions are fairly expensive. If there is a way to build the code such that some subset of wildcards can be serviced without regex (and of course exact matches without using regex), then I'm at least a +0 on this. It may seem like over-engineering, but maybe creating a Matcher interface and a Factory (I know, I know) which produces Matchers which implement the optimal strategy for a particular value would be a good way to do this. A single matcher could be used for really simple values and maybe a MultipleMatcher could be used for multiple different value-checks. Something like that will likely lead to the highest-performing filter processing. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Adding regular expression support to CORS filter
Any comments on that? Is it worth preparing a PR?
Adding regular expression support to CORS filter
Hi there,
I'd like to contribute a CORS filter enhancement, making it accept both
wildcard-based and 'regular expression'-based expressions for its
allowed origins list.
I know this from a project based on Jetty, which has support for, at
least, simple wildcard matching (*). Specifying multiple allowed origins
with one pattern comes quite handy if there are numerous developer
machines that all access one single server from their browsers.
The implementation shall support two flavors of expressions:
- Java Pattern Class based expressions
Enclosed between slashes (/.../) these bring the full power of regular
expressions to the filter's allowed origins list configuration. This
will also support specifying pattern flags by appending single
characters after the terminating slash (like in /^foo.bar$/i for
case-insensitive matching).
- Wildcard-based simple expressions
With a much simpler syntax, these expressions are more compact and may
be more intuitive for people not familiar with regular expressions.
Although less powerful than *real* regular expressions, the special
characters supported should provide enough options to specify allowed
origins efficiently:
? matches any single character except the domain separator (.)
# matches any single digit
* matches any number of any characters except the domain
separator (.) including none
** matches any number of any characters including none (this also
matches the domain separator and so matches several sub-
domains)
(Technically, any number > 1 of consecutive asterisks are
treated as a single ** pattern.)
[abc] not yet sure about character classes
[a-z]
[^abc]
Wildcard-based expressions are implemented by regular expressions as
well. Such an expression is turned into an *anchored* regular expression
during initialization e.g.
http://?*.devzone.intra ==> ^http://[^.][^.]*\.devzone\.intra$
Of course, it is still possible to specify literal origins, as well as
the sole '*' to allow access from any origin. So, the value of the
'cors.allowed.origins' initialization parameter may look like this:
https://www.apache.org,
http://?*.devzone.intra,
/:\/\/staginghost-\d{1,3}.mycompany.corp$/i
As you can see, *real* Java regular expressions are not anchored by
default. The above one is end anchored only (making it match any protocol).
Obviously, forward slashes withing the regular expression must be
escaped in order not to end the expression prematurely.
The current CORS filter implementation uses a HashSet to
determine whether a given origin is valid or not. That's a quite fast
solution. Since evaluating a regular expression is much more expensive
(~25 times slower), a sort of caching mechanism is required.
The idea is to transparently add positive matches (allowed origins) to
the same HashSet that already contains all literally specified
allowed origins. Since these positives form a (rather small) countable
set (in practice) we could simply just add these without worrying about
cache removal. There is no difference in memory consumption compared to
the current implementation: all allowed origins must be stored in that
hash set.
There *may* be more disallowed origins than allowed ones so, another
cache for non-matching origins is certainly a good idea. However, this
adds extra memory consumption and that cache should not grow with no
limit. The idea is to use a LinkedHashMap with access order ordering
mode (accessOrder = true). This makes the map an LRU-cache, removing the
least recently used entry when a defined maximum capacity is reached
while adding a new entry. Maybe that cache's capacity should be
configurable.
Write access to that caches must be synchronized. At current, I tend to
use a ReadWriteLock.
So, the new algorithm for determining whether an origin is allowed or
not is like so:
private boolean isOriginAllowed(final String origin) {
if (anyOriginAllowed) {
return true;
}
if (allowedOrigins.contains(origin)) {
return true;
}
if (notAllowedOrigins.containsKey(origin)) {
return false;
}
// synchronized block starts here (using a ReadWriteLock)
boolean result = false;
for (Pattern pattern : allowedOriginPatterns) {
if (pattern.matcher(origin).matches()) {
allowedOrigins.add(origin);
break;
}
}
if (!result) {
// origin is definitely not allowed
notAllowedOrigins.put(origin, null);
}
// release lock here
return result;
}
As you can see, there are not more than N extra evaluations of a regular
expression required for an allowed origin during the filter's lifetime
(when the origin is used for the first time), N being the number of
different expressions configured.
The same is true for not allowed origins if the LRU cach
Re: cors filter in WEB-INF/web.xml
Hello Masber, In order to get accurate answers it would be helpful if you could provide details like: - Platform details: OS, jdk/jre, apache-tomcat version... - "I went through documentation" which one? perhaps https://tomcat.apache.org/tomcat-9.0-doc/config/filter.html#CORS_Filter - "my web client still complains" I guess that you get some error response here; have you checked your logs? Hope it helps, Luis 2018-07-28 9:00 GMT+02:00 masber masber : > Dear Apache Tomcat community, > > > I am learning Tomcat and would like to create a crosfilter, I went through > the documentation and added the code suggested but my web client still > complains. > > > This is the content of my web.xml file: > > > > > Archetype Created Web Application > > > > > jersey-servlet > > org.glassfish.jersey.servlet. > ServletContainer > > > > > jersey.config.server.provider.packages param-name> > > returnitRest > > > > > > > jersey.config.server.provider.classnames param-name> > > org.glassfish.jersey.media.multipart. > MultiPartFeature > > > > > > > javax.ws.rs.Application > > returnitRest.AppConfig > > > > > 1 > > > > > > > jersey-servlet > > /rest/* > > > > > > > CorsFilter > > org.apache.catalina.filters.CorsFilter > > > > cors.allowed.origins > > * > > > > > > cors.allowed.methods > > GET,POST,HEAD,OPTIONS,PUT > > > > > > cors.allowed.headers > > Content-Type,X-Requested-With,accept,Origin, > Access-Control-Request-Method,Access-Control-Request-Headers > > > > > > cors.exposed.headers > > Access-Control-Allow-Origin,Access-Control- > Allow-Credentials > > > > > > cors.support.credentials > > true > > > > > > cors.preflight.maxage > > 10 > > > > > > > > CorsFilter > > /* > > > > > > > I was wondering whether someone could help me to understand what I am > doing wrong? > > > thank you very much > > -- "Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better." - Samuel Beckett
cors filter in WEB-INF/web.xml
Dear Apache Tomcat community, I am learning Tomcat and would like to create a crosfilter, I went through the documentation and added the code suggested but my web client still complains. This is the content of my web.xml file: Archetype Created Web Application jersey-servlet org.glassfish.jersey.servlet.ServletContainer jersey.config.server.provider.packages returnitRest jersey.config.server.provider.classnames org.glassfish.jersey.media.multipart.MultiPartFeature javax.ws.rs.Application returnitRest.AppConfig 1 jersey-servlet /rest/* CorsFilter org.apache.catalina.filters.CorsFilter cors.allowed.origins * cors.allowed.methods GET,POST,HEAD,OPTIONS,PUT cors.allowed.headers Content-Type,X-Requested-With,accept,Origin,Access-Control-Request-Method,Access-Control-Request-Headers cors.exposed.headers Access-Control-Allow-Origin,Access-Control-Allow-Credentials cors.support.credentials true cors.preflight.maxage 10 CorsFilter /* I was wondering whether someone could help me to understand what I am doing wrong? thank you very much
Re: [EXTERNAL] Re: Configuring CORS filter
Thank you Mark! For the quick reply! Yeah...Apache reports it as LOW and they report as MEDIUM. We have to mitigate all MEDIUM and HIGH vulnerabilities. Best regards, Rick On Wed, Jun 20, 2018 at 1:00 PM, Mark Thomas wrote: > On 20/06/18 18:16, Bradley, Richard wrote: > > Hello, > > > > Tomcat version: 8.5.31 > > O/S: Windows Server 2008 R2 > > > > McAfee vulnerability checker has reported a MEDIUM level vulnerability as > > follows: > > > > Vulnerability: CVE-2018-8014: Apache Tomcat Vulnerability Prior To 8.5.32 > > [FID 23621] > > > > Apache Software Foundation reports this in annou...@tomcat.apache.org > > <https://lists.apache.org/list.html?annou...@tomcat.apache.org>: > > > > CVE-2018-8014 Insecure defaults for CORS filter > > > > and the only mitigation is to "Configure the filter appropriately for > your > > environment" > > > > My question is: > > > > What if you don't have a CORS filter configured anywhere in the Tomcat > and > > web apps associated web.xml files? > > You have nothing to worry about. > > Well, apart from the poor quality of your vulnerability scanner that > looks like it is reporting a CORS issue without checking to see if CORS > headers are being sent. > > Mark > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > -- Richard M. Bradley (Rick) *Geospatial Engineer* BLM NOC EGIS Sanborn Map Company, Inc. Phone number: (303) 236-4538 rmbrad...@blm.gov "Decide that you want it more than you're afraid of it. Your greatest dreams are all on the other side of the wall of fear and caution." - Unknown This e-mail, including any attachments, contains information intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged and/or confidential or is otherwise protected by law. If you are not the intended recipient or agent or an employee responsible for delivering the communication to the intended recipient, you are hereby notified that any review, use, disclosure, copying and/or distribution of its contents is prohibited. If you have received this e-mail in error, please notify us immediately by reply to sender only and destroy the original.
Re: Configuring CORS filter
On 20/06/18 18:16, Bradley, Richard wrote: > Hello, > > Tomcat version: 8.5.31 > O/S: Windows Server 2008 R2 > > McAfee vulnerability checker has reported a MEDIUM level vulnerability as > follows: > > Vulnerability: CVE-2018-8014: Apache Tomcat Vulnerability Prior To 8.5.32 > [FID 23621] > > Apache Software Foundation reports this in annou...@tomcat.apache.org > <https://lists.apache.org/list.html?annou...@tomcat.apache.org>: > > CVE-2018-8014 Insecure defaults for CORS filter > > and the only mitigation is to "Configure the filter appropriately for your > environment" > > My question is: > > What if you don't have a CORS filter configured anywhere in the Tomcat and > web apps associated web.xml files? You have nothing to worry about. Well, apart from the poor quality of your vulnerability scanner that looks like it is reporting a CORS issue without checking to see if CORS headers are being sent. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Configuring CORS filter
Hello, Tomcat version: 8.5.31 O/S: Windows Server 2008 R2 McAfee vulnerability checker has reported a MEDIUM level vulnerability as follows: Vulnerability: CVE-2018-8014: Apache Tomcat Vulnerability Prior To 8.5.32 [FID 23621] Apache Software Foundation reports this in annou...@tomcat.apache.org <https://lists.apache.org/list.html?annou...@tomcat.apache.org>: CVE-2018-8014 Insecure defaults for CORS filter and the only mitigation is to "Configure the filter appropriately for your environment" My question is: What if you don't have a CORS filter configured anywhere in the Tomcat and web apps associated web.xml files? It seems that if you explicitly configure a minimum filter specified in the documentation (https://tomcat.apache.org/tomcat-8.5-doc/config/filter.html#CORS_Filter) then you have to be concerned about the cors.support.credentials allowing the default of "true". Thanks, Rick -- Richard M. Bradley (Rick) *Geospatial Engineer* BLM NOC EGIS Sanborn Map Company, Inc. Phone number: (303) 236-4538 rmbrad...@blm.gov "Decide that you want it more than you're afraid of it. Your greatest dreams are all on the other side of the wall of fear and caution." - Unknown This e-mail, including any attachments, contains information intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged and/or confidential or is otherwise protected by law. If you are not the intended recipient or agent or an employee responsible for delivering the communication to the intended recipient, you are hereby notified that any review, use, disclosure, copying and/or distribution of its contents is prohibited. If you have received this e-mail in error, please notify us immediately by reply to sender only and destroy the original.
[SECURITY] CVE-2018-8014 Insecure defaults for CORS filter
CVE-2018-8014 Insecure defaults for CORS filter Severity: Low Vendor: The Apache Software Foundation Versions Affected: Apache Tomcat 9.0.0.M1 to 9.0.8 Apache Tomcat 8.5.0 to 8.5.31 Apache Tomcat 8.0.0.RC1 to 8.0.52 Apache Tomcat 7.0.41 to 7.0.88 Description: The defaults settings for the CORS filter are insecure and enable 'supportsCredentials' for all origins. It is expected that users of the CORS filter will have configured it appropriately for their environment rather than using it in the default configuration. Therefore, it is expected that most users will not be impacted by this issue. Mitigation: Users of the affected versions should apply one of the following mitigations. - Configure the filter appropriately for your environment Secure defaults will be provided in the following versions: - Apache Tomcat 9.0.9 or later when released - Apache Tomcat 8.5.32 or later when released - Apache Tomcat 8.0.53 or later when released - Apache Tomcat 7.0.89 or later when released History: 2018-05-15 Original advisory References: [1] http://tomcat.apache.org/security-9.html [2] http://tomcat.apache.org/security-8.html [3] http://tomcat.apache.org/security-7.html - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat CORS filter not allowing origin with file:// when resource access done from WebView
Hi, We are facing a problem in tomcat cors filter. Below is the filter configurations added in web.xml for cors request processing. CorsFilter org.apache.catalina.filters.CorsFilter cors.allowed.origins * cors.allowed.methods GET,POST,HEAD,OPTIONS,PUT cors.allowed.headers Content-Type,X-Requested-With,accept,Origin,Access-Control-Request-Method,Access-Control-Request-Headers,KN-X-UserAgent cors.exposed.headers Access-Control-Allow-Origin,Access-Control-Allow-Credentials cors.support.credentials true cors.preflight.maxage 10 CorsFilter /* The Tomcat server processes all the cors request successfully when the Origin in the request contains a domain for all sachems like http://www.kodiakptt.com , file://local etc. POST http://kodiakptt.com/poc/ HTTP/1.1 Host: medistreet.in Connection: keep-alive Access-Control-Request-Method: POST Origin: http://www.kodiakptt.com<http://www.kodiakptt.com/> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.116 Safari/537.36 The http request fails if the Origin header contains only scheme and not a domain name. The Server sends 403 when the request is as below. POST http://kodiakptt.com/poc/ HTTP/1.1 Accept: application/json, text/plain, */* Origin: file:// User-Agent: Mozilla/5.0 (Linux; Android 4.4.2; XT1033 Build/KXB20.25-1.31) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/30.0.0.0 Mobile Safari/537.36 Content-Type: application/json;charset=UT The Difference in request headers from the successfull operation and failed operations are 1. Origin is file:// in falied and http://www.kodiakptt.com<http://www.kodiakptt.com/> in successfully processed request 2. The User-Agent header. Regards, Chandra
Re: Cors-Filter
> On Feb 26, 2016, at 3:40 PM, Christopher Schultz > wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Jose, > > On 2/26/16 7:08 AM, Jose María Zaragoza wrote: >> 2016-02-26 9:08 GMT+01:00 RICHARD DOUST : >>> My question is, why doesn't it work, or, how can I debug it? >> >> Are you tested to allow to all origins (default option) ? Only for >> testing purpose, I mean: >> >> cors.allowed.origins >> * >> >> At first sight, your settings should work, but ... > > This is exactly what I was going to suggest. > > Also, what HTTP METHOD are you actually using? POST? POST > > If you are using https://, I would make sure that https:// URLs > actually appear in your configuration (you only have HTTP URLs). The origin of the request is http://, that’s why I put it in there. Do I also need to put https:// in there? Seems counter-intuitive, but okay. I’ll try it. Thanks. > > - -chris > >>> I guess I'm going to have to figure out how to get the code for >>> org.apache associated with the jar file so that I can see the >>> source in Eclipse and set a breakpoint. I have read elsewhere >>> that any http page that attempts to mix in https content is as >>> insecure as the page that uses http exclusively, being subject to >>> man in the middle attacks and that once you need https everything >>> needs to be https, but in a large SPA, that seems to me to mean a >>> lot of potentially unnecessary overhead. I'd like to know what >>> some experts think. >>> >>> Thanks >>> >>> Sent from my iPad >>> On Feb 26, 2016, at 2:42 AM, André Warnier (tomcat) wrote: > On 25.02.2016 22:59, RICHARD DOUST wrote: Hi, > > I’m running Tomcat 7.0. Can’t find the version.bat file, so I > don’t know more than that. It’s installed on a Windows > computer running Windows Server 2003 DataCenter Edition. > (How’s that for refusing to upgrade?) Anyway, it’s a client’s > box. I’m trying to migrate an application to JavaScript from > GWT, but that’s beside the point. The problem is, I’m unable > to send an XMLHttpRequest to this Tomcat instance via https. > The site is being served by the same domain, but via http. > > I get: > > Failed to load resource: Origin http://www.domain.com is not > allowed by Access-Control-Allow-Origin. > https://www.domain.com/application/api/request XMLHttpRequest > cannot load https://www.domain.com/application/api/reqeuest. > Origin http://www.domain.com is not allowed by > Access-Control-Allow-Origin. > > This is an excerpt my web.xml file for the war: > >> CorsFilter >> org.apache.catalina.filters.CorsFilter> >> >> > >> cors.allowed.origins >> http://www.domain.com, http://beta.domain.com:8080, >> http://localhost:8080 >> cors.allowed.methods >> GET,POST,HEAD,OPTIONS,PUT >> >> >> CorsFilter >> /api/* > > > I’d like to debug this, but I don’t know how to go about it. > Am I suffering from a basic misunderstanding? Does cors not > allow http to https? Anyway, any help would be appreciated. > Honestly, I don't know much about CORS, but I looked at the specs, here : http://tools.ietf.org/html/rfc6454 (*) and it seems to me indeed that in 3.2, Q: Why not just use the host?, it indeed says that the scheme "http" or "https", is part of the origin. I interpret this as meaning that if the HTML page was obtained from "http://www.domain.com";, a call made from within it, to "https://www.domain.com"; would not qualify as "from the same origin". Further in 3.2.1, it gives some examples : Each of the following resources has a different origin from the others. http://example.com/ http://example.com:8080/ http://www.example.com/ https://example.com:80/ https://example.com/ http://example.org/ (*) pointed at by the on-line Tomcat documentation : https://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CORS_Fil > ter > - -> cors.allowed.origins -> "origin" > - - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org >>> >>> - >>> >>> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >>> >> >> - >> >> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEY
Re: Cors-Filter
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jose, On 2/26/16 7:08 AM, Jose María Zaragoza wrote: > 2016-02-26 9:08 GMT+01:00 RICHARD DOUST : >> My question is, why doesn't it work, or, how can I debug it? > > Are you tested to allow to all origins (default option) ? Only for > testing purpose, I mean: > > cors.allowed.origins > * > > At first sight, your settings should work, but ... This is exactly what I was going to suggest. Also, what HTTP METHOD are you actually using? POST? If you are using https://, I would make sure that https:// URLs actually appear in your configuration (you only have HTTP URLs). - -chris >> I guess I'm going to have to figure out how to get the code for >> org.apache associated with the jar file so that I can see the >> source in Eclipse and set a breakpoint. I have read elsewhere >> that any http page that attempts to mix in https content is as >> insecure as the page that uses http exclusively, being subject to >> man in the middle attacks and that once you need https everything >> needs to be https, but in a large SPA, that seems to me to mean a >> lot of potentially unnecessary overhead. I'd like to know what >> some experts think. >> >> Thanks >> >> Sent from my iPad >> >>> On Feb 26, 2016, at 2:42 AM, André Warnier (tomcat) >>> wrote: >>> On 25.02.2016 22:59, RICHARD DOUST wrote: Hi, I’m running Tomcat 7.0. Can’t find the version.bat file, so I don’t know more than that. It’s installed on a Windows computer running Windows Server 2003 DataCenter Edition. (How’s that for refusing to upgrade?) Anyway, it’s a client’s box. I’m trying to migrate an application to JavaScript from GWT, but that’s beside the point. The problem is, I’m unable to send an XMLHttpRequest to this Tomcat instance via https. The site is being served by the same domain, but via http. I get: Failed to load resource: Origin http://www.domain.com is not allowed by Access-Control-Allow-Origin. https://www.domain.com/application/api/request XMLHttpRequest cannot load https://www.domain.com/application/api/reqeuest. Origin http://www.domain.com is not allowed by Access-Control-Allow-Origin. This is an excerpt my web.xml file for the war: > CorsFilter > org.apache.catalina.filters.CorsFilter > > > cors.allowed.origins > http://www.domain.com, http://beta.domain.com:8080, > http://localhost:8080 > cors.allowed.methods > GET,POST,HEAD,OPTIONS,PUT > > > CorsFilter > /api/* I’d like to debug this, but I don’t know how to go about it. Am I suffering from a basic misunderstanding? Does cors not allow http to https? Anyway, any help would be appreciated. >>> >>> Honestly, I don't know much about CORS, but I looked at the >>> specs, here : http://tools.ietf.org/html/rfc6454 (*) and it >>> seems to me indeed that in 3.2, Q: Why not just use the host?, >>> it indeed says that the scheme "http" or "https", is part of >>> the origin. I interpret this as meaning that if the HTML page >>> was obtained from "http://www.domain.com";, a call made from >>> within it, to "https://www.domain.com"; would not qualify as >>> "from the same origin". >>> >>> Further in 3.2.1, it gives some examples : >>> >>> Each of the following resources has a different origin from >>> the others. >>> >>> http://example.com/ http://example.com:8080/ >>> http://www.example.com/ https://example.com:80/ >>> https://example.com/ http://example.org/ >>> >>> >>> (*) pointed at by the on-line Tomcat documentation : >>> https://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CORS_Fil ter >>> >>> - -> cors.allowed.origins -> "origin" >>> >>> >>> - - >>> >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >>> >> >> - >> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlbQuDUACgkQ9CaO5/Lv0PBDBQCfe2fqs1g47UjQmQfB5KlZ6RWM 85QAnRsoWbcs3rSpiUcBEQcOJqqg5cjr =es80 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cors-Filter
2016-02-26 9:08 GMT+01:00 RICHARD DOUST : > My question is, why doesn't it work, or, how can I debug it? Are you tested to allow to all origins (default option) ? Only for testing purpose, I mean: cors.allowed.origins * At first sight, your settings should work, but ... > I guess I'm going to have to figure out how to get the code for org.apache > associated with the jar file so that I can see the source in Eclipse and set > a breakpoint. > I have read elsewhere that any http page that attempts to mix in https > content is as insecure as the page that uses http exclusively, being subject > to man in the middle attacks and that once you need https everything needs to > be https, but in a large SPA, that seems to me to mean a lot of potentially > unnecessary overhead. I'd like to know what some experts think. > > Thanks > > Sent from my iPad > >> On Feb 26, 2016, at 2:42 AM, André Warnier (tomcat) wrote: >> >>> On 25.02.2016 22:59, RICHARD DOUST wrote: >>> Hi, >>> >>> I’m running Tomcat 7.0. Can’t find the version.bat file, so I don’t know >>> more than that. It’s installed on a Windows computer running Windows Server >>> 2003 DataCenter Edition. (How’s that for refusing to upgrade?) Anyway, it’s >>> a client’s box. I’m trying to migrate an application to JavaScript from >>> GWT, but that’s beside the point. The problem is, I’m unable to send an >>> XMLHttpRequest to this Tomcat instance via https. The site is being served >>> by the same domain, but via http. >>> >>> I get: >>> >>> Failed to load resource: Origin http://www.domain.com is not allowed by >>> Access-Control-Allow-Origin. >>> https://www.domain.com/application/api/request >>> XMLHttpRequest cannot load https://www.domain.com/application/api/reqeuest. >>> Origin http://www.domain.com is not allowed by Access-Control-Allow-Origin. >>> >>> This is an excerpt my web.xml file for the war: >>> CorsFilter org.apache.catalina.filters.CorsFilter cors.allowed.origins http://www.domain.com, http://beta.domain.com:8080, http://localhost:8080 cors.allowed.methods GET,POST,HEAD,OPTIONS,PUT CorsFilter /api/* >>> >>> >>> I’d like to debug this, but I don’t know how to go about it. Am I suffering >>> from a basic misunderstanding? Does cors not allow http to https? Anyway, >>> any help would be appreciated. >>> >> >> Honestly, I don't know much about CORS, but I looked at the specs, here : >> http://tools.ietf.org/html/rfc6454 (*) >> and it seems to me indeed that in >> 3.2, Q: Why not just use the host?, >> it indeed says that the scheme "http" or "https", is part of the origin. >> I interpret this as meaning that if the HTML page was obtained from >> "http://www.domain.com";, a call made from within it, to >> "https://www.domain.com"; would not qualify as "from the same origin". >> >> Further in 3.2.1, it gives some examples : >> >> Each of the following resources has a different origin from the >> others. >> >> http://example.com/ >> http://example.com:8080/ >> http://www.example.com/ >> https://example.com:80/ >> https://example.com/ >> http://example.org/ >> >> >> (*) pointed at by the on-line Tomcat documentation : >> https://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CORS_Filter >> -> cors.allowed.origins -> "origin" >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cors-Filter
Hi. On this list, it is preferred to not top-post, but respond in-line or below the previous intervention. Re : http://tomcat.apache.org/lists.html#tomcat-users -> important -> 6 It makes it easier to follow the conversation, and for people with small screens, to avoid scrolling up and down all the time. So I have re-positioned your answer below. On 26.02.2016 09:08, RICHARD DOUST wrote: On Feb 26, 2016, at 2:42 AM, André Warnier (tomcat) wrote: On 25.02.2016 22:59, RICHARD DOUST wrote: Hi, I’m running Tomcat 7.0. Can’t find the version.bat file, so I don’t know more than that. It’s installed on a Windows computer running Windows Server 2003 DataCenter Edition. (How’s that for refusing to upgrade?) Anyway, it’s a client’s box. I’m trying to migrate an application to JavaScript from GWT, but that’s beside the point. The problem is, I’m unable to send an XMLHttpRequest to this Tomcat instance via https. The site is being served by the same domain, but via http. I get: Failed to load resource: Origin http://www.domain.com is not allowed by Access-Control-Allow-Origin. https://www.domain.com/application/api/request XMLHttpRequest cannot load https://www.domain.com/application/api/reqeuest. Origin http://www.domain.com is not allowed by Access-Control-Allow-Origin. This is an excerpt my web.xml file for the war: CorsFilter org.apache.catalina.filters.CorsFilter cors.allowed.origins http://www.domain.com, http://beta.domain.com:8080, http://localhost:8080 cors.allowed.methods GET,POST,HEAD,OPTIONS,PUT CorsFilter /api/* I’d like to debug this, but I don’t know how to go about it. Am I suffering from a basic misunderstanding? Does cors not allow http to https? Anyway, any help would be appreciated. Honestly, I don't know much about CORS, but I looked at the specs, here : http://tools.ietf.org/html/rfc6454 (*) and it seems to me indeed that in 3.2, Q: Why not just use the host?, it indeed says that the scheme "http" or "https", is part of the origin. I interpret this as meaning that if the HTML page was obtained from "http://www.domain.com";, a call made from within it, to "https://www.domain.com"; would not qualify as "from the same origin". Further in 3.2.1, it gives some examples : Each of the following resources has a different origin from the others. http://example.com/ http://example.com:8080/ http://www.example.com/ https://example.com:80/ https://example.com/ http://example.org/ (*) pointed at by the on-line Tomcat documentation : https://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CORS_Filter -> cors.allowed.origins -> "origin" There's no doubt in my mind that this is considered a cross-domain request. The question is, why is it not being allowed given the configuration. The domain that requested the original page (via http) is specifically set to be allowed to access the site in a cross-domain scenario. Ok, sorry to have misunderstood your question. I'm new at this CORS stuff.. My question is, why doesn't it work, or, how can I debug it? I guess I'm going to have to figure out how to get the code for org.apache associated with the jar file so that I can see the source in Eclipse and set a breakpoint. I have read elsewhere that any http page that attempts to mix in https content is as insecure as the page that uses http exclusively, being subject to man in the middle attacks and that once you need https everything needs to be https There is a short explanation for this view in the same RFC, at 3.2. Origin -> Q: Why not just use the host? , but in a large SPA, that seems to me to mean a lot of potentially unnecessary overhead. This is another debate. In my heart, I tend to agree with you. But then, it seems that even high-traffic sites are switching to HTTPS overall, so I guess it does not have such a fearsome impact on performance anymore. I'd like to know what some experts think. I guess I'd better leave it to them then, and keep watching this thread to learn more about CORS.. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cors-Filter
There's no doubt in my mind that this is considered a cross-domain request. The question is, why is it not being allowed given the configuration. The domain that requested the original page (via http) is specifically set to be allowed to access the site in a cross-domain scenario. My question is, why doesn't it work, or, how can I debug it? I guess I'm going to have to figure out how to get the code for org.apache associated with the jar file so that I can see the source in Eclipse and set a breakpoint. I have read elsewhere that any http page that attempts to mix in https content is as insecure as the page that uses http exclusively, being subject to man in the middle attacks and that once you need https everything needs to be https, but in a large SPA, that seems to me to mean a lot of potentially unnecessary overhead. I'd like to know what some experts think. Thanks Sent from my iPad > On Feb 26, 2016, at 2:42 AM, André Warnier (tomcat) wrote: > >> On 25.02.2016 22:59, RICHARD DOUST wrote: >> Hi, >> >> I’m running Tomcat 7.0. Can’t find the version.bat file, so I don’t know >> more than that. It’s installed on a Windows computer running Windows Server >> 2003 DataCenter Edition. (How’s that for refusing to upgrade?) Anyway, it’s >> a client’s box. I’m trying to migrate an application to JavaScript from GWT, >> but that’s beside the point. The problem is, I’m unable to send an >> XMLHttpRequest to this Tomcat instance via https. The site is being served >> by the same domain, but via http. >> >> I get: >> >> Failed to load resource: Origin http://www.domain.com is not allowed by >> Access-Control-Allow-Origin. >> https://www.domain.com/application/api/request >> XMLHttpRequest cannot load https://www.domain.com/application/api/reqeuest. >> Origin http://www.domain.com is not allowed by Access-Control-Allow-Origin. >> >> This is an excerpt my web.xml file for the war: >> >>> >>>CorsFilter >>>org.apache.catalina.filters.CorsFilter >>> >>>cors.allowed.origins >>> http://www.domain.com, >>> http://beta.domain.com:8080, http://localhost:8080 >>> >>> >>>cors.allowed.methods >>>GET,POST,HEAD,OPTIONS,PUT >>> >>> >>> >>> >>> CorsFilter >>> /api/* >>> >> >> >> I’d like to debug this, but I don’t know how to go about it. Am I suffering >> from a basic misunderstanding? Does cors not allow http to https? Anyway, >> any help would be appreciated. >> > > Honestly, I don't know much about CORS, but I looked at the specs, here : > http://tools.ietf.org/html/rfc6454 (*) > and it seems to me indeed that in > 3.2, Q: Why not just use the host?, > it indeed says that the scheme "http" or "https", is part of the origin. > I interpret this as meaning that if the HTML page was obtained from > "http://www.domain.com";, a call made from within it, to > "https://www.domain.com"; would not qualify as "from the same origin". > > Further in 3.2.1, it gives some examples : > > Each of the following resources has a different origin from the > others. > > http://example.com/ > http://example.com:8080/ > http://www.example.com/ > https://example.com:80/ > https://example.com/ > http://example.org/ > > > (*) pointed at by the on-line Tomcat documentation : > https://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CORS_Filter > -> cors.allowed.origins -> "origin" > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cors-Filter
On 25.02.2016 22:59, RICHARD DOUST wrote: Hi, I’m running Tomcat 7.0. Can’t find the version.bat file, so I don’t know more than that. It’s installed on a Windows computer running Windows Server 2003 DataCenter Edition. (How’s that for refusing to upgrade?) Anyway, it’s a client’s box. I’m trying to migrate an application to JavaScript from GWT, but that’s beside the point. The problem is, I’m unable to send an XMLHttpRequest to this Tomcat instance via https. The site is being served by the same domain, but via http. I get: Failed to load resource: Origin http://www.domain.com is not allowed by Access-Control-Allow-Origin. https://www.domain.com/application/api/request XMLHttpRequest cannot load https://www.domain.com/application/api/reqeuest. Origin http://www.domain.com is not allowed by Access-Control-Allow-Origin. This is an excerpt my web.xml file for the war: CorsFilter org.apache.catalina.filters.CorsFilter cors.allowed.origins http://www.domain.com, http://beta.domain.com:8080, http://localhost:8080 cors.allowed.methods GET,POST,HEAD,OPTIONS,PUT CorsFilter /api/* I’d like to debug this, but I don’t know how to go about it. Am I suffering from a basic misunderstanding? Does cors not allow http to https? Anyway, any help would be appreciated. Honestly, I don't know much about CORS, but I looked at the specs, here : http://tools.ietf.org/html/rfc6454 (*) and it seems to me indeed that in 3.2, Q: Why not just use the host?, it indeed says that the scheme "http" or "https", is part of the origin. I interpret this as meaning that if the HTML page was obtained from "http://www.domain.com";, a call made from within it, to "https://www.domain.com"; would not qualify as "from the same origin". Further in 3.2.1, it gives some examples : Each of the following resources has a different origin from the others. http://example.com/ http://example.com:8080/ http://www.example.com/ https://example.com:80/ https://example.com/ http://example.org/ (*) pointed at by the on-line Tomcat documentation : https://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CORS_Filter -> cors.allowed.origins -> "origin" - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Cors-Filter
Hi, I’m running Tomcat 7.0. Can’t find the version.bat file, so I don’t know more than that. It’s installed on a Windows computer running Windows Server 2003 DataCenter Edition. (How’s that for refusing to upgrade?) Anyway, it’s a client’s box. I’m trying to migrate an application to JavaScript from GWT, but that’s beside the point. The problem is, I’m unable to send an XMLHttpRequest to this Tomcat instance via https. The site is being served by the same domain, but via http. I get: Failed to load resource: Origin http://www.domain.com is not allowed by Access-Control-Allow-Origin. https://www.domain.com/application/api/request XMLHttpRequest cannot load https://www.domain.com/application/api/reqeuest. Origin http://www.domain.com is not allowed by Access-Control-Allow-Origin. This is an excerpt my web.xml file for the war: > > CorsFilter > > org.apache.catalina.filters.CorsFilter > > cors.allowed.origins >http://www.domain.com, > http://beta.domain.com:8080, http://localhost:8080 > > > cors.allowed.methods > GET,POST,HEAD,OPTIONS,PUT > > > > > CorsFilter > /api/* > I’d like to debug this, but I don’t know how to go about it. Am I suffering from a basic misunderstanding? Does cors not allow http to https? Anyway, any help would be appreciated. Thanks, Richard
Re: TOMCAT 7 , Native CORS FILTER and Spring Security
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Maatari, On 7/23/15 10:49 AM, Maatari Daniel Okouya wrote: > Hi, > > I am using TOMCAT 7, and I have enable the CORS FILTER as per the > explanation on the official website: > https://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CORS_Filte r > > I use the actual configuration: > > > CorsFilter > org.apache.catalina.filters.CorsFilter > > > cors.allowed.origins > * > cors.allowed.methods > GET,POST,HEAD,OPTIONS,PUT > cors.allowed.headers > Content-Type,X-Requested-With,accept,Origin,Access-Contro l-Request-Method,Access-Control-Request-Headers > > > cors.exposed.headers > Access-Control-Allow-Origin,Access-Control-Allow-Credenti als > > > cors.support.credentials > true > cors.preflight.maxage > 10 > CorsFilter > /* > > I do it in my Web.xml that is in the conf folder. > > However the app that i am trying to access have a spring security > filter. I show below the application configuration in question. I > have no control over that application. In fact this is a vendor > application. I can only modify the configuration file to enable the > CORS FILTER. > > > springSecurityFilterChain > org.springframework.web.filter.DelegatingFilterProxy > > > > springSecurityFilterChain > /* > springSecurityFilterChain > / > > or a larger view > > > MessageFilter > at.punkt.PoolParty.Management.MessageFilter > > > MessageFilter > /* > > TransactionFilter > biz.poolparty.thesaurus.web.support.TransactionFilter > > > TransactionFilter > /* > > SpringLocaleFilter > biz.poolparty.thesaurus.web.support.SpringLocaleFilter > > > SpringLocaleFilter > /* > > > springSecurityFilterChain > org.springframework.web.filter.DelegatingFilterProxy > > > > springSecurityFilterChain > /* > springSecurityFilterChain > / > > ServletContextListener > at.punkt.PoolParty.Management.PoolPartyListener > > > > > contextConfigLocation > classpath:/applicationContext.xml > > > > org.springframework.web.context.ContextLoaderListener< /listener-class> > > > > > dispatcher > org.springframework.web.servlet.DispatcherServlet > > 2 > true > dispatcher > /!/* > dispatcher > /api/* > > > I wonder if there is an issue between the Spring Security Filter > and the Native Cors Filter coming with tomcat ? > > What are the work around ? > > If not how can I know what is exactly stop the CORS FILTER FROM > WORKING RIGHT ? What happens when the filter does not work properly? Does the application break, or do you merely not get any CORS protection. What have you been doing to test? You need to provide more information if we can help you. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVt87nAAoJEBzwKT+lPKRY2NYQAMWT+0tvpB3NxIvT7rS4eqDH uMdZ5hKen1zTUwaR75HpMmOYy1fNieoC4MG5GQluRe9V+hd4nW1FjR3FRUFhlBPC kyfhAmKND7Hc+MO//hwOFxCH0pMAEoeECqjIXdwyHqdMLqDxHKxDir2rlBN8qVJ5 YttStdG1PvuZaarWNavoILHN3ENO273KM1Ujq+UfpKSwU7zFKqRFPa/HdJIx1jnj QOYadkTLejXKAFKXNIaJv1lOy/PF5AH7kNkIqaakRhWfTxddufBY508qkfPF1AKQ wZkRejfq7ARG6z+ygbHYAuc2we3ulfIgDvbYOWQBxHhXaKTH9oP6swmyTV04BWWu wReISXWKDRjAeqNc2v9toiuNJxG9E6tuEuoO1hXOme9iKjZ7+5n/pcupYXy8QaLw hulb0r+Rw8XPE2zwZVPmoJLt3gzVJ9/9Rwy4amagLNd8TT25/0jKD9pyCjb6xVak tIx9hpHocr8UGGooM3YErs0ZIxMJyMaK/Amyu/e/xlkWLocY67f4YbkRCr93OOs+ drJJYTyAy5ScKbK3k3k4Fe7j3+A8Va6W77xP2FLmXLFphAGXTNw0JcqzhyEG7R+v xVaPNlR+GKvuKfp3T7KEXWbNaNUswOWGo9OHpY5Ji/r4otuhtN0c7EwA2qVvZJQ9 dOWlEdHul4YVAO1ISQAV =YuF9 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
TOMCAT 7 , Native CORS FILTER and Spring Security
Hi, I am using TOMCAT 7, and I have enable the CORS FILTER as per the explanation on the official website: https://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CORS_Filter I use the actual configuration: CorsFilter org.apache.catalina.filters.CorsFilter cors.allowed.origins * cors.allowed.methods GET,POST,HEAD,OPTIONS,PUT cors.allowed.headers Content-Type,X-Requested-With,accept,Origin,Access-Control-Request-Method,Access-Control-Request-Headers cors.exposed.headers Access-Control-Allow-Origin,Access-Control-Allow-Credentials cors.support.credentials true cors.preflight.maxage 10 CorsFilter /* I do it in my Web.xml that is in the conf folder. However the app that i am trying to access have a spring security filter. I show below the application configuration in question. I have no control over that application. In fact this is a vendor application. I can only modify the configuration file to enable the CORS FILTER. springSecurityFilterChain org.springframework.web.filter.DelegatingFilterProxy springSecurityFilterChain /* springSecurityFilterChain / or a larger view MessageFilter at.punkt.PoolParty.Management.MessageFilter MessageFilter /* TransactionFilter biz.poolparty.thesaurus.web.support.TransactionFilter TransactionFilter /* SpringLocaleFilter biz.poolparty.thesaurus.web.support.SpringLocaleFilter SpringLocaleFilter /* springSecurityFilterChain org.springframework.web.filter.DelegatingFilterProxy springSecurityFilterChain /* springSecurityFilterChain / ServletContextListener at.punkt.PoolParty.Management.PoolPartyListener contextConfigLocation classpath:/applicationContext.xml org.springframework.web.context.ContextLoaderListener dispatcher org.springframework.web.servlet.DispatcherServlet 2 true dispatcher /!/* dispatcher /api/* I wonder if there is an issue between the Spring Security Filter and the Native Cors Filter coming with tomcat ? What are the work around ? If not how can I know what is exactly stop the CORS FILTER FROM WORKING RIGHT ? -- Maatari Daniel Okouya Sent with Airmail
Fw: TOMCAT 7 , Native CORS FILTER and Spring Security
-- Maatari Daniel Okouya Sent with Airmail On July 23, 2015 at 10:49:19 AM, Maatari Daniel Okouya (okouy...@yahoo.fr) wrote: Hi, I am using TOMCAT 7, and I have enable the CORS FILTER as per the explanation on the official website: https://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CORS_Filter I use the actual configuration: CorsFilter org.apache.catalina.filters.CorsFilter cors.allowed.origins * cors.allowed.methods GET,POST,HEAD,OPTIONS,PUT cors.allowed.headers Content-Type,X-Requested-With,accept,Origin,Access-Control-Request-Method,Access-Control-Request-Headers cors.exposed.headers Access-Control-Allow-Origin,Access-Control-Allow-Credentials cors.support.credentials true cors.preflight.maxage 10 CorsFilter /* I do it in my Web.xml that is in the conf folder. However the app that i am trying to access have a spring security filter. I show below the application configuration in question. I have no control over that application. In fact this is a vendor application. I can only modify the configuration file to enable the CORS FILTER. springSecurityFilterChain org.springframework.web.filter.DelegatingFilterProxy springSecurityFilterChain /* springSecurityFilterChain / or a larger view MessageFilter at.punkt.PoolParty.Management.MessageFilter MessageFilter /* TransactionFilter biz.poolparty.thesaurus.web.support.TransactionFilter TransactionFilter /* SpringLocaleFilter biz.poolparty.thesaurus.web.support.SpringLocaleFilter SpringLocaleFilter /* springSecurityFilterChain org.springframework.web.filter.DelegatingFilterProxy springSecurityFilterChain /* springSecurityFilterChain / ServletContextListener at.punkt.PoolParty.Management.PoolPartyListener contextConfigLocation classpath:/applicationContext.xml org.springframework.web.context.ContextLoaderListener dispatcher org.springframework.web.servlet.DispatcherServlet 2 true dispatcher /!/* dispatcher /api/* I wonder if there is an issue between the Spring Security Filter and the Native Cors Filter coming with tomcat ? What are the work around ? If not how can I know what is exactly stop the CORS FILTER FROM WORKING RIGHT ? -- Maatari Daniel Okouya Sent with Airmail
CORS-Filter for all webapps?
Hi there, I am having issues with Cross-Origin Resource Sharing (CORS). I use Tomcat 7.0.57 with deegree-webservices 3.3.13 on both a Windows Server 2013 and Windows Pro SP1 on my localhost. I have a html with javascript-code and want to send requests with AJAX to a WFS running on the Tomcat Server. I know Tomcat (7.0.57) is able to Filter CORS-Requests and I implemented a Filter in Tomcats web.xml (in Tomcat 7.0/conf/) to allow requests from all Origins. In order to test it I put a test-file in some random Tomcat directories on the server and try to access it from localhost via an AJAX-request in my javascript-code. It Works. But as soon as I make a WFS-request to my deegree-WFS (or even if I just put the test-file in the deegree directory) I can't access it any more. Error: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8080' is therefore not allowed access. The response had HTTP status code 500. What I thought is if I configure the web.xml in Tomcat/conf it should be valid for all webapps and also deegree. Am I wrong? Also if I put the CORS-Filter in Tomcat/webapps/deegree-webservices-3.3.13/web-inf/web.xml it doesn't work. Somebody an idea what I am doing wrong? Cheers Eike
Re: Tomcat CORS Filter: Why is the default list of headers in "Access-Control-Allow-Headers" so arbitrarily limited?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Brian,
On 2/7/15 12:21 PM, Brian wrote:
> Tomcat brings a special filter that implements the CORS
> specification. In this filter, the default list of allowed headers
> is the following:
>
> Origin Accept X-Requested-With Content-Type
> Access-Control-Request-Method Access-Control-Request-Headers
>
>
>
> I know that I can replace that list by using the filter parameter
> "cors.allowed.headers" and specify my own list of headers. I know
> that. But I have the following questions:
>
> - When this filter was created, why was the list filled with this
> -abritrarily- short list of headers? Why these headers and not
> others? Why, for example, isn't the "cache-control" header in the
> list? How was this list chosen?
The W3C CORS "standard" recommendation
(http://www.w3.org/TR/cors/#access-control-allow-headers-response-header)
does not specify which headers should be included by default in this
list. So, it's probably up to the implementer to determine that list.
The author probably wanted to cover the smallest number of low-risk
headers for a default configuration. As you've said, the default can
be overridden. This is a fairly new Filter in Tomcat, so there may
have been some oversights.
The spec mentions "simple headers" of which "Cache-Control" is one. I
haven't read the spec well enough -- nor the code at all -- to know if
those "simple headers" are included by default but not mentioned.
The "cors.exposed.headers" specifically mentions them but
"cors.allowed.headers" does not. I suspect this is accurate, and that
no simple headers are included by default. If you want to add
"Cache-Control" then you should probably add it yourself.
> - If I want to define a more complete list, which headers should I
> include? There are some many headers to think about!
Now you see why the original author might have had a hard time
determining the default list.
> - Can I use a "*" instead of specifying a list? Is that something
> that the CORS specs allows?
This kind of defeats the purpose of the tool in the first place,
doesn't it?
> - I know that the CORS specs defined this kind of list, but. Why is
> that necessary? Why can't we just accept any header in the
> pre-flight OPTIONS step, instead of returning a 403 (Forbiden) if
> at least one of the headers requested by the client is not in the
> list of allowed headers?
You certainly /can/ do that, but then you remove a layer of security
that the tool is supposed to provide.
> - Why isn't there an option in the filter to do something like
> this:
>
> response.setHeader("Access-Control-Allow-Headers",
> request.getHeader("Access-Control-Request-Headers")?
This would accept anything the client sent (which, of course, is what
you're asking about). "Custom headers" are a potential attack vector
and part of the reason that header white-listing is a part of the CORS
spec.
> I'm puzzled. One of the users of my API sent the "cache-control"
> header in the in the "Access-Control-Request-Headers" list during
> the pre-flight step, and received an HTTP 403 error status. I can
> add this header to the list (using the "cors.allowed.headers"
> filter parameter). But what about next time some client sends
> another header that is not in the list?
It sounds like you need to listen to to the needs of your customers
and adapt to them. You can either say "sure, we'll white-list that
header" or "sorry, you'll have to remove that header from your request
because we see it as a security issue".
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJU2MlHAAoJEBzwKT+lPKRYmxUQAK+cIucZ3jodP5wBvZugLz0m
iO2jDNDVz1KVJwDqsmtOaXQSFuGOsguUkyhbSW0RY4WMAbh4YellXDaXCC6zw02Q
vKzPJewvOyvmfN7Jztk2vmqfu0+ETFW6aVfWFz+azwUdzKv06Bs+rOlKgvbrtrtN
+hBqkFpZTMjDA77oc2i93fqv3GX8+Qy+XcaE0tMnULxcsLSoQzVJ6x03XyCvEpMX
v8SLWo12mUYio7VNBY56CeqxG+hCE9vY1hBVjzBM9kEzXe/YM/iOJAiocoScKcUn
8I1LA6kyCXYZM3ubYfaUV/jS0ebGXkeOyePuX1js1YC9vdgapzckwXNg1flUYs7i
9pbetj0n9E590eDaz3j6VaTchWf+RYL92CejU51g9/lvGN4whhAdFmehlV+TNJy/
gW95q2uY7SiU2ORepMKWI9zSQwFGDl+ve80jhupB4fg/xjk/cioe/VJQuazReyOj
JugpKH0Z3XjPXV5V2DneucvEhYyVtUqMqtTh7FPrZQL4xgGLslSDZSJHb2EDnyHt
7QqGU+2jhW5X0oxY6iFVBYgv2OX++ulAUcr14KH6vXfHLl4e8uCq0EuS9zXj29Ox
+bi3SBu3z62cLLV/gefzMjH3hmw+a0+f5/+xKc48aKADwat1W1051GjzWr+ErKOF
h1XH5OossOmsBCChwQcs
=Ok7B
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat CORS Filter: Why is the default list of headers in "Access-Control-Allow-Headers" so arbitrarily limited?
Hi,
Tomcat brings a special filter that implements the CORS specification. In
this filter, the default list of allowed headers is the following:
Origin
Accept
X-Requested-With
Content-Type
Access-Control-Request-Method
Access-Control-Request-Headers
I know that I can replace that list by using the filter parameter
"cors.allowed.headers" and specify my own list of headers. I know that. But
I have the following questions:
- When this filter was created, why was the list filled with this
-abritrarily- short list of headers? Why these headers and not others? Why,
for example, isn't the "cache-control" header in the list? How was this list
chosen?
- If I want to define a more complete list, which headers should I include?
There are some many headers to think about!
- Can I use a "*" instead of specifying a list? Is that something that the
CORS specs allows?
- I know that the CORS specs defined this kind of list, but. Why is that
necessary? Why can't we just accept any header in the pre-flight OPTIONS
step, instead of returning a 403 (Forbiden) if at least one of the headers
requested by the client is not in the list of allowed headers?
- Why isn't there an option in the filter to do something like this:
response.setHeader("Access-Control-Allow-Headers",
request.getHeader("Access-Control-Request-Headers") ?
I'm puzzled. One of the users of my API sent the "cache-control" header in
the in the "Access-Control-Request-Headers" list during the pre-flight
step, and received an HTTP 403 error status. I can add this header to the
list (using the "cors.allowed.headers" filter parameter). But what about
next time some client sends another header that is not in the list?
Brian
