On 4/26/2014 1:13 AM, Ankit Singhal wrote:
On Sat, Apr 26, 2014 at 12:53 AM, Terence M. Bandoian <tere...@tmbsw.com>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 <accept-origin>*</accept-origin> 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 <tere...@tmbsw.com
wrote:
  On 4/24/2014 1:14 PM, Jose María Zaragoza wrote:
  2014-04-24 19:00 GMT+02:00 Terence M. Bandoian <tere...@tmbsw.com>:
  On 4/22/2014 1:37 PM, Jose María Zaragoza wrote:
  ---------- Forwarded message ----------
From: Terence M. Bandoian <tere...@tmbsw.com>
Date: 2014-04-22 20:12 GMT+02:00
Subject: Re: CORS issue with Tomcat and Android Webview
To: Tomcat Users List <users@tomcat.apache.org>


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

<ankising...@gmail.com>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:



<filter>

<filter-name>CorsFilter</filter-name>

<filter-class>org.apache.catalina.filters.CorsFilter</filter-class>

<init-param>

<param-name>cors.allowed.origins</param-name>

<param-value>*</param-value>

</init-param>

</filter>

<filter-mapping>

<filter-name>CorsFilter</filter-name>

<url-pattern>/*</url-pattern>

</filter-mapping>



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=


Cache-Control:no-cache

Connection:keep-alive

Content-Length:39

Content-Type:application/json;charset=8

Cookie:fbm_464284963672217�se_domain=edistreet.in;
JSESSIONID�435755F03D7B045DD6E33D1D16AC51;

fbsr_464284963672217=SqF-nWquTFPk_-5wAtI0jTImBNkVxglUT-gHNSw.
eyJhbGdvcml0aG0iOiJITUFDLVNIQTI1NiIsImNvZGUiOiJBUUQ0UEZZVXE4
eDFIa3V6OW9RV3RlVzE4clQ3SmtVRjBzU1VVcXhfV1BENG8tV1BZYjZuTVdD
dDJGMmw4TjJUeUxLSzhIYUU1TUc2MkY5cXZOaXRMN3NGdklNZkhySmluYkdj
MWs1THAyZnZYa2Zpa1lLVGJ0OWlZeXVvRDNWUDhTblp4czJCeTQ4RTlYY1Zj
UmhGWGJsNnFMeG5YcWxxQ0d3b0hRM1ctRWhlLU02ejVITnhhakJtaVFRVk9P
anFBVUtMSlk4Y3pLa0RtejFSY3RjTEFRaW16X1lkLUFkUngxUGwzajVNczdW
OFdiMW9xeC05QjA0T2xraXktVU9ZalpSRUJsZjhibnZjQXQ2aUZTc1d2QTA3
TjVUYnFIekVxQ0JIYjJNRG4tSUJhajl6TEMwQlVpckM0YzJXbC1GVDNhcyIs
Imlzc3VlZF9hdCI6MTM5ODE4MDg2NCwidXNlcl9pZCI6IjU3NjI1MjI2MiJ9


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
Hi

Removing the CORS filter is not an option , as our site is serving the Web
pages as well and also the JSON data for the mobile app created in Phonegap.

@Chris: I checked the trunk code as well. If you see "dofilter()" method ,
it first do "checkRequestType ()" , where it checks for "isValidOrigin"
first. Based of the results it makes it INVALID CORS. .
I hacked the code and made "IsValidOrigin" always return true. Things
started working after that..


Hi, Ankit-

Where did you see <accept-origin> documented? I see an <init-param> 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".

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

-Terence Bandoian


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

Reply via email to