Re: CORS issue with Tomcat and Android Webview

[Terence M. Bandoian]

On 4/28/2014 3:21 PM, Konstantin Kolinko wrote:

2014-04-28 23:44 GMT+04:00 Terence M. Bandoian :

On 4/27/2014 11:36 AM, Konstantin Kolinko wrote:

2014-04-27 0:50 GMT+04:00 Terence M. Bandoian :

On 4/26/2014 1:13 AM, Ankit Singhal wrote:

On Sat, Apr 26, 2014 at 12:53 AM, Terence M. Bandoian

Hi, Ankit-

Where did you see  documented?  I see an 
named
cors.allowed.origins on the Tomcat web site:

https://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CORS_Filter

In any case, I agree that if allowed origins is set to "*", all CORS
requests should be allowed.  As I understand it, the W3C spec only
requires
that the Origin header exists:

http://www.w3.org/TR/cors/#resource-processing-model

It also states that it is acceptable for Origin headers to always match
the
list of allowed origins when the list is "unbounded".


1. From a quick reading, I do not see any syntax for that lists
besides exact case-sensitive matches.

http://tools.ietf.org/html/rfc6454#section-7
says that the syntax of origin header is

 serialized-origin   = scheme "://" host [ ":" port ]
 ; , ,  from RFC 3986

Nothing says that "host" can be omitted.

http://tools.ietf.org/html/rfc6454#section-6.1
Per Sections 6.1 and 6.2 the correct serialized value of such
"file://" origin will be "null".

2. Some form of sanity check must be present,
because the origin header value is sent back to client and as such can
be abused.

3. That said,
I think that CorsFilter.isValidOrigin(String) can be patched to
a) Be more strict to the specified syntax  (and not just allow any URI)
(Not actually necessary, but it will allow to reject non-conforming
clients).

b) Specifically white-list the "null" origin.

c) Specifically white-list a "file://" origin,  with notion that that
is a bug in certain Android versions


Maybe this is a good case to submit a bug report or a patch.

Agreed.

Best regards,
Konstantin Kolinko



Hi, Konstantin-

I agree there is value in validating the origin header value and with your
interpretation of the IETF origin header specification.  I was referring to:

 http://www.w3.org/TR/cors/#resource-requests

which includes:

 1. If the Origin header is not present terminate this set of steps. The
request is outside the scope of this specification.

 2. If the value of the Origin header is not a case-sensitive match for
any of the values in list of origins, do not set any additional headers and
terminate this set of steps.

 Note: Always matching is acceptable since the list of origins can be
unbounded.

The solution you propose makes sense to me and I think will work although
I'm a little unclear about a).  Do you mean adding a test for a null host
value?

In a) I meant that  on Origin header is either "null" (4 characters literally),
or  "scheme "://" host [ ":" port ]".

It is not an URI. So in theory the check can be more strict, that
there is no "path", "query", "anchor" or whatever additional URI
components can be there.

(Though I see no real worth in being that strict. A small worth is to
encourage clients to behave correctly, if there are some misbehaving
ones).

Best regards,
Konstantin Kolinko



One alternative solution might be to reduce origin header validation to 
checking for invalid characters only. It may be a little sloppy but 
would eliminate the need to add to a hardcoded whitelist for every 
client that doesn't comply with the origin header spec.


Another would be to add a cors.allowed.invalidorigins initialization 
parameter. This would allow for strict validation of origin headers with 
configurable whitelisting of invalid values.


-Terence Bandoian

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: CORS issue with Tomcat and Android Webview

[Terence M. Bandoian]

On 4/29/2014 3:48 AM, Jose María Zaragoza wrote:

2014-04-29 0:38 GMT+02:00 Terence M. Bandoian :

On 4/28/2014 5:32 PM, Terence M. Bandoian wrote:

On 4/28/2014 3:08 PM, Jose María Zaragoza wrote:

2014-04-28 21:55 GMT+02:00 Terence M. Bandoian :

On 4/26/2014 6:56 AM, Jose María Zaragoza wrote:

2014-04-26 13:16 GMT+02:00 Martin Gainty :

Date: Sat, 26 Apr 2014 11:43:05 +0530
Subject: Re: CORS issue with Tomcat and Android Webview
From: ankising...@gmail.com
To: users@tomcat.apache.org

On Sat, Apr 26, 2014 at 12:53 AM, Terence M. Bandoian
wrote:


On 4/24/2014 11:16 PM, Ankit Singhal wrote:


Hi

I did more research on this and figure out the issue.If you see the
headers
from Android and look into Origin Header.

Origin: file://

Tomcat CORS filter tries to validate the URI in Origin header and
considers
"file://" as an invalid URI and returns back 403.

I have applied * params. So
shouldn't
CORS
filter honor this ?

I agree that Client also has the problem , but still server should
also
allow...


Hi:

I'm watching this flowchart
https://tomcat.apache.org/tomcat-7.0-doc/images/cors-flowchart.png

and I wonder if Tomcat 7 checks if the request received belongs to the
right type.
I mean, if browser sends a simple request ( eg. POST + application/xml
content-type header )
WC3 spec says that request should be a preflight request  , does
Tomcat check this case ?



Regards


Hi, Jose-

I don't see where the W3C spec requires a preflight request for simple
requests.


-Terence Bandoian


Sorry, I meant non-simple request.
For example, if I perform a cross-domain POST request (within
application/xml content-type header ),
I guess that a preflight request is required , right ?
What happens, if it's not sent , on Tomcat? Should it check it ?

Regards



Hi, Jose-

I don't see in the W3C spec where preflight requests are required at all.
Can you point me to where you've found that?

-Terence Bandoian



I meant to say I don't see where the W3C spec requires preflight requests to
be sent.

According to

http://www.w3.org/TR/cors/#simple-cross-origin-request
Cross-Origin Request with Preflight
[
Go to the next step if the following conditions are true. *Otherwise,
make a preflight request.*

- For request method there either is a method cache match or it is a
simple method and the force preflight flag is unset.
- For every header of author request headers there either is a header
cache match for the field name or it is a simple header.
/]

So, I understand that if I make a POST request within application/xml
content-type header, it's a simple method but Content-type:
application/xml is not a simple header, according to
http://www.w3.org/TR/cors/#simple-method
I understand that client must to make a preflight request

Maybe I'm wrong


Regards



Hi, Jose,

I see that now but the logic behind it is a little confusing.  In 
particular, the following sentence at the beginning of the section you 
referenced is not clear to me:


"To protect resources against cross-origin requests that could not 
originate from certain user agents before this specification existed a 
preflight request is made to ensure that the resource is aware of this 
specification."


Are servers required to perform any actions related to preflight 
requests other than responding appropriately to them?


-Terence Bandoian


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: CORS issue with Tomcat and Android Webview

[Jose María Zaragoza]

2014-04-29 0:38 GMT+02:00 Terence M. Bandoian :
> On 4/28/2014 5:32 PM, Terence M. Bandoian wrote:
>>
>> On 4/28/2014 3:08 PM, Jose María Zaragoza wrote:
>>>
>>> 2014-04-28 21:55 GMT+02:00 Terence M. Bandoian :
>>>>
>>>> On 4/26/2014 6:56 AM, Jose María Zaragoza wrote:
>>>>>
>>>>> 2014-04-26 13:16 GMT+02:00 Martin Gainty :
>>>>>>>
>>>>>>> Date: Sat, 26 Apr 2014 11:43:05 +0530
>>>>>>> Subject: Re: CORS issue with Tomcat and Android Webview
>>>>>>> From: ankising...@gmail.com
>>>>>>> To: users@tomcat.apache.org
>>>>>>>
>>>>>>> On Sat, Apr 26, 2014 at 12:53 AM, Terence M. Bandoian
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On 4/24/2014 11:16 PM, Ankit Singhal wrote:
>>>>>>>>
>>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>> I did more research on this and figure out the issue.If you see the
>>>>>>>>> headers
>>>>>>>>> from Android and look into Origin Header.
>>>>>>>>>
>>>>>>>>> Origin: file://
>>>>>>>>>
>>>>>>>>> Tomcat CORS filter tries to validate the URI in Origin header and
>>>>>>>>> considers
>>>>>>>>> "file://" as an invalid URI and returns back 403.
>>>>>>>>>
>>>>>>>>> I have applied * params. So
>>>>>>>>> shouldn't
>>>>>>>>> CORS
>>>>>>>>> filter honor this ?
>>>>>>>>>
>>>>>>>>> I agree that Client also has the problem , but still server should
>>>>>>>>> also
>>>>>>>>> allow...
>>>>>>>>>
>>>>> Hi:
>>>>>
>>>>> I'm watching this flowchart
>>>>> https://tomcat.apache.org/tomcat-7.0-doc/images/cors-flowchart.png
>>>>>
>>>>> and I wonder if Tomcat 7 checks if the request received belongs to the
>>>>> right type.
>>>>> I mean, if browser sends a simple request ( eg. POST + application/xml
>>>>> content-type header )
>>>>> WC3 spec says that request should be a preflight request  , does
>>>>> Tomcat check this case ?
>>>>>
>>>>>
>>>>>
>>>>> Regards
>>>>>
>>>>
>>>> Hi, Jose-
>>>>
>>>> I don't see where the W3C spec requires a preflight request for simple
>>>> requests.
>>>>
>>>>
>>>> -Terence Bandoian
>>>
>>>
>>> Sorry, I meant non-simple request.
>>> For example, if I perform a cross-domain POST request (within
>>> application/xml content-type header ),
>>> I guess that a preflight request is required , right ?
>>> What happens, if it's not sent , on Tomcat? Should it check it ?
>>>
>>> Regards
>>
>>
>>
>> Hi, Jose-
>>
>> I don't see in the W3C spec where preflight requests are required at all.
>> Can you point me to where you've found that?
>>
>> -Terence Bandoian
>>
>
>
> I meant to say I don't see where the W3C spec requires preflight requests to
> be sent.

According to

http://www.w3.org/TR/cors/#simple-cross-origin-request
Cross-Origin Request with Preflight
[
Go to the next step if the following conditions are true. *Otherwise,
make a preflight request.*

- For request method there either is a method cache match or it is a
simple method and the force preflight flag is unset.
- For every header of author request headers there either is a header
cache match for the field name or it is a simple header.
/]

So, I understand that if I make a POST request within application/xml
content-type header, it's a simple method but Content-type:
application/xml is not a simple header, according to
http://www.w3.org/TR/cors/#simple-method
I understand that client must to make a preflight request

Maybe I'm wrong


Regards




















>
> -Terence
>
>
>
> -
> 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 issue with Tomcat and Android Webview

[Terence M. Bandoian]

On 4/28/2014 5:32 PM, Terence M. Bandoian wrote:

On 4/28/2014 3:08 PM, Jose María Zaragoza wrote:

2014-04-28 21:55 GMT+02:00 Terence M. Bandoian :

On 4/26/2014 6:56 AM, Jose María Zaragoza wrote:

2014-04-26 13:16 GMT+02:00 Martin Gainty :

Date: Sat, 26 Apr 2014 11:43:05 +0530
Subject: Re: CORS issue with Tomcat and Android Webview
From: ankising...@gmail.com
To: users@tomcat.apache.org

On Sat, Apr 26, 2014 at 12:53 AM, Terence M. Bandoian
wrote:


On 4/24/2014 11:16 PM, Ankit Singhal wrote:


Hi

I did more research on this and figure out the issue.If you see 
the

headers
from Android and look into Origin Header.

Origin: file://

Tomcat CORS filter tries to validate the URI in Origin header and
considers
"file://" as an invalid URI and returns back 403.

I have applied * params. So 
shouldn't

CORS
filter honor this ?

I agree that Client also has the problem , but still server should
also
allow...


Hi:

I'm watching this flowchart
https://tomcat.apache.org/tomcat-7.0-doc/images/cors-flowchart.png

and I wonder if Tomcat 7 checks if the request received belongs to the
right type.
I mean, if browser sends a simple request ( eg. POST + application/xml
content-type header )
WC3 spec says that request should be a preflight request  , does
Tomcat check this case ?



Regards



Hi, Jose-

I don't see where the W3C spec requires a preflight request for simple
requests.


-Terence Bandoian


Sorry, I meant non-simple request.
For example, if I perform a cross-domain POST request (within
application/xml content-type header ),
I guess that a preflight request is required , right ?
What happens, if it's not sent , on Tomcat? Should it check it ?

Regards



Hi, Jose-

I don't see in the W3C spec where preflight requests are required at 
all.  Can you point me to where you've found that?


-Terence Bandoian




I meant to say I don't see where the W3C spec requires preflight 
requests to be sent.


-Terence


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: CORS issue with Tomcat and Android Webview

[Terence M. Bandoian]

On 4/28/2014 3:08 PM, Jose María Zaragoza wrote:

2014-04-28 21:55 GMT+02:00 Terence M. Bandoian :

On 4/26/2014 6:56 AM, Jose María Zaragoza wrote:

2014-04-26 13:16 GMT+02:00 Martin Gainty :

Date: Sat, 26 Apr 2014 11:43:05 +0530
Subject: Re: CORS issue with Tomcat and Android Webview
From: ankising...@gmail.com
To: users@tomcat.apache.org

On Sat, Apr 26, 2014 at 12:53 AM, Terence M. Bandoian
wrote:


On 4/24/2014 11:16 PM, Ankit Singhal wrote:


Hi

I did more research on this and figure out the issue.If you see the
headers
from Android and look into Origin Header.

Origin: file://

Tomcat CORS filter tries to validate the URI in Origin header and
considers
"file://" as an invalid URI and returns back 403.

I have applied * params. So shouldn't
CORS
filter honor this ?

I agree that Client also has the problem , but still server should
also
allow...


Hi:

I'm watching this flowchart
https://tomcat.apache.org/tomcat-7.0-doc/images/cors-flowchart.png

and I wonder if Tomcat 7 checks if the request received belongs to the
right type.
I mean, if browser sends a simple request ( eg. POST + application/xml
content-type header )
WC3 spec says that request should be a preflight request  , does
Tomcat check this case ?



Regards



Hi, Jose-

I don't see where the W3C spec requires a preflight request for simple
requests.


-Terence Bandoian


Sorry, I meant non-simple request.
For example, if I perform a cross-domain POST request (within
application/xml content-type header ),
I guess that a preflight request is required , right ?
What happens, if it's not sent , on Tomcat? Should it check it ?

Regards



Hi, Jose-

I don't see in the W3C spec where preflight requests are required at 
all.  Can you point me to where you've found that?


-Terence Bandoian


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: CORS issue with Tomcat and Android Webview

[Terence M. Bandoian]

On 4/28/2014 3:21 PM, Konstantin Kolinko wrote:

2014-04-28 23:44 GMT+04:00 Terence M. Bandoian :

On 4/27/2014 11:36 AM, Konstantin Kolinko wrote:

2014-04-27 0:50 GMT+04:00 Terence M. Bandoian :

On 4/26/2014 1:13 AM, Ankit Singhal wrote:

On Sat, Apr 26, 2014 at 12:53 AM, Terence M. Bandoian

Hi, Ankit-

Where did you see  documented?  I see an 
named
cors.allowed.origins on the Tomcat web site:

https://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CORS_Filter

In any case, I agree that if allowed origins is set to "*", all CORS
requests should be allowed.  As I understand it, the W3C spec only
requires
that the Origin header exists:

http://www.w3.org/TR/cors/#resource-processing-model

It also states that it is acceptable for Origin headers to always match
the
list of allowed origins when the list is "unbounded".


1. From a quick reading, I do not see any syntax for that lists
besides exact case-sensitive matches.

http://tools.ietf.org/html/rfc6454#section-7
says that the syntax of origin header is

 serialized-origin   = scheme "://" host [ ":" port ]
 ; , ,  from RFC 3986

Nothing says that "host" can be omitted.

http://tools.ietf.org/html/rfc6454#section-6.1
Per Sections 6.1 and 6.2 the correct serialized value of such
"file://" origin will be "null".

2. Some form of sanity check must be present,
because the origin header value is sent back to client and as such can
be abused.

3. That said,
I think that CorsFilter.isValidOrigin(String) can be patched to
a) Be more strict to the specified syntax  (and not just allow any URI)
(Not actually necessary, but it will allow to reject non-conforming
clients).

b) Specifically white-list the "null" origin.

c) Specifically white-list a "file://" origin,  with notion that that
is a bug in certain Android versions


Maybe this is a good case to submit a bug report or a patch.

Agreed.

Best regards,
Konstantin Kolinko



Hi, Konstantin-

I agree there is value in validating the origin header value and with your
interpretation of the IETF origin header specification.  I was referring to:

 http://www.w3.org/TR/cors/#resource-requests

which includes:

 1. If the Origin header is not present terminate this set of steps. The
request is outside the scope of this specification.

 2. If the value of the Origin header is not a case-sensitive match for
any of the values in list of origins, do not set any additional headers and
terminate this set of steps.

 Note: Always matching is acceptable since the list of origins can be
unbounded.

The solution you propose makes sense to me and I think will work although
I'm a little unclear about a).  Do you mean adding a test for a null host
value?

In a) I meant that  on Origin header is either "null" (4 characters literally),
or  "scheme "://" host [ ":" port ]".

It is not an URI. So in theory the check can be more strict, that
there is no "path", "query", "anchor" or whatever additional URI
components can be there.

(Though I see no real worth in being that strict. A small worth is to
encourage clients to behave correctly, if there are some misbehaving
ones).

Best regards,
Konstantin Kolinko



Ahh.  Makes sense.  Thanks for the clarification.

-Terence Bandoian


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: CORS issue with Tomcat and Android Webview

[Konstantin Kolinko]

2014-04-28 23:44 GMT+04:00 Terence M. Bandoian :
> On 4/27/2014 11:36 AM, Konstantin Kolinko wrote:
>>
>> 2014-04-27 0:50 GMT+04:00 Terence M. Bandoian :
>>>
>>> On 4/26/2014 1:13 AM, Ankit Singhal wrote:

 On Sat, Apr 26, 2014 at 12:53 AM, Terence M. Bandoian
>>>
>>> Hi, Ankit-
>>>
>>> Where did you see  documented?  I see an 
>>> named
>>> cors.allowed.origins on the Tomcat web site:
>>>
>>> https://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CORS_Filter
>>>
>>> In any case, I agree that if allowed origins is set to "*", all CORS
>>> requests should be allowed.  As I understand it, the W3C spec only
>>> requires
>>> that the Origin header exists:
>>>
>>> http://www.w3.org/TR/cors/#resource-processing-model
>>>
>>> It also states that it is acceptable for Origin headers to always match
>>> the
>>> list of allowed origins when the list is "unbounded".
>>>
>> 1. From a quick reading, I do not see any syntax for that lists
>> besides exact case-sensitive matches.
>>
>> http://tools.ietf.org/html/rfc6454#section-7
>> says that the syntax of origin header is
>>
>> serialized-origin   = scheme "://" host [ ":" port ]
>> ; , ,  from RFC 3986
>>
>> Nothing says that "host" can be omitted.
>>
>> http://tools.ietf.org/html/rfc6454#section-6.1
>> Per Sections 6.1 and 6.2 the correct serialized value of such
>> "file://" origin will be "null".
>>
>> 2. Some form of sanity check must be present,
>> because the origin header value is sent back to client and as such can
>> be abused.
>>
>> 3. That said,
>> I think that CorsFilter.isValidOrigin(String) can be patched to
>> a) Be more strict to the specified syntax  (and not just allow any URI)
>> (Not actually necessary, but it will allow to reject non-conforming
>> clients).
>>
>> b) Specifically white-list the "null" origin.
>>
>> c) Specifically white-list a "file://" origin,  with notion that that
>> is a bug in certain Android versions
>>
>>> Maybe this is a good case to submit a bug report or a patch.
>>
>> Agreed.
>>
>> Best regards,
>> Konstantin Kolinko
>>
>
>
> Hi, Konstantin-
>
> I agree there is value in validating the origin header value and with your
> interpretation of the IETF origin header specification.  I was referring to:
>
> http://www.w3.org/TR/cors/#resource-requests
>
> which includes:
>
> 1. If the Origin header is not present terminate this set of steps. The
> request is outside the scope of this specification.
>
> 2. If the value of the Origin header is not a case-sensitive match for
> any of the values in list of origins, do not set any additional headers and
> terminate this set of steps.
>
> Note: Always matching is acceptable since the list of origins can be
> unbounded.
>
> The solution you propose makes sense to me and I think will work although
> I'm a little unclear about a).  Do you mean adding a test for a null host
> value?

In a) I meant that  on Origin header is either "null" (4 characters literally),
or  "scheme "://" host [ ":" port ]".

It is not an URI. So in theory the check can be more strict, that
there is no "path", "query", "anchor" or whatever additional URI
components can be there.

(Though I see no real worth in being that strict. A small worth is to
encourage clients to behave correctly, if there are some misbehaving
ones).

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: CORS issue with Tomcat and Android Webview

[Jose María Zaragoza]

2014-04-28 21:55 GMT+02:00 Terence M. Bandoian :
> On 4/26/2014 6:56 AM, Jose María Zaragoza wrote:
>>
>> 2014-04-26 13:16 GMT+02:00 Martin Gainty :
>>>>
>>>> Date: Sat, 26 Apr 2014 11:43:05 +0530
>>>> Subject: Re: CORS issue with Tomcat and Android Webview
>>>> From: ankising...@gmail.com
>>>> To: users@tomcat.apache.org
>>>>
>>>> On Sat, Apr 26, 2014 at 12:53 AM, Terence M. Bandoian
>>>> wrote:
>>>>
>>>>> On 4/24/2014 11:16 PM, Ankit Singhal wrote:
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> I did more research on this and figure out the issue.If you see the
>>>>>> headers
>>>>>> from Android and look into Origin Header.
>>>>>>
>>>>>> Origin: file://
>>>>>>
>>>>>> Tomcat CORS filter tries to validate the URI in Origin header and
>>>>>> considers
>>>>>> "file://" as an invalid URI and returns back 403.
>>>>>>
>>>>>> I have applied * params. So shouldn't
>>>>>> CORS
>>>>>> filter honor this ?
>>>>>>
>>>>>> I agree that Client also has the problem , but still server should
>>>>>> also
>>>>>> allow...
>>>>>>
>> Hi:
>>
>> I'm watching this flowchart
>> https://tomcat.apache.org/tomcat-7.0-doc/images/cors-flowchart.png
>>
>> and I wonder if Tomcat 7 checks if the request received belongs to the
>> right type.
>> I mean, if browser sends a simple request ( eg. POST + application/xml
>> content-type header )
>> WC3 spec says that request should be a preflight request  , does
>> Tomcat check this case ?
>>
>>
>>
>> Regards
>>
>
>
> Hi, Jose-
>
> I don't see where the W3C spec requires a preflight request for simple
> requests.
>
>
> -Terence Bandoian


Sorry, I meant non-simple request.
For example, if I perform a cross-domain POST request (within
application/xml content-type header ),
I guess that a preflight request is required , right ?
What happens, if it's not sent , on Tomcat? Should it check it ?

Regards










>
>
> -
> 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 issue with Tomcat and Android Webview

[Terence M. Bandoian]

On 4/26/2014 6:56 AM, Jose María Zaragoza wrote:

2014-04-26 13:16 GMT+02:00 Martin Gainty :

Date: Sat, 26 Apr 2014 11:43:05 +0530
Subject: Re: CORS issue with Tomcat and Android Webview
From: ankising...@gmail.com
To: users@tomcat.apache.org

On Sat, Apr 26, 2014 at 12:53 AM, Terence M. Bandoian wrote:


On 4/24/2014 11:16 PM, Ankit Singhal wrote:


Hi

I did more research on this and figure out the issue.If you see the
headers
from Android and look into Origin Header.

Origin: file://

Tomcat CORS filter tries to validate the URI in Origin header and
considers
"file://" as an invalid URI and returns back 403.

I have applied * params. So shouldn't CORS
filter honor this ?

I agree that Client also has the problem , but still server should also
allow...


Hi:

I'm watching this flowchart
https://tomcat.apache.org/tomcat-7.0-doc/images/cors-flowchart.png

and I wonder if Tomcat 7 checks if the request received belongs to the
right type.
I mean, if browser sends a simple request ( eg. POST + application/xml
content-type header )
WC3 spec says that request should be a preflight request  , does
Tomcat check this case ?



Regards




Hi, Jose-

I don't see where the W3C spec requires a preflight request for simple 
requests.


-Terence Bandoian


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: CORS issue with Tomcat and Android Webview

[Terence M. Bandoian]

On 4/27/2014 11:36 AM, Konstantin Kolinko wrote:

2014-04-27 0:50 GMT+04:00 Terence M. Bandoian :

On 4/26/2014 1:13 AM, Ankit Singhal wrote:

On Sat, Apr 26, 2014 at 12:53 AM, Terence M. Bandoian

Hi, Ankit-

Where did you see  documented?  I see an  named
cors.allowed.origins on the Tomcat web site:

https://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CORS_Filter

In any case, I agree that if allowed origins is set to "*", all CORS
requests should be allowed.  As I understand it, the W3C spec only requires
that the Origin header exists:

http://www.w3.org/TR/cors/#resource-processing-model

It also states that it is acceptable for Origin headers to always match the
list of allowed origins when the list is "unbounded".


1. From a quick reading, I do not see any syntax for that lists
besides exact case-sensitive matches.

http://tools.ietf.org/html/rfc6454#section-7
says that the syntax of origin header is

serialized-origin   = scheme "://" host [ ":" port ]
; , ,  from RFC 3986

Nothing says that "host" can be omitted.

http://tools.ietf.org/html/rfc6454#section-6.1
Per Sections 6.1 and 6.2 the correct serialized value of such
"file://" origin will be "null".

2. Some form of sanity check must be present,
because the origin header value is sent back to client and as such can
be abused.

3. That said,
I think that CorsFilter.isValidOrigin(String) can be patched to
a) Be more strict to the specified syntax  (and not just allow any URI)
(Not actually necessary, but it will allow to reject non-conforming clients).

b) Specifically white-list the "null" origin.

c) Specifically white-list a "file://" origin,  with notion that that
is a bug in certain Android versions


Maybe this is a good case to submit a bug report or a patch.

Agreed.

Best regards,
Konstantin Kolinko




Hi, Konstantin-

I agree there is value in validating the origin header value and with 
your interpretation of the IETF origin header specification.  I was 
referring to:


http://www.w3.org/TR/cors/#resource-requests

which includes:

1. If the Origin header is not present terminate this set of steps. 
The request is outside the scope of this specification.


2. If the value of the Origin header is not a case-sensitive match 
for any of the values in list of origins, do not set any additional 
headers and terminate this set of steps.


Note: Always matching is acceptable since the list of origins 
can be unbounded.


The solution you propose makes sense to me and I think will work 
although I'm a little unclear about a).  Do you mean adding a test for a 
null host value?


-Terence Bandoian

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: CORS issue with Tomcat and Android Webview

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Konstantin,

On 4/27/14, 12:36 PM, Konstantin Kolinko wrote:
> 2014-04-27 0:50 GMT+04:00 Terence M. Bandoian :
>> On 4/26/2014 1:13 AM, Ankit Singhal wrote:
>>> 
>>> On Sat, Apr 26, 2014 at 12:53 AM, Terence M. Bandoian
>> Hi, Ankit-
>> 
>> Where did you see  documented?  I see an
>>  named cors.allowed.origins on the Tomcat web site:
>> 
>> https://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CORS_Filter
>>
>>
>> 
In any case, I agree that if allowed origins is set to "*", all CORS
>> requests should be allowed.  As I understand it, the W3C spec
>> only requires that the Origin header exists:
>> 
>> http://www.w3.org/TR/cors/#resource-processing-model
>> 
>> It also states that it is acceptable for Origin headers to always
>> match the list of allowed origins when the list is "unbounded".
>> 
> 
> 1. From a quick reading, I do not see any syntax for that lists 
> besides exact case-sensitive matches.
> 
> http://tools.ietf.org/html/rfc6454#section-7 says that the syntax
> of origin header is
> 
> serialized-origin   = scheme "://" host [ ":" port ] ; ,
> ,  from RFC 3986
> 
> Nothing says that "host" can be omitted.

RFC 3986 (URI Syntax) says that "host" can be a few things, including
a re-name, which is defined as:

   reg-name= *( unreserved / pct-encoded / sub-delims )

Technically, this allows host names of zero-length. So,
Origin=file:/// is legal, if not still problematic.

> http://tools.ietf.org/html/rfc6454#section-6.1 Per Sections 6.1 and
> 6.2 the correct serialized value of such "file://" origin will be
> "null".

Section 6.1.1. could be interpreted to mean that a zero-length host
still implies a "scheme/host/port triple". Perhaps that is how Google
is interpreting it in this case.

> 2. Some form of sanity check must be present, because the origin
> header value is sent back to client and as such can be abused.

+1

Use of file:// URLs for CORS seems like a bad idea upon initial
consideration. It basically lets you avoid all of the constraints.

> 3. That said, I think that CorsFilter.isValidOrigin(String) can be
> patched to a) Be more strict to the specified syntax  (and not just
> allow any URI) (Not actually necessary, but it will allow to reject
> non-conforming clients).

The current implementation uses "new URI(String)" to perform a sanity
check against the Origin header value. That constructor is documented
to specifically reject "file:///" because it does not contain a path
component (or, rather, there is no non-zero-length path component).
Thus, file:/// can't work with Tomcat's current implementation.

Thanks, Ankit, for pointing that out. I had only been looking at the
methods called later in the process.

> b) Specifically white-list the "null" origin.
> 
> c) Specifically white-list a "file://" origin,  with notion that
> that is a bug in certain Android versions

+1, though I would probably favor an implementation where file://(/)?
(and/or null) needs to be explicitly-specified in addition to "*" just
so the user is entirely clear about allowing these particular origins.

There also appears to be an unimplemented spec case where the client
sends multiple origin headers. I'm not sure how common that is.

>> Maybe this is a good case to submit a bug report or a patch.
> 
> Agreed.

+1

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJTXlG6AAoJEBzwKT+lPKRYJEsP/0U6cvjjjVoEHsf1HOKDQkZH
N76/tfgKtk7krvxod1eImGHSLNladu9LS9rpqEjRs0ZBXKSi2Hk+xOKlE6ZDO0hr
ZTQuWL/NG3VJTTS+RH/KCCGNeP/rmnX/bhB4NsJfnCoUuxHj8ajEdZfbbUKbDUST
8O0x+Lx8QYDdqnbJWWyLFrD26vCVdvaPoTbmM3r6mpZubm2/xa7Zt4yAHsELrUMf
J9WH1OtVpn+jCzJ1129oR5CLCFhN6rm9xZrIXsVIEapjKf0GR9RWcqMyhyk63l5t
R8Nb0yOamQSFdg86WtO2+S6x064XVvh/pIdvnXUA3XV8fe8rfdUKz+U6smZyBn78
Etl09X4zwONnslBqm+ZhTzxQ710Y5iLlxLOo/RjZt0TOcu7s7XtmbaZgNDmunLDu
wCgDE/GCaBO0bxRe5UlDoRux7ICz5Ju1Pp4XfN888SMDUIlrjq7BbtsINons+XmH
eZHofi51QnZKQvbm72qe+pJSlyWByZzJQtzWOdXj8DFmn/OzF8dqs701Jv/KgqTI
dXQSalNGOgBqKkoOCEJp424A7N5v2PaI0MvEKo9AnlqF6+mRn6XkEAKvkzL2Hry6
dq6JIwBWT8G1PmiQbVTM7jF2GdHWY9RpnC/QrMn41aiFENYRFf2HLJqCGjB+Lepj
zEg0+5+SZRV1C8TgXsb+
=IqBI
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: CORS issue with Tomcat and Android Webview

[Konstantin Kolinko]

2014-04-27 0:50 GMT+04:00 Terence M. Bandoian :
> On 4/26/2014 1:13 AM, Ankit Singhal wrote:
>>
>> On Sat, Apr 26, 2014 at 12:53 AM, Terence M. Bandoian
> Hi, Ankit-
>
> Where did you see  documented?  I see an  named
> cors.allowed.origins on the Tomcat web site:
>
> https://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CORS_Filter
>
> In any case, I agree that if allowed origins is set to "*", all CORS
> requests should be allowed.  As I understand it, the W3C spec only requires
> that the Origin header exists:
>
> http://www.w3.org/TR/cors/#resource-processing-model
>
> It also states that it is acceptable for Origin headers to always match the
> list of allowed origins when the list is "unbounded".
>

1. From a quick reading, I do not see any syntax for that lists
besides exact case-sensitive matches.

http://tools.ietf.org/html/rfc6454#section-7
says that the syntax of origin header is

   serialized-origin   = scheme "://" host [ ":" port ]
   ; , ,  from RFC 3986

Nothing says that "host" can be omitted.

http://tools.ietf.org/html/rfc6454#section-6.1
Per Sections 6.1 and 6.2 the correct serialized value of such
"file://" origin will be "null".

2. Some form of sanity check must be present,
because the origin header value is sent back to client and as such can
be abused.

3. That said,
I think that CorsFilter.isValidOrigin(String) can be patched to
a) Be more strict to the specified syntax  (and not just allow any URI)
(Not actually necessary, but it will allow to reject non-conforming clients).

b) Specifically white-list the "null" origin.

c) Specifically white-list a "file://" origin,  with notion that that
is a bug in certain Android versions

> Maybe this is a good case to submit a bug report or a patch.

Agreed.

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: CORS issue with Tomcat and Android Webview

[Terence M. Bandoian]

On 4/26/2014 1:13 AM, Ankit Singhal wrote:

On Sat, Apr 26, 2014 at 12:53 AM, Terence M. Bandoian wrote:


On 4/24/2014 11:16 PM, Ankit Singhal wrote:


Hi

I did more research on this and figure out the issue.If you see the
headers
from Android and look into Origin Header.

Origin: file://

Tomcat CORS filter tries to validate the URI in Origin header and
considers
"file://" as an invalid URI and returns back 403.

I have applied * params. So shouldn't CORS
filter honor this  ?

I agree that Client also has the problem  , but still server should also
allow...



Hi, Ankit-

Have you tried disabling or removing the CORS filter when you're testing
from the Android device?  The flowchart in the Tomcat CORS documentation
indicates that the filter will attempt to validate the origin before it
determines whether or not it is allowed. Apparently, the file scheme is not
considered valid.

Please Note:  The convention on this list is to bottom-post.  When you
reply to a message, please do so at the bottom of the message or inline, as
I've done here.  Additional information may be found on the Tomcat web
site: http://tomcat.apache.org/lists.html#tomcat-users

Hope that helps.

-Terence Bandoian





On Fri, Apr 25, 2014 at 1:36 AM, Terence M. Bandoian 
wrote:

  On 4/24/2014 1:14 PM, Jose María Zaragoza wrote:

  2014-04-24 19:00 GMT+02:00 Terence M. Bandoian :

  On 4/22/2014 1:37 PM, Jose María Zaragoza wrote:

  -- Forwarded message --

From: Terence M. Bandoian 
Date: 2014-04-22 20:12 GMT+02:00
Subject: Re: CORS issue with Tomcat and Android Webview
To: Tomcat Users List 


On 4/22/2014 11:03 AM, Ankit Singhal wrote:

  Also we tried to give the same call from Android App to some

different
Node
server and things worked fine. So it seems some problem with Tomcat
only.

   A silly question:


What does it have to do Tomcat's CORS support with W3C Widget Access
specification ?

I have no idea about Phonegap but it looks like that it prefers to
follow that specification for managing requests to different domains ,
right ?



Hi, Jose-

The request/response headers in the original post were difficult for me
to
follow but basically, requests to Tomcat are successful when tested
with
Chrome (desktop? laptop? server? same as Tomcat?) and unsuccessful when
tested from an Android device. What are the differences between the two
environments? Do those differences have any effect on request
processing
by
the Tomcat CORS filter? If it were me, I'd find out.

  Well , I have no idea, but according this page

http://www.html5rocks.com/en/tutorials/cors/

if Content-Type is application/json , then request is a "not simple
request" ( sic. ) and it requires a OPTIONS preflight request (
including "Origin" header)
And "Once the preflight request gives permissions, the browser makes
the actual request"

First case (Chrome browser) did but, but the second didn't

Are you test to change the Content-Type ?

Regards



Hi, Jose-

  From the page you cited:

"The use-case for CORS is simple. Imagine the site alice.com has some
data that the site bob.com wants to access. This type of request
traditionally wouldn’t be allowed under the browser’s same origin policy.
However, by supporting CORS requests, alice.com can add a few special
response headers that allows bob.com to access the data."

In this case, alice.com would be the server that hosts Tomcat.  As you
suggest, the problem may very well be in the client but - FOR ME - it's
worth the effort to understand what should happen on both the client and
the server and to ensure that both are configured correctly.

-Terence Bandoian





   On Tue, Apr 22, 2014 at 9:22 PM, Ankit Singhal


wrote:

   Hi All



I am facing a strange problem with Tomcat 8 and CORS. I am
developing
a
Hybrid web app using ionicframework, AngularJS, Cordova as front end
and
Tomcat 8 and Spring 3 as back-end.



For easy development I am testing the functionality in chrome ,
where
things are working fine. I added CORS filter with standard
configuration
to
allow CROSS ORIGIN requests from browser.



Today I converted my app into Android App and started making AJAX
calls
to
tomcat server. To my surprise things stopped working . I debugged
further
and anomalies in the headers of browser and Android webview.



Browser sends 2 requests for same call OPTION and POST. But Android
Webview only send POST request.



Browser Request Headers:



OPTION:

Remote Address:54.254.159.166:80

Request URL:http://medistreet.in/auth2

Request Method:OPTIONS

Status Code:200 OK

Request Headers

OPTIONS /auth2 HTTP/1.1

Host: medistreet.in

Connection: keep-alive

Access-Control-Request-Method: POST

Origin: http://localhost

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36
(KHTML,
like Gecko) Chrome/34.0.1847.116 Safari/537.36

Access-Control-Request-Headers: accept, content-type

Accept: */*

Refere

RE: CORS issue with Tomcat and Android Webview

[Martin Gainty]

  


> From: demablo...@gmail.com
> Date: Sat, 26 Apr 2014 13:56:43 +0200
> Subject: Re: CORS issue with Tomcat and Android Webview
> To: users@tomcat.apache.org
> 
> 2014-04-26 13:16 GMT+02:00 Martin Gainty :
> >> Date: Sat, 26 Apr 2014 11:43:05 +0530
> >> Subject: Re: CORS issue with Tomcat and Android Webview
> >> From: ankising...@gmail.com
> >> To: users@tomcat.apache.org
> >>
> >> On Sat, Apr 26, 2014 at 12:53 AM, Terence M. Bandoian 
> >> wrote:
> >>
> >> > On 4/24/2014 11:16 PM, Ankit Singhal wrote:
> >> >
> >> >> Hi
> >> >>
> >> >> I did more research on this and figure out the issue.If you see the
> >> >> headers
> >> >> from Android and look into Origin Header.
> >> >>
> >> >> Origin: file://
> >> >>
> >> >> Tomcat CORS filter tries to validate the URI in Origin header and
> >> >> considers
> >> >> "file://" as an invalid URI and returns back 403.
> >> >>
> >> >> I have applied * params. So shouldn't 
> >> >> CORS
> >> >> filter honor this ?
> >> >>
> >> >> I agree that Client also has the problem , but still server should also
> >> >> allow...
> >> >>
> 
> Hi:
> 
> I'm watching this flowchart
> https://tomcat.apache.org/tomcat-7.0-doc/images/cors-flowchart.png
> 
> and I wonder if Tomcat 7 checks if the request received belongs to the
> right type.
> I mean, if browser sends a simple request ( eg. POST + application/xml
> content-type header )
> WC3 spec says that request should be a preflight request , does
> Tomcat check this case ?
> 
MG>you will need to set the Access-Allow-Origin to * and Content-Type to 
application/xml
public void doPost(HttpServletRequest req, HttpServletResponse resp) {
  resp.addHeader("Access-Control-Allow-Origin", "*");
  resp.addHeader("Content-Type", "application/xml");
  resp.getWriter().append(csvString);
}MG>
 
> 
> Regards
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
  

Re: CORS issue with Tomcat and Android Webview

[Jose María Zaragoza]

2014-04-26 13:16 GMT+02:00 Martin Gainty :
>> Date: Sat, 26 Apr 2014 11:43:05 +0530
>> Subject: Re: CORS issue with Tomcat and Android Webview
>> From: ankising...@gmail.com
>> To: users@tomcat.apache.org
>>
>> On Sat, Apr 26, 2014 at 12:53 AM, Terence M. Bandoian 
>> wrote:
>>
>> > On 4/24/2014 11:16 PM, Ankit Singhal wrote:
>> >
>> >> Hi
>> >>
>> >> I did more research on this and figure out the issue.If you see the
>> >> headers
>> >> from Android and look into Origin Header.
>> >>
>> >> Origin: file://
>> >>
>> >> Tomcat CORS filter tries to validate the URI in Origin header and
>> >> considers
>> >> "file://" as an invalid URI and returns back 403.
>> >>
>> >> I have applied * params. So shouldn't CORS
>> >> filter honor this ?
>> >>
>> >> I agree that Client also has the problem , but still server should also
>> >> allow...
>> >>

Hi:

I'm watching this flowchart
https://tomcat.apache.org/tomcat-7.0-doc/images/cors-flowchart.png

and I wonder if Tomcat 7 checks if the request received belongs to the
right type.
I mean, if browser sends a simple request ( eg. POST + application/xml
content-type header )
WC3 spec says that request should be a preflight request  , does
Tomcat check this case ?



Regards

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: CORS issue with Tomcat and Android Webview

[Martin Gainty]

> Date: Sat, 26 Apr 2014 11:43:05 +0530
> Subject: Re: CORS issue with Tomcat and Android Webview
> From: ankising...@gmail.com
> To: users@tomcat.apache.org
> 
> On Sat, Apr 26, 2014 at 12:53 AM, Terence M. Bandoian 
> wrote:
> 
> > On 4/24/2014 11:16 PM, Ankit Singhal wrote:
> >
> >> Hi
> >>
> >> I did more research on this and figure out the issue.If you see the
> >> headers
> >> from Android and look into Origin Header.
> >>
> >> Origin: file://
> >>
> >> Tomcat CORS filter tries to validate the URI in Origin header and
> >> considers
> >> "file://" as an invalid URI and returns back 403.
> >>
> >> I have applied * params. So shouldn't CORS
> >> filter honor this ?
> >>
> >> I agree that Client also has the problem , but still server should also
> >> allow...
> >>
> >
> >
> > Hi, Ankit-
> >
> > Have you tried disabling or removing the CORS filter when you're testing
> > from the Android device? The flowchart in the Tomcat CORS documentation
> > indicates that the filter will attempt to validate the origin before it
> > determines whether or not it is allowed. Apparently, the file scheme is not
> > considered valid.

MG>referencing the request processing flowchart at
MG>https://tomcat.apache.org/tomcat-7.0-doc/images/cors-flowchart.png
MG>you will need to carefully shepherd your request thru TC 
Valve/Filter/ServletProcessing gauntlet
MG>did you supply a valid origin header?
MG>http://en.wikipedia.org/wiki/List_of_HTTP_header_fields
MG>did you supply a valid request method e.g. POST/GET?
MG>Android is a much diffferent User-agent than Browser and you will need to 
set the request headers properly
MG>HttpConnection httpConn = null;
try {
  // Open an HTTP Connection object
  httpConn = 
(HttpConnection)Connector.open(http://LOCALHOST:8080/services/getdata);
  // Setup HTTP Request to POST
  httpConn.setRequestMethod(HttpConnection.POST);
  httpConn.setRequestProperty("User-Agent",
   ???);
http://www.useragentstring.com/pages/Mobile%20Browserlist/
MG>

> > Hope that helps.
> >
> > -Terence Bandoian
> >
> >
> >
> >>
> >>
> >> On Fri, Apr 25, 2014 at 1:36 AM, Terence M. Bandoian  >> >wrote:
> >>
> >> On 4/24/2014 1:14 PM, Jose María Zaragoza wrote:
> >>>
> >>> 2014-04-24 19:00 GMT+02:00 Terence M. Bandoian :
> >>>>
> >>>> On 4/22/2014 1:37 PM, Jose María Zaragoza wrote:
> >>>>>
> >>>>> -- Forwarded message --
> >>>>>> From: Terence M. Bandoian 
> >>>>>> Date: 2014-04-22 20:12 GMT+02:00
> >>>>>> Subject: Re: CORS issue with Tomcat and Android Webview
> >>>>>> To: Tomcat Users List 
> >>>>>>
> >>>>>>
> >>>>>> On 4/22/2014 11:03 AM, Ankit Singhal wrote:
> >>>>>>
> >>>>>> Also we tried to give the same call from Android App to some
> >>>>>>> different
> >>>>>>> Node
> >>>>>>> server and things worked fine. So it seems some problem with Tomcat
> >>>>>>> only.
> >>>>>>>
> >>>>>>> A silly question:
> >>>>>>>
> >>>>>> What does it have to do Tomcat's CORS support with W3C Widget Access
> >>>>>> specification ?
> >>>>>>
> >>>>>> I have no idea about Phonegap but it looks like that it prefers to
> >>>>>> follow that specification for managing requests to different domains ,
> >>>>>> right ?
> >>>>>>
> >>>>>>
> >>>>> Hi, Jose-
> >>>>>
> >>>>> The request/response headers in the original post were difficult for me
> >>>>> to
> >>>>> follow but basically, requests to Tomcat are successful when tested
> >>>>> with
> >>>>> Chrome (desktop? laptop? server? same as Tomcat?) and unsuccessful when
> >>>>> tested from an Android device. What are the differences between the two
> >>>>> environments? Do those differences have any effect on request
> >>>>> processing
> >>>>> by
> >>>>> the Tomcat CORS filter? If it were me, I'd find ou

Re: CORS issue with Tomcat and Android Webview

[Ankit Singhal]

On Sat, Apr 26, 2014 at 12:53 AM, Terence M. Bandoian wrote:

> On 4/24/2014 11:16 PM, Ankit Singhal wrote:
>
>> Hi
>>
>> I did more research on this and figure out the issue.If you see the
>> headers
>> from Android and look into Origin Header.
>>
>> Origin: file://
>>
>> Tomcat CORS filter tries to validate the URI in Origin header and
>> considers
>> "file://" as an invalid URI and returns back 403.
>>
>> I have applied * params. So shouldn't CORS
>> filter honor this  ?
>>
>> I agree that Client also has the problem  , but still server should also
>> allow...
>>
>
>
> Hi, Ankit-
>
> Have you tried disabling or removing the CORS filter when you're testing
> from the Android device?  The flowchart in the Tomcat CORS documentation
> indicates that the filter will attempt to validate the origin before it
> determines whether or not it is allowed. Apparently, the file scheme is not
> considered valid.
>
> Please Note:  The convention on this list is to bottom-post.  When you
> reply to a message, please do so at the bottom of the message or inline, as
> I've done here.  Additional information may be found on the Tomcat web
> site: http://tomcat.apache.org/lists.html#tomcat-users
>
> Hope that helps.
>
> -Terence Bandoian
>
>
>
>>
>>
>> On Fri, Apr 25, 2014 at 1:36 AM, Terence M. Bandoian > >wrote:
>>
>>  On 4/24/2014 1:14 PM, Jose María Zaragoza wrote:
>>>
>>>  2014-04-24 19:00 GMT+02:00 Terence M. Bandoian :
>>>>
>>>>  On 4/22/2014 1:37 PM, Jose María Zaragoza wrote:
>>>>>
>>>>>  -- Forwarded message --
>>>>>> From: Terence M. Bandoian 
>>>>>> Date: 2014-04-22 20:12 GMT+02:00
>>>>>> Subject: Re: CORS issue with Tomcat and Android Webview
>>>>>> To: Tomcat Users List 
>>>>>>
>>>>>>
>>>>>> On 4/22/2014 11:03 AM, Ankit Singhal wrote:
>>>>>>
>>>>>>  Also we tried to give the same call from Android App to some
>>>>>>> different
>>>>>>> Node
>>>>>>> server and things worked fine. So it seems some problem with Tomcat
>>>>>>> only.
>>>>>>>
>>>>>>>   A silly question:
>>>>>>>
>>>>>> What does it have to do Tomcat's CORS support with W3C Widget Access
>>>>>> specification ?
>>>>>>
>>>>>> I have no idea about Phonegap but it looks like that it prefers to
>>>>>> follow that specification for managing requests to different domains ,
>>>>>> right ?
>>>>>>
>>>>>>
>>>>> Hi, Jose-
>>>>>
>>>>> The request/response headers in the original post were difficult for me
>>>>> to
>>>>> follow but basically, requests to Tomcat are successful when tested
>>>>> with
>>>>> Chrome (desktop? laptop? server? same as Tomcat?) and unsuccessful when
>>>>> tested from an Android device. What are the differences between the two
>>>>> environments? Do those differences have any effect on request
>>>>> processing
>>>>> by
>>>>> the Tomcat CORS filter? If it were me, I'd find out.
>>>>>
>>>>>  Well , I have no idea, but according this page
>>>>
>>>> http://www.html5rocks.com/en/tutorials/cors/
>>>>
>>>> if Content-Type is application/json , then request is a "not simple
>>>> request" ( sic. ) and it requires a OPTIONS preflight request (
>>>> including "Origin" header)
>>>> And "Once the preflight request gives permissions, the browser makes
>>>> the actual request"
>>>>
>>>> First case (Chrome browser) did but, but the second didn't
>>>>
>>>> Are you test to change the Content-Type ?
>>>>
>>>> Regards
>>>>
>>>>
>>> Hi, Jose-
>>>
>>>  From the page you cited:
>>>
>>> "The use-case for CORS is simple. Imagine the site alice.com has some
>>> data that the site bob.com wants to access. This type of request
>>> traditionally wouldn’t be allowed under the browser’s same origin policy.
>>> However, by supporting CORS requests, alice.com can add a few special
>>> 

Re: CORS issue with Tomcat and Android Webview

[Terence M. Bandoian]

On 4/24/2014 11:16 PM, Ankit Singhal wrote:

Hi

I did more research on this and figure out the issue.If you see the headers
from Android and look into Origin Header.

Origin: file://

Tomcat CORS filter tries to validate the URI in Origin header and considers
"file://" as an invalid URI and returns back 403.

I have applied * params. So shouldn't CORS
filter honor this  ?

I agree that Client also has the problem  , but still server should also
allow...



Hi, Ankit-

Have you tried disabling or removing the CORS filter when you're testing 
from the Android device?  The flowchart in the Tomcat CORS documentation 
indicates that the filter will attempt to validate the origin before it 
determines whether or not it is allowed. Apparently, the file scheme is 
not considered valid.


Please Note:  The convention on this list is to bottom-post.  When you 
reply to a message, please do so at the bottom of the message or inline, 
as I've done here.  Additional information may be found on the Tomcat 
web site: http://tomcat.apache.org/lists.html#tomcat-users


Hope that helps.

-Terence Bandoian






On Fri, Apr 25, 2014 at 1:36 AM, Terence M. Bandoian wrote:


On 4/24/2014 1:14 PM, Jose María Zaragoza wrote:


2014-04-24 19:00 GMT+02:00 Terence M. Bandoian :


On 4/22/2014 1:37 PM, Jose María Zaragoza wrote:


-- Forwarded message --
From: Terence M. Bandoian 
Date: 2014-04-22 20:12 GMT+02:00
Subject: Re: CORS issue with Tomcat and Android Webview
To: Tomcat Users List 


On 4/22/2014 11:03 AM, Ankit Singhal wrote:


Also we tried to give the same call from Android App to some different
Node
server and things worked fine. So it seems some problem with Tomcat
only.

  A silly question:

What does it have to do Tomcat's CORS support with W3C Widget Access
specification ?

I have no idea about Phonegap but it looks like that it prefers to
follow that specification for managing requests to different domains ,
right ?



Hi, Jose-

The request/response headers in the original post were difficult for me
to
follow but basically, requests to Tomcat are successful when tested with
Chrome (desktop? laptop? server? same as Tomcat?) and unsuccessful when
tested from an Android device. What are the differences between the two
environments? Do those differences have any effect on request processing
by
the Tomcat CORS filter? If it were me, I'd find out.


Well , I have no idea, but according this page

http://www.html5rocks.com/en/tutorials/cors/

if Content-Type is application/json , then request is a "not simple
request" ( sic. ) and it requires a OPTIONS preflight request (
including "Origin" header)
And "Once the preflight request gives permissions, the browser makes
the actual request"

First case (Chrome browser) did but, but the second didn't

Are you test to change the Content-Type ?

Regards



Hi, Jose-

 From the page you cited:

"The use-case for CORS is simple. Imagine the site alice.com has some
data that the site bob.com wants to access. This type of request
traditionally wouldn’t be allowed under the browser’s same origin policy.
However, by supporting CORS requests, alice.com can add a few special
response headers that allows bob.com to access the data."

In this case, alice.com would be the server that hosts Tomcat.  As you
suggest, the problem may very well be in the client but - FOR ME - it's
worth the effort to understand what should happen on both the client and
the server and to ensure that both are configured correctly.

-Terence Bandoian





  On Tue, Apr 22, 2014 at 9:22 PM, Ankit Singhal

wrote:

  Hi All



I am facing a strange problem with Tomcat 8 and CORS. I am developing
a
Hybrid web app using ionicframework, AngularJS, Cordova as front end
and
Tomcat 8 and Spring 3 as back-end.



For easy development I am testing the functionality in chrome , where
things are working fine. I added CORS filter with standard
configuration
to
allow CROSS ORIGIN requests from browser.



Today I converted my app into Android App and started making AJAX
calls
to
tomcat server. To my surprise things stopped working . I debugged
further
and anomalies in the headers of browser and Android webview.



Browser sends 2 requests for same call OPTION and POST. But Android
Webview only send POST request.



Browser Request Headers:



OPTION:

Remote Address:54.254.159.166:80

Request URL:http://medistreet.in/auth2

Request Method:OPTIONS

Status Code:200 OK

Request Headers

OPTIONS /auth2 HTTP/1.1

Host: medistreet.in

Connection: keep-alive

Access-Control-Request-Method: POST

Origin: http://localhost

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36
(KHTML,
like Gecko) Chrome/34.0.1847.116 Safari/537.36

Access-Control-Request-Headers: accept, content-type

Accept: */*

Referer: http://localhost/

Accept-Encoding: gzip,deflate,sdch

Accept-Language: en-US,en;q=






POST:



Remote Address:5

Re: CORS issue with Tomcat and Android Webview

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ankit,

On 4/25/14, 12:16 AM, Ankit Singhal wrote:
> Hi
> 
> I did more research on this and figure out the issue.If you see
> the headers from Android and look into Origin Header.
> 
> Origin: file://
> 
> Tomcat CORS filter tries to validate the URI in Origin header and 
> considers "file://" as an invalid URI and returns back 403.
> 
> I have applied * params. So 
> shouldn't CORS filter honor this  ?

Current trunk looks like it should work: if you given "*" value for
cors.allowed.origins, then the isOriginAllowed method should
immediately return true, regardless of the value provided for "Origin"
(including no value).

> I agree that Client also has the problem  , but still server
> should also allow...

Are you willing to hack the code a bit and add some debug output?
Perhaps something else is going wrong...

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJTWna9AAoJEBzwKT+lPKRYVOMQAIUa4UkfK/z11ZmhOuCdq1NS
7z3s0SukYHeSwHibE7kKUn7GpmSZHA5xpuTbxNmu/7eqJN33g102TOu7vbxTupn9
C5SIlAfR0vfXGkh4zqrsxH0VhUqb/ZhT1TI3hQppn8Ze9HCCStyFle0s9SO30QEY
LW2D3HwQlTcIcrQlFnWwWLsHacLPKL6D96td4sZ0LmraKdwJttydWTet7/XC6sdJ
2j/ui7+2ImGy+mxSDMXaUiZ86nd/OoqFTSyN2S1RYKbW3CWsY1DcDHOIJyGdpHJT
frLDwJYMxqJPLmLBIhRy+m7K3JKrLod/wY2fiJKRlhWYl0wyTV3JVRd8KqnOhj9N
emjdtst5e010mWdSW3gwZ9hvagkUBnQc3IzoTak/nklVy/dJ6QodiiqVVePH/yJf
N4ZB+ma/IUgFDhtJaTWbSL2ipjXVcR26mhlHRUQqS/lWTc53jwhp+vYskdaEFO0J
o7viW46yZoQL4skQYgM4gSVmepm55ulfsh5cMayXGYFzZMI5g9x5SykFZ5JhgstT
45vAgSHmQI0AWM4pb7Nzfgj6940jGiePF7G3rUkmiuzLkPqpSkUk2nAWnYEjyelI
CHfPR44gD+ZJpuDXonKKoGtH65vJJgOZXn5h0su1g999ueviLFRkjmThDvHPKeAu
9SH9aq8nPB1P7QaqAkI0
=z3Cr
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: CORS issue with Tomcat and Android Webview

[Ankit Singhal]

Hi

I did more research on this and figure out the issue.If you see the headers
from Android and look into Origin Header.

Origin: file://

Tomcat CORS filter tries to validate the URI in Origin header and considers
"file://" as an invalid URI and returns back 403.

I have applied * params. So shouldn't CORS
filter honor this  ?

I agree that Client also has the problem  , but still server should also
allow...



On Fri, Apr 25, 2014 at 1:36 AM, Terence M. Bandoian wrote:

> On 4/24/2014 1:14 PM, Jose María Zaragoza wrote:
>
>> 2014-04-24 19:00 GMT+02:00 Terence M. Bandoian :
>>
>>> On 4/22/2014 1:37 PM, Jose María Zaragoza wrote:
>>>
>>>> -- Forwarded message --
>>>> From: Terence M. Bandoian 
>>>> Date: 2014-04-22 20:12 GMT+02:00
>>>> Subject: Re: CORS issue with Tomcat and Android Webview
>>>> To: Tomcat Users List 
>>>>
>>>>
>>>> On 4/22/2014 11:03 AM, Ankit Singhal wrote:
>>>>
>>>>> Also we tried to give the same call from Android App to some different
>>>>> Node
>>>>> server and things worked fine. So it seems some problem with Tomcat
>>>>> only.
>>>>>
>>>>>  A silly question:
>>>>
>>>> What does it have to do Tomcat's CORS support with W3C Widget Access
>>>> specification ?
>>>>
>>>> I have no idea about Phonegap but it looks like that it prefers to
>>>> follow that specification for managing requests to different domains ,
>>>> right ?
>>>>
>>>
>>>
>>> Hi, Jose-
>>>
>>> The request/response headers in the original post were difficult for me
>>> to
>>> follow but basically, requests to Tomcat are successful when tested with
>>> Chrome (desktop? laptop? server? same as Tomcat?) and unsuccessful when
>>> tested from an Android device. What are the differences between the two
>>> environments? Do those differences have any effect on request processing
>>> by
>>> the Tomcat CORS filter? If it were me, I'd find out.
>>>
>>
>> Well , I have no idea, but according this page
>>
>> http://www.html5rocks.com/en/tutorials/cors/
>>
>> if Content-Type is application/json , then request is a "not simple
>> request" ( sic. ) and it requires a OPTIONS preflight request (
>> including "Origin" header)
>> And "Once the preflight request gives permissions, the browser makes
>> the actual request"
>>
>> First case (Chrome browser) did but, but the second didn't
>>
>> Are you test to change the Content-Type ?
>>
>> Regards
>>
>
>
> Hi, Jose-
>
> From the page you cited:
>
> "The use-case for CORS is simple. Imagine the site alice.com has some
> data that the site bob.com wants to access. This type of request
> traditionally wouldn’t be allowed under the browser’s same origin policy.
> However, by supporting CORS requests, alice.com can add a few special
> response headers that allows bob.com to access the data."
>
> In this case, alice.com would be the server that hosts Tomcat.  As you
> suggest, the problem may very well be in the client but - FOR ME - it's
> worth the effort to understand what should happen on both the client and
> the server and to ensure that both are configured correctly.
>
> -Terence Bandoian
>
>
>
>>
>>
>>  On Tue, Apr 22, 2014 at 9:22 PM, Ankit Singhal
>>>>> wrote:
>>>>>
>>>>>  Hi All
>>>>>>
>>>>>>
>>>>>>
>>>>>> I am facing a strange problem with Tomcat 8 and CORS. I am developing
>>>>>> a
>>>>>> Hybrid web app using ionicframework, AngularJS, Cordova as front end
>>>>>> and
>>>>>> Tomcat 8 and Spring 3 as back-end.
>>>>>>
>>>>>>
>>>>>>
>>>>>> For easy development I am testing the functionality in chrome , where
>>>>>> things are working fine. I added CORS filter with standard
>>>>>> configuration
>>>>>> to
>>>>>> allow CROSS ORIGIN requests from browser.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Today I converted my app into Android App and started making AJAX
>>>>>> calls
>>>>>> to
>>>>>> tomcat server. To my surprise things

Re: CORS issue with Tomcat and Android Webview

[Terence M. Bandoian]

On 4/24/2014 1:14 PM, Jose María Zaragoza wrote:

2014-04-24 19:00 GMT+02:00 Terence M. Bandoian :

On 4/22/2014 1:37 PM, Jose María Zaragoza wrote:

-- Forwarded message --
From: Terence M. Bandoian 
Date: 2014-04-22 20:12 GMT+02:00
Subject: Re: CORS issue with Tomcat and Android Webview
To: Tomcat Users List 


On 4/22/2014 11:03 AM, Ankit Singhal wrote:

Also we tried to give the same call from Android App to some different
Node
server and things worked fine. So it seems some problem with Tomcat only.


A silly question:

What does it have to do Tomcat's CORS support with W3C Widget Access
specification ?

I have no idea about Phonegap but it looks like that it prefers to
follow that specification for managing requests to different domains ,
right ?



Hi, Jose-

The request/response headers in the original post were difficult for me to
follow but basically, requests to Tomcat are successful when tested with
Chrome (desktop? laptop? server? same as Tomcat?) and unsuccessful when
tested from an Android device. What are the differences between the two
environments? Do those differences have any effect on request processing by
the Tomcat CORS filter? If it were me, I'd find out.


Well , I have no idea, but according this page

http://www.html5rocks.com/en/tutorials/cors/

if Content-Type is application/json , then request is a "not simple
request" ( sic. ) and it requires a OPTIONS preflight request (
including "Origin" header)
And "Once the preflight request gives permissions, the browser makes
the actual request"

First case (Chrome browser) did but, but the second didn't

Are you test to change the Content-Type ?

Regards



Hi, Jose-

From the page you cited:

"The use-case for CORS is simple. Imagine the site alice.com has some 
data that the site bob.com wants to access. This type of request 
traditionally wouldn’t be allowed under the browser’s same origin 
policy. However, by supporting CORS requests, alice.com can add a few 
special response headers that allows bob.com to access the data."


In this case, alice.com would be the server that hosts Tomcat.  As you 
suggest, the problem may very well be in the client but - FOR ME - it's 
worth the effort to understand what should happen on both the client and 
the server and to ensure that both are configured correctly.


-Terence Bandoian







On Tue, Apr 22, 2014 at 9:22 PM, Ankit Singhal
wrote:


Hi All



I am facing a strange problem with Tomcat 8 and CORS. I am developing a
Hybrid web app using ionicframework, AngularJS, Cordova as front end and
Tomcat 8 and Spring 3 as back-end.



For easy development I am testing the functionality in chrome , where
things are working fine. I added CORS filter with standard configuration
to
allow CROSS ORIGIN requests from browser.



Today I converted my app into Android App and started making AJAX calls
to
tomcat server. To my surprise things stopped working . I debugged
further
and anomalies in the headers of browser and Android webview.



Browser sends 2 requests for same call OPTION and POST. But Android
Webview only send POST request.



Browser Request Headers:



OPTION:

Remote Address:54.254.159.166:80

Request URL:http://medistreet.in/auth2

Request Method:OPTIONS

Status Code:200 OK

Request Headers

OPTIONS /auth2 HTTP/1.1

Host: medistreet.in

Connection: keep-alive

Access-Control-Request-Method: POST

Origin: http://localhost

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36
(KHTML,
like Gecko) Chrome/34.0.1847.116 Safari/537.36

Access-Control-Request-Headers: accept, content-type

Accept: */*

Referer: http://localhost/

Accept-Encoding: gzip,deflate,sdch

Accept-Language: en-US,en;q=






POST:



Remote Address:54.254.159.166:80

Request URL:http://medistreet.in/auth2

Request Method:POST

Status Code:200 OK



Request Headers

Accept:application/json, text/plain, */*

Accept-Encoding:gzip,deflate,sdch

Accept-Language:en-US,en;q=

Connection:keep-alive

Content-Length:39

Content-Type:application/json;charset=8


Host:medistreet.in

Origin:http://localhost

Referer:http://localhost/

User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36
(KHTML,
like Gecko) Chrome/34.0.1847.116 Safari/537.36





Android Request Headers:



Request URL:http://medistreet.in/auth2

Request Method:POST

Status Code:403 Forbidden

Request Headers

POST http://medistreet.in/auth2
HTTP/1.1<http://medistreet.in/auth2%20HTTP/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=8






The difference here I see is with Number of headers and specially Origin
Header  which contains "file://". To overcome this I added  more option
is CORS filter:





CorsFilter

org.apa

Re: CORS issue with Tomcat and Android Webview

[Jose María Zaragoza]

2014-04-24 19:00 GMT+02:00 Terence M. Bandoian :
> On 4/22/2014 1:37 PM, Jose María Zaragoza wrote:
>>
>> -- Forwarded message --
>> From: Terence M. Bandoian 
>> Date: 2014-04-22 20:12 GMT+02:00
>> Subject: Re: CORS issue with Tomcat and Android Webview
>> To: Tomcat Users List 
>>
>>
>> On 4/22/2014 11:03 AM, Ankit Singhal wrote:
>>>
>>> Also we tried to give the same call from Android App to some different
>>> Node
>>> server and things worked fine. So it seems some problem with Tomcat only.
>>>
>>
>> A silly question:
>>
>> What does it have to do Tomcat's CORS support with W3C Widget Access
>> specification ?
>>
>> I have no idea about Phonegap but it looks like that it prefers to
>> follow that specification for managing requests to different domains ,
>> right ?
>
>
>
> Hi, Jose-
>
> The request/response headers in the original post were difficult for me to
> follow but basically, requests to Tomcat are successful when tested with
> Chrome (desktop? laptop? server? same as Tomcat?) and unsuccessful when
> tested from an Android device. What are the differences between the two
> environments? Do those differences have any effect on request processing by
> the Tomcat CORS filter? If it were me, I'd find out.


Well , I have no idea, but according this page

http://www.html5rocks.com/en/tutorials/cors/

if Content-Type is application/json , then request is a "not simple
request" ( sic. ) and it requires a OPTIONS preflight request (
including "Origin" header)
And "Once the preflight request gives permissions, the browser makes
the actual request"

First case (Chrome browser) did but, but the second didn't

Are you test to change the Content-Type ?

Regards







>
> -Terence Bandoian
>
>
>>
>>> On Tue, Apr 22, 2014 at 9:22 PM, Ankit Singhal
>>> wrote:
>>>
>>>> Hi All
>>>>
>>>>
>>>>
>>>> I am facing a strange problem with Tomcat 8 and CORS. I am developing a
>>>> Hybrid web app using ionicframework, AngularJS, Cordova as front end and
>>>> Tomcat 8 and Spring 3 as back-end.
>>>>
>>>>
>>>>
>>>> For easy development I am testing the functionality in chrome , where
>>>> things are working fine. I added CORS filter with standard configuration
>>>> to
>>>> allow CROSS ORIGIN requests from browser.
>>>>
>>>>
>>>>
>>>> Today I converted my app into Android App and started making AJAX calls
>>>> to
>>>> tomcat server. To my surprise things stopped working . I debugged
>>>> further
>>>> and anomalies in the headers of browser and Android webview.
>>>>
>>>>
>>>>
>>>> Browser sends 2 requests for same call OPTION and POST. But Android
>>>> Webview only send POST request.
>>>>
>>>>
>>>>
>>>> Browser Request Headers:
>>>>
>>>>
>>>>
>>>> OPTION:
>>>>
>>>> Remote Address:54.254.159.166:80
>>>>
>>>> Request URL:http://medistreet.in/auth2
>>>>
>>>> Request Method:OPTIONS
>>>>
>>>> Status Code:200 OK
>>>>
>>>> Request Headers
>>>>
>>>> OPTIONS /auth2 HTTP/1.1
>>>>
>>>> Host: medistreet.in
>>>>
>>>> Connection: keep-alive
>>>>
>>>> Access-Control-Request-Method: POST
>>>>
>>>> Origin: http://localhost
>>>>
>>>> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36
>>>> (KHTML,
>>>> like Gecko) Chrome/34.0.1847.116 Safari/537.36
>>>>
>>>> Access-Control-Request-Headers: accept, content-type
>>>>
>>>> Accept: */*
>>>>
>>>> Referer: http://localhost/
>>>>
>>>> Accept-Encoding: gzip,deflate,sdch
>>>>
>>>> Accept-Language: en-US,en;q=8
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> POST:
>>>>
>>>>
>>>>
>>>> Remote Address:54.254.159.166:80
>>>>
>>>> Request URL:http://medistreet.in/auth2
>>>>
>>>> Request Method:POST
>>>>
>>>> Status Code:200 OK
>>>>
>>>>
>>>

Re: CORS issue with Tomcat and Android Webview

[Terence M. Bandoian]

On 4/22/2014 1:37 PM, Jose María Zaragoza wrote:

-- Forwarded message --
From: Terence M. Bandoian 
Date: 2014-04-22 20:12 GMT+02:00
Subject: Re: CORS issue with Tomcat and Android Webview
To: Tomcat Users List 


On 4/22/2014 11:03 AM, Ankit Singhal wrote:

Also we tried to give the same call from Android App to some different Node
server and things worked fine. So it seems some problem with Tomcat only.



A silly question:

What does it have to do Tomcat's CORS support with W3C Widget Access
specification ?

I have no idea about Phonegap but it looks like that it prefers to
follow that specification for managing requests to different domains ,
right ?



Hi, Jose-

The request/response headers in the original post were difficult for me 
to follow but basically, requests to Tomcat are successful when tested 
with Chrome (desktop? laptop? server? same as Tomcat?) and unsuccessful 
when tested from an Android device. What are the differences between the 
two environments? Do those differences have any effect on request 
processing by the Tomcat CORS filter? If it were me, I'd find out.


-Terence Bandoian





On Tue, Apr 22, 2014 at 9:22 PM, Ankit Singhal wrote:


Hi All



I am facing a strange problem with Tomcat 8 and CORS. I am developing a
Hybrid web app using ionicframework, AngularJS, Cordova as front end and
Tomcat 8 and Spring 3 as back-end.



For easy development I am testing the functionality in chrome , where
things are working fine. I added CORS filter with standard configuration to
allow CROSS ORIGIN requests from browser.



Today I converted my app into Android App and started making AJAX calls to
tomcat server. To my surprise things stopped working . I debugged further
and anomalies in the headers of browser and Android webview.



Browser sends 2 requests for same call OPTION and POST. But Android
Webview only send POST request.



Browser Request Headers:



OPTION:

Remote Address:54.254.159.166:80

Request URL:http://medistreet.in/auth2

Request Method:OPTIONS

Status Code:200 OK

Request Headers

OPTIONS /auth2 HTTP/1.1

Host: medistreet.in

Connection: keep-alive

Access-Control-Request-Method: POST

Origin: http://localhost

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/34.0.1847.116 Safari/537.36

Access-Control-Request-Headers: accept, content-type

Accept: */*

Referer: http://localhost/

Accept-Encoding: gzip,deflate,sdch

Accept-Language: en-US,en;q=8





POST:



Remote Address:54.254.159.166:80

Request URL:http://medistreet.in/auth2

Request Method:POST

Status Code:200 OK



Request Headers

Accept:application/json, text/plain, */*

Accept-Encoding:gzip,deflate,sdch

Accept-Language:en-US,en;q=8

Connection:keep-alive

Content-Length:39

Content-Type:application/json;charset=F-8

Host:medistreet.in

Origin:http://localhost

Referer:http://localhost/

User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/34.0.1847.116 Safari/537.36





Android Request Headers:



Request URL:http://medistreet.in/auth2

Request Method:POST

Status Code:403 Forbidden

Request Headers

POST http://medistreet.in/auth2 HTTP/1.1<http://medistreet.in/auth2%20HTTP/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=F-8





The difference here I see is with Number of headers and specially Origin
Header  which contains "file://". To overcome this I added  more option
is CORS filter:





CorsFilter

org.apache.catalina.filters.CorsFilter



cors.allowed.origins

*







CorsFilter

/*





Another strange thing is that when we send the same Android request
Headers from POSTMAN (chrome REST plugin) request is successful.



POSTMAN Headers:



Remote Address:54.254.159.166:80

Request URL:http://medistreet.in/auth2

Request Method:POST

Status Code:200 OK

Request Headers

Accept:application/json, text/plain, */*

Accept-Encoding:gzip,deflate,sdch

Accept-Language:en-US,en;q=8

Cache-Control:no-cache

Connection:keep-alive

Content-Length:39

Content-Type:application/json;charset=F-8

Cookie:fbm_464284963672217�se_domain=.medistreet.in;
JSESSIONID�435755F03D7B045DD6E33D1D16AC51;
fbsr_464284963672217=jASqF-nWquTFPk_-5wAtI0jTImBNkVxglUT-gHNSw.eyJhbGdvcml0aG0iOiJITUFDLVNIQTI1NiIsImNvZGUiOiJBUUQ0UEZZVXE4eDFIa3V6OW9RV3RlVzE4clQ3SmtVRjBzU1VVcXhfV1BENG8tV1BZYjZuTVdDdDJGMmw4TjJUeUxLSzhIYUU1TUc2MkY5cXZOaXRMN3NGdklNZkhySmluYkdjMWs1THAyZnZYa2Zpa1lLVGJ0OWlZeXVvRDNWUDhTblp4czJCeTQ4RTlYY1ZjUmhGWGJsNnFMeG5YcWxxQ0d3b0hRM1ctRWhlLU02ejVITnhhakJtaVFRVk9PanFBVUtMSlk4Y3pLa0RtejFSY3RjTEFRaW16X1lkLUFkUngxUGwzajVNczdWOFdiMW9xeC05QjA0T2xraXktVU9ZalpSRUJsZjhibnZjQXQ2aUZTc1d2QTA3TjVUYnFIekVxQ0JIYjJNRG4tSUJhajl6TEMwQlVpckM0YzJXbC1GVDNhcyIsImlzc3VlZF9hdCI6MTM5ODE4MDg2NCwidX

Re: CORS issue with Tomcat and Android Webview

[Jose María Zaragoza]

-- Forwarded message --
From: Terence M. Bandoian 
Date: 2014-04-22 20:12 GMT+02:00
Subject: Re: CORS issue with Tomcat and Android Webview
To: Tomcat Users List 


On 4/22/2014 11:03 AM, Ankit Singhal wrote:
>
> Also we tried to give the same call from Android App to some different Node
> server and things worked fine. So it seems some problem with Tomcat only.
>


A silly question:

What does it have to do Tomcat's CORS support with W3C Widget Access
specification ?

I have no idea about Phonegap but it looks like that it prefers to
follow that specification for managing requests to different domains ,
right ?

>
> On Tue, Apr 22, 2014 at 9:22 PM, Ankit Singhal wrote:
>
>> Hi All
>>
>>
>>
>> I am facing a strange problem with Tomcat 8 and CORS. I am developing a
>> Hybrid web app using ionicframework, AngularJS, Cordova as front end and
>> Tomcat 8 and Spring 3 as back-end.
>>
>>
>>
>> For easy development I am testing the functionality in chrome , where
>> things are working fine. I added CORS filter with standard configuration to
>> allow CROSS ORIGIN requests from browser.
>>
>>
>>
>> Today I converted my app into Android App and started making AJAX calls to
>> tomcat server. To my surprise things stopped working . I debugged further
>> and anomalies in the headers of browser and Android webview.
>>
>>
>>
>> Browser sends 2 requests for same call OPTION and POST. But Android
>> Webview only send POST request.
>>
>>
>>
>> Browser Request Headers:
>>
>>
>>
>> OPTION:
>>
>> Remote Address:54.254.159.166:80
>>
>> Request URL:http://medistreet.in/auth2
>>
>> Request Method:OPTIONS
>>
>> Status Code:200 OK
>>
>> Request Headers
>>
>> OPTIONS /auth2 HTTP/1.1
>>
>> Host: medistreet.in
>>
>> Connection: keep-alive
>>
>> Access-Control-Request-Method: POST
>>
>> Origin: http://localhost
>>
>> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML,
>> like Gecko) Chrome/34.0.1847.116 Safari/537.36
>>
>> Access-Control-Request-Headers: accept, content-type
>>
>> Accept: */*
>>
>> Referer: http://localhost/
>>
>> Accept-Encoding: gzip,deflate,sdch
>>
>> Accept-Language: en-US,en;q=0.8
>>
>>
>>
>>
>>
>> POST:
>>
>>
>>
>> Remote Address:54.254.159.166:80
>>
>> Request URL:http://medistreet.in/auth2
>>
>> Request Method:POST
>>
>> Status Code:200 OK
>>
>>
>>
>> Request Headers
>>
>> Accept:application/json, text/plain, */*
>>
>> Accept-Encoding:gzip,deflate,sdch
>>
>> Accept-Language:en-US,en;q=0.8
>>
>> Connection:keep-alive
>>
>> Content-Length:39
>>
>> Content-Type:application/json;charset=UTF-8
>>
>> Host:medistreet.in
>>
>> Origin:http://localhost
>>
>> Referer:http://localhost/
>>
>> User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML,
>> like Gecko) Chrome/34.0.1847.116 Safari/537.36
>>
>>
>>
>>
>>
>> Android Request Headers:
>>
>>
>>
>> Request URL:http://medistreet.in/auth2
>>
>> Request Method:POST
>>
>> Status Code:403 Forbidden
>>
>> Request Headers
>>
>> POST http://medistreet.in/auth2 
>> HTTP/1.1<http://medistreet.in/auth2%20HTTP/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=UTF-8
>>
>>
>>
>>
>>
>> The difference here I see is with Number of headers and specially Origin
>> Header  which contains "file://". To overcome this I added  more option
>> is CORS filter:
>>
>>
>>
>> 
>>
>> CorsFilter
>>
>> org.apache.catalina.filters.CorsFilter
>>
>> 
>>
>> cors.allowed.origins
>>
>> *
>>
>> 
>>
>> 
>>
>> 
>>
>> CorsFilter
>>
>> /*
>>
>> 
>>
>>
>>
>> Another strange thing is that when we send the same Android request
>> Headers from POSTMAN (chrome REST plugin) request is successful.
>>
>>
>>
>> POSTMA

Re: CORS issue with Tomcat and Android Webview

[Terence M. Bandoian]

On 4/22/2014 11:03 AM, Ankit Singhal wrote:

Also we tried to give the same call from Android App to some different Node
server and things worked fine. So it seems some problem with Tomcat only.


On Tue, Apr 22, 2014 at 9:22 PM, Ankit Singhal wrote:


Hi All



I am facing a strange problem with Tomcat 8 and CORS. I am developing a
Hybrid web app using ionicframework, AngularJS, Cordova as front end and
Tomcat 8 and Spring 3 as back-end.



For easy development I am testing the functionality in chrome , where
things are working fine. I added CORS filter with standard configuration to
allow CROSS ORIGIN requests from browser.



Today I converted my app into Android App and started making AJAX calls to
tomcat server. To my surprise things stopped working . I debugged further
and anomalies in the headers of browser and Android webview.



Browser sends 2 requests for same call OPTION and POST. But Android
Webview only send POST request.



Browser Request Headers:



OPTION:

Remote Address:54.254.159.166:80

Request URL:http://medistreet.in/auth2

Request Method:OPTIONS

Status Code:200 OK

Request Headers

OPTIONS /auth2 HTTP/1.1

Host: medistreet.in

Connection: keep-alive

Access-Control-Request-Method: POST

Origin: http://localhost

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/34.0.1847.116 Safari/537.36

Access-Control-Request-Headers: accept, content-type

Accept: */*

Referer: http://localhost/

Accept-Encoding: gzip,deflate,sdch

Accept-Language: en-US,en;q=0.8





POST:



Remote Address:54.254.159.166:80

Request URL:http://medistreet.in/auth2

Request Method:POST

Status Code:200 OK



Request Headers

Accept:application/json, text/plain, */*

Accept-Encoding:gzip,deflate,sdch

Accept-Language:en-US,en;q=0.8

Connection:keep-alive

Content-Length:39

Content-Type:application/json;charset=UTF-8

Host:medistreet.in

Origin:http://localhost

Referer:http://localhost/

User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/34.0.1847.116 Safari/537.36





Android Request Headers:



Request URL:http://medistreet.in/auth2

Request Method:POST

Status Code:403 Forbidden

Request Headers

POST http://medistreet.in/auth2 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=UTF-8





The difference here I see is with Number of headers and specially Origin
Header  which contains "file://". To overcome this I added  more option
is CORS filter:





CorsFilter

org.apache.catalina.filters.CorsFilter



cors.allowed.origins

*







CorsFilter

/*





Another strange thing is that when we send the same Android request
Headers from POSTMAN (chrome REST plugin) request is successful.



POSTMAN Headers:



Remote Address:54.254.159.166:80

Request URL:http://medistreet.in/auth2

Request Method:POST

Status Code:200 OK

Request Headers

Accept:application/json, text/plain, */*

Accept-Encoding:gzip,deflate,sdch

Accept-Language:en-US,en;q=0.8

Cache-Control:no-cache

Connection:keep-alive

Content-Length:39

Content-Type:application/json;charset=UTF-8

Cookie:fbm_464284963672217=base_domain=.medistreet.in;
JSESSIONID=87435755F03D7B045DD6E33D1D16AC51;
fbsr_464284963672217=dUjASqF-nWquTFPk_-5wAtI0jTImBNkVxglUT-gHNSw.eyJhbGdvcml0aG0iOiJITUFDLVNIQTI1NiIsImNvZGUiOiJBUUQ0UEZZVXE4eDFIa3V6OW9RV3RlVzE4clQ3SmtVRjBzU1VVcXhfV1BENG8tV1BZYjZuTVdDdDJGMmw4TjJUeUxLSzhIYUU1TUc2MkY5cXZOaXRMN3NGdklNZkhySmluYkdjMWs1THAyZnZYa2Zpa1lLVGJ0OWlZeXVvRDNWUDhTblp4czJCeTQ4RTlYY1ZjUmhGWGJsNnFMeG5YcWxxQ0d3b0hRM1ctRWhlLU02ejVITnhhakJtaVFRVk9PanFBVUtMSlk4Y3pLa0RtejFSY3RjTEFRaW16X1lkLUFkUngxUGwzajVNczdWOFdiMW9xeC05QjA0T2xraXktVU9ZalpSRUJsZjhibnZjQXQ2aUZTc1d2QTA3TjVUYnFIekVxQ0JIYjJNRG4tSUJhajl6TEMwQlVpckM0YzJXbC1GVDNhcyIsImlzc3VlZF9hdCI6MTM5ODE4MDg2NCwidXNlcl9pZCI6IjU3NjI1MjI2MiJ9

Host:medistreet.in

Origin:chrome-extension://fdmmgilgnpjigdojojpjoooidkmcomcm

User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/34.0.1847.116 Safari/537.36





After this also there is no solution to the problem .  I suspect that
Android Webview is not sending something which Tomcat is rejecting.



Any help will highly be appreciated.


Regards

Ankit



Hi, Ankit-

I would double-check the documentation for the Tomcat CORS filter and 
the Cordova whitelist implementation:


https://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CORS_Filter
http://docs.phonegap.com/en/3.4.0/guide_appdev_whitelist_index.md.html

Hope that helps.

-Terence Bandoian


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: CORS issue with Tomcat and Android Webview

[Ankit Singhal]

Also we tried to give the same call from Android App to some different Node
server and things worked fine. So it seems some problem with Tomcat only.


On Tue, Apr 22, 2014 at 9:22 PM, Ankit Singhal wrote:

> Hi All
>
>
>
> I am facing a strange problem with Tomcat 8 and CORS. I am developing a
> Hybrid web app using ionicframework, AngularJS, Cordova as front end and
> Tomcat 8 and Spring 3 as back-end.
>
>
>
> For easy development I am testing the functionality in chrome , where
> things are working fine. I added CORS filter with standard configuration to
> allow CROSS ORIGIN requests from browser.
>
>
>
> Today I converted my app into Android App and started making AJAX calls to
> tomcat server. To my surprise things stopped working . I debugged further
> and anomalies in the headers of browser and Android webview.
>
>
>
> Browser sends 2 requests for same call OPTION and POST. But Android
> Webview only send POST request.
>
>
>
> Browser Request Headers:
>
>
>
> OPTION:
>
> Remote Address:54.254.159.166:80
>
> Request URL:http://medistreet.in/auth2
>
> Request Method:OPTIONS
>
> Status Code:200 OK
>
> Request Headers
>
> OPTIONS /auth2 HTTP/1.1
>
> Host: medistreet.in
>
> Connection: keep-alive
>
> Access-Control-Request-Method: POST
>
> Origin: http://localhost
>
> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML,
> like Gecko) Chrome/34.0.1847.116 Safari/537.36
>
> Access-Control-Request-Headers: accept, content-type
>
> Accept: */*
>
> Referer: http://localhost/
>
> Accept-Encoding: gzip,deflate,sdch
>
> Accept-Language: en-US,en;q=0.8
>
>
>
>
>
> POST:
>
>
>
> Remote Address:54.254.159.166:80
>
> Request URL:http://medistreet.in/auth2
>
> Request Method:POST
>
> Status Code:200 OK
>
>
>
> Request Headers
>
> Accept:application/json, text/plain, */*
>
> Accept-Encoding:gzip,deflate,sdch
>
> Accept-Language:en-US,en;q=0.8
>
> Connection:keep-alive
>
> Content-Length:39
>
> Content-Type:application/json;charset=UTF-8
>
> Host:medistreet.in
>
> Origin:http://localhost
>
> Referer:http://localhost/
>
> User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML,
> like Gecko) Chrome/34.0.1847.116 Safari/537.36
>
>
>
>
>
> Android Request Headers:
>
>
>
> Request URL:http://medistreet.in/auth2
>
> Request Method:POST
>
> Status Code:403 Forbidden
>
> Request Headers
>
> POST http://medistreet.in/auth2 
> 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=UTF-8
>
>
>
>
>
> The difference here I see is with Number of headers and specially Origin
> Header  which contains "file://". To overcome this I added  more option
> is CORS filter:
>
>
>
> 
>
> CorsFilter
>
> org.apache.catalina.filters.CorsFilter
>
> 
>
> cors.allowed.origins
>
> *
>
> 
>
> 
>
> 
>
> CorsFilter
>
> /*
>
> 
>
>
>
> Another strange thing is that when we send the same Android request
> Headers from POSTMAN (chrome REST plugin) request is successful.
>
>
>
> POSTMAN Headers:
>
>
>
> Remote Address:54.254.159.166:80
>
> Request URL:http://medistreet.in/auth2
>
> Request Method:POST
>
> Status Code:200 OK
>
> Request Headers
>
> Accept:application/json, text/plain, */*
>
> Accept-Encoding:gzip,deflate,sdch
>
> Accept-Language:en-US,en;q=0.8
>
> Cache-Control:no-cache
>
> Connection:keep-alive
>
> Content-Length:39
>
> Content-Type:application/json;charset=UTF-8
>
> Cookie:fbm_464284963672217=base_domain=.medistreet.in;
> JSESSIONID=87435755F03D7B045DD6E33D1D16AC51;
> fbsr_464284963672217=dUjASqF-nWquTFPk_-5wAtI0jTImBNkVxglUT-gHNSw.eyJhbGdvcml0aG0iOiJITUFDLVNIQTI1NiIsImNvZGUiOiJBUUQ0UEZZVXE4eDFIa3V6OW9RV3RlVzE4clQ3SmtVRjBzU1VVcXhfV1BENG8tV1BZYjZuTVdDdDJGMmw4TjJUeUxLSzhIYUU1TUc2MkY5cXZOaXRMN3NGdklNZkhySmluYkdjMWs1THAyZnZYa2Zpa1lLVGJ0OWlZeXVvRDNWUDhTblp4czJCeTQ4RTlYY1ZjUmhGWGJsNnFMeG5YcWxxQ0d3b0hRM1ctRWhlLU02ejVITnhhakJtaVFRVk9PanFBVUtMSlk4Y3pLa0RtejFSY3RjTEFRaW16X1lkLUFkUngxUGwzajVNczdWOFdiMW9xeC05QjA0T2xraXktVU9ZalpSRUJsZjhibnZjQXQ2aUZTc1d2QTA3TjVUYnFIekVxQ0JIYjJNRG4tSUJhajl6TEMwQlVpckM0YzJXbC1GVDNhcyIsImlzc3VlZF9hdCI6MTM5ODE4MDg2NCwidXNlcl9pZCI6IjU3NjI1MjI2MiJ9
>
> Host:medistreet.in
>
> Origin:chrome-extension://fdmmgilgnpjigdojojpjoooidkmcomcm
>
> User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML,
> like Gecko) Chrome/34.0.1847.116 Safari/537.36
>
>
>
>
>
> After this also there is no solution to the problem .  I suspect that
> Android Webview is not sending something which Tomcat is rejecting.
>
>
>
> Any help will highly be appreciated.
>
>
> Regards
>
> Ankit
>
>
>

CORS issue with Tomcat and Android Webview

[Ankit Singhal]

Hi All



I am facing a strange problem with Tomcat 8 and CORS. I am developing a
Hybrid web app using ionicframework, AngularJS, Cordova as front end and
Tomcat 8 and Spring 3 as back-end.



For easy development I am testing the functionality in chrome , where
things are working fine. I added CORS filter with standard configuration to
allow CROSS ORIGIN requests from browser.



Today I converted my app into Android App and started making AJAX calls to
tomcat server. To my surprise things stopped working . I debugged further
and anomalies in the headers of browser and Android webview.



Browser sends 2 requests for same call OPTION and POST. But Android Webview
only send POST request.



Browser Request Headers:



OPTION:

Remote Address:54.254.159.166:80

Request URL:http://medistreet.in/auth2

Request Method:OPTIONS

Status Code:200 OK

Request Headers

OPTIONS /auth2 HTTP/1.1

Host: medistreet.in

Connection: keep-alive

Access-Control-Request-Method: POST

Origin: http://localhost

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/34.0.1847.116 Safari/537.36

Access-Control-Request-Headers: accept, content-type

Accept: */*

Referer: http://localhost/

Accept-Encoding: gzip,deflate,sdch

Accept-Language: en-US,en;q=0.8





POST:



Remote Address:54.254.159.166:80

Request URL:http://medistreet.in/auth2

Request Method:POST

Status Code:200 OK



Request Headers

Accept:application/json, text/plain, */*

Accept-Encoding:gzip,deflate,sdch

Accept-Language:en-US,en;q=0.8

Connection:keep-alive

Content-Length:39

Content-Type:application/json;charset=UTF-8

Host:medistreet.in

Origin:http://localhost

Referer:http://localhost/

User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/34.0.1847.116 Safari/537.36





Android Request Headers:



Request URL:http://medistreet.in/auth2

Request Method:POST

Status Code:403 Forbidden

Request Headers

POST http://medistreet.in/auth2 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=UTF-8





The difference here I see is with Number of headers and specially Origin
Header  which contains "file:// ". To overcome this I added
more option is CORS filter:





CorsFilter

org.apache.catalina.filters.CorsFilter



cors.allowed.origins

*







CorsFilter

/*





Another strange thing is that when we send the same Android request Headers
from POSTMAN (chrome REST plugin) request is successful.



POSTMAN Headers:



Remote Address:54.254.159.166:80

Request URL:http://medistreet.in/auth2

Request Method:POST

Status Code:200 OK

Request Headers

Accept:application/json, text/plain, */*

Accept-Encoding:gzip,deflate,sdch

Accept-Language:en-US,en;q=0.8

Cache-Control:no-cache

Connection:keep-alive

Content-Length:39

Content-Type:application/json;charset=UTF-8

Cookie:fbm_464284963672217=base_domain=.medistreet.in;
JSESSIONID=87435755F03D7B045DD6E33D1D16AC51;
fbsr_464284963672217=dUjASqF-nWquTFPk_-5wAtI0jTImBNkVxglUT-gHNSw.eyJhbGdvcml0aG0iOiJITUFDLVNIQTI1NiIsImNvZGUiOiJBUUQ0UEZZVXE4eDFIa3V6OW9RV3RlVzE4clQ3SmtVRjBzU1VVcXhfV1BENG8tV1BZYjZuTVdDdDJGMmw4TjJUeUxLSzhIYUU1TUc2MkY5cXZOaXRMN3NGdklNZkhySmluYkdjMWs1THAyZnZYa2Zpa1lLVGJ0OWlZeXVvRDNWUDhTblp4czJCeTQ4RTlYY1ZjUmhGWGJsNnFMeG5YcWxxQ0d3b0hRM1ctRWhlLU02ejVITnhhakJtaVFRVk9PanFBVUtMSlk4Y3pLa0RtejFSY3RjTEFRaW16X1lkLUFkUngxUGwzajVNczdWOFdiMW9xeC05QjA0T2xraXktVU9ZalpSRUJsZjhibnZjQXQ2aUZTc1d2QTA3TjVUYnFIekVxQ0JIYjJNRG4tSUJhajl6TEMwQlVpckM0YzJXbC1GVDNhcyIsImlzc3VlZF9hdCI6MTM5ODE4MDg2NCwidXNlcl9pZCI6IjU3NjI1MjI2MiJ9

Host:medistreet.in

Origin:chrome-extension://fdmmgilgnpjigdojojpjoooidkmcomcm

User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/34.0.1847.116 Safari/537.36





After this also there is no solution to the problem .  I suspect that
Android Webview is not sending something which Tomcat is rejecting.



Any help will highly be appreciated.


Regards

Ankit