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
