Re: CORS issue with Tomcat and Android Webview
On 4/29/2014 3:48 AM, Jose María Zaragoza wrote: 2014-04-29 0:38 GMT+02:00 Terence M. Bandoian tere...@tmbsw.com: 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 tere...@tmbsw.com: On 4/26/2014 6:56 AM, Jose María Zaragoza wrote: 2014-04-26 13:16 GMT+02:00 Martin Gainty mgai...@hotmail.com: 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 tere...@tmbsw.comwrote: 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: 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
On 4/28/2014 3:21 PM, Konstantin Kolinko wrote: 2014-04-28 23:44 GMT+04:00 Terence M. Bandoian tere...@tmbsw.com: On 4/27/2014 11:36 AM, Konstantin Kolinko wrote: 2014-04-27 0:50 GMT+04:00 Terence M. Bandoian tere...@tmbsw.com: 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 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. 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 ] ; 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
2014-04-29 0:38 GMT+02:00 Terence M. Bandoian tere...@tmbsw.com: 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 tere...@tmbsw.com: On 4/26/2014 6:56 AM, Jose María Zaragoza wrote: 2014-04-26 13:16 GMT+02:00 Martin Gainty mgai...@hotmail.com: 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 tere...@tmbsw.comwrote: 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: 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
-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 tere...@tmbsw.com: 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 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. 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 ] ; 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
On 4/27/2014 11:36 AM, Konstantin Kolinko wrote: 2014-04-27 0:50 GMT+04:00 Terence M. Bandoian tere...@tmbsw.com: 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 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. 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 ] ; 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
On 4/26/2014 6:56 AM, Jose María Zaragoza wrote: 2014-04-26 13:16 GMT+02:00 Martin Gainty mgai...@hotmail.com: 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 tere...@tmbsw.comwrote: 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: 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
2014-04-28 21:55 GMT+02:00 Terence M. Bandoian tere...@tmbsw.com: On 4/26/2014 6:56 AM, Jose María Zaragoza wrote: 2014-04-26 13:16 GMT+02:00 Martin Gainty mgai...@hotmail.com: 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 tere...@tmbsw.comwrote: 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: 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
2014-04-28 23:44 GMT+04:00 Terence M. Bandoian tere...@tmbsw.com: On 4/27/2014 11:36 AM, Konstantin Kolinko wrote: 2014-04-27 0:50 GMT+04:00 Terence M. Bandoian tere...@tmbsw.com: 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 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. 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 ] ; 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
On 4/28/2014 3:21 PM, Konstantin Kolinko wrote: 2014-04-28 23:44 GMT+04:00 Terence M. Bandoian tere...@tmbsw.com: On 4/27/2014 11:36 AM, Konstantin Kolinko wrote: 2014-04-27 0:50 GMT+04:00 Terence M. Bandoian tere...@tmbsw.com: 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 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. 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 ] ; 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
On 4/28/2014 3:08 PM, Jose María Zaragoza wrote: 2014-04-28 21:55 GMT+02:00 Terence M. Bandoian tere...@tmbsw.com: On 4/26/2014 6:56 AM, Jose María Zaragoza wrote: 2014-04-26 13:16 GMT+02:00 Martin Gainty mgai...@hotmail.com: 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 tere...@tmbsw.comwrote: 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: 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
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 tere...@tmbsw.com: On 4/26/2014 6:56 AM, Jose María Zaragoza wrote: 2014-04-26 13:16 GMT+02:00 Martin Gainty mgai...@hotmail.com: 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 tere...@tmbsw.comwrote: 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: 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
2014-04-27 0:50 GMT+04:00 Terence M. Bandoian tere...@tmbsw.com: 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 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. 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 ] ; 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
On Sat, Apr 26, 2014 at 12:53 AM, Terence M. Bandoian tere...@tmbsw.comwrote: 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.comwrote: 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
RE: CORS issue with Tomcat and Android Webview
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
tere...@tmbsw.comwrote:
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.
MGreferencing the request processing flowchart at
MGhttps://tomcat.apache.org/tomcat-7.0-doc/images/cors-flowchart.png
MGyou will need to carefully shepherd your request thru TC
Valve/Filter/ServletProcessing gauntlet
MGdid you supply a valid origin header?
MGhttp://en.wikipedia.org/wiki/List_of_HTTP_header_fields
MGdid you supply a valid request method e.g. POST/GET?
MGAndroid is a much diffferent User-agent than Browser and you will need to
set the request headers properly
MGHttpConnection 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 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.comwrote:
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
Re: CORS issue with Tomcat and Android Webview
2014-04-26 13:16 GMT+02:00 Martin Gainty mgai...@hotmail.com: 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 tere...@tmbsw.comwrote: 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: 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
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 mgai...@hotmail.com:
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
tere...@tmbsw.comwrote:
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:
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 ?
MGyou 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
On 4/26/2014 1:13 AM, Ankit Singhal wrote: On Sat, Apr 26, 2014 at 12:53 AM, Terence M. Bandoian tere...@tmbsw.comwrote: 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.comwrote: 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
Re: CORS issue with Tomcat and Android Webview
-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 accept-origin*/accept-origin 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
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.comwrote: 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.comwrote: 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
Re: CORS issue with Tomcat and Android Webview
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. -Terence Bandoian On Tue, Apr 22, 2014 at 9:22 PM, Ankit Singhal ankising...@gmail.comwrote: 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.1http://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: filter filter-nameCorsFilter/filter-name filter-classorg.apache.catalina.filters.CorsFilter/filter-class init-param param-namecors.allowed.origins/param-name param-value*/param-value /init-param /filter filter-mapping filter-nameCorsFilter/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=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.eyJhbGdvcml0aG0iOiJITUFDLVNIQTI1NiIsImNvZGUiOiJBUUQ0UEZZVXE4eDFIa3V6OW9RV3RlVzE4clQ3SmtVRjBzU1VVcXhfV1BENG8tV1BZYjZuTVdDdDJGMmw4TjJUeUxLSzhIYUU1TUc2MkY5cXZOaXRMN3NGdklNZkhySmluYkdjMWs1THAyZnZYa2Zpa1lLVGJ0OWlZeXVvRDNWUDhTblp4czJCeTQ4RTlYY1ZjUmhGWGJsN
Re: CORS issue with Tomcat and Android Webview
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 -Terence Bandoian On Tue, Apr 22, 2014 at 9:22 PM, Ankit Singhal ankising...@gmail.comwrote: 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.1http://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: filter filter-nameCorsFilter/filter-name filter-classorg.apache.catalina.filters.CorsFilter/filter-class init-param param-namecors.allowed.origins/param-name param-value*/param-value /init-param /filter filter-mapping filter-nameCorsFilter/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
Re: CORS issue with Tomcat and Android Webview
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.comwrote: 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.1http://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-nameCorsFilter/filter-name
Re: CORS issue with Tomcat and Android Webview
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... On Fri, Apr 25, 2014 at 1:36 AM, Terence M. Bandoian tere...@tmbsw.comwrote: 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.comwrote: 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
Re: CORS issue with Tomcat and Android Webview
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 ankising...@gmail.comwrote: 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.1http://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: filter filter-nameCorsFilter/filter-name filter-classorg.apache.catalina.filters.CorsFilter/filter-class init-param param-namecors.allowed.origins/param-name param-value*/param-value /init-param /filter filter-mapping filter-nameCorsFilter/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=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
Re: CORS issue with Tomcat and Android Webview
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 ankising...@gmail.comwrote: 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.1http://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: filter filter-nameCorsFilter/filter-name filter-classorg.apache.catalina.filters.CorsFilter/filter-class init-param param-namecors.allowed.origins/param-name param-value*/param-value /init-param /filter filter-mapping filter-nameCorsFilter/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=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
Re: CORS issue with Tomcat and Android Webview
-- 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 ? On Tue, Apr 22, 2014 at 9:22 PM, Ankit Singhal ankising...@gmail.comwrote: 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.1http://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: filter filter-nameCorsFilter/filter-name filter-classorg.apache.catalina.filters.CorsFilter/filter-class init-param param-namecors.allowed.origins/param-name param-value*/param-value /init-param /filter filter-mapping filter-nameCorsFilter/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=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
