Re: Adding regular expression support to CORS filter

2020-10-06 Thread Carsten Klein

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

2020-09-27 Thread Christopher Schultz
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

2020-09-27 Thread Carsten Klein

Any comments on that? Is it worth preparing a PR?


Adding regular expression support to CORS filter

2020-09-21 Thread Carsten Klein

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

2018-07-31 Thread Luis Rodríguez Fernández
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

2018-07-28 Thread 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

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

2018-06-20 Thread Bradley, Richard
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

2018-06-20 Thread Mark Thomas
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

2018-06-20 Thread Bradley, Richard
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

2018-05-16 Thread Mark Thomas
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

2016-08-19 Thread Chandrashekar H . S
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

2016-02-26 Thread RICHARD DOUST

> 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

2016-02-26 Thread Christopher Schultz
-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 Thread Jose María Zaragoza
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

2016-02-26 Thread tomcat

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

2016-02-26 Thread RICHARD DOUST
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

2016-02-25 Thread tomcat

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

2016-02-25 Thread RICHARD DOUST
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

2015-07-28 Thread Christopher Schultz
-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

2015-07-23 Thread Maatari Daniel Okouya
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

2015-07-23 Thread Maatari Daniel Okouya

-- 
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?

2015-02-24 Thread Geod Master
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?

2015-02-09 Thread Christopher Schultz
-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?

2015-02-07 Thread Brian
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