[play-2.4.0-rc1] [play-java] CORS filter not working

792 views
Skip to first unread message

Nicolaas Frederick Huysamen

unread,
May 4, 2015, 1:53:01 PM5/4/15
to play-fr...@googlegroups.com
I have implemented the CORS filter as suggested at:


but to no avail. I can see the OPTIONS response is successful, and does contain some of the CORS headers, but the following POST still fails, and inspecting with FireBug it is a CORS issue. It looks as though the filter ignored the play.filters.cors.* options on the application.conf file. Regardless of what I specify there (i.e. ["*"] for pretty much everything), I always het the same response back, which allows a very small subset, not including all the headers in the following POST request.

Nicolaas Frederick Huysamen

unread,
May 4, 2015, 1:59:15 PM5/4/15
to play-fr...@googlegroups.com
To elaborate, in my application.conf I have:

# CORS
play.filters.cors.allowOrigins = ["*"]
play
.filters.cors.allowHttpMethods = ["GET", "PUT", "POST", "DELETE", "OPTIONS"]
play
.filters.cors.allowHttpHeaders = ["Accept", "Authorization", "Content-Type", "Origin", "Referer", "User-Agent", "X-Requested-With"]


But in my OPTIONS response, I receive:

Access-Control-Allow-Cred...true
Access-Control-Allow-Head...content-type
Access-Control-Allow-Meth...POST
Access-Control-Allow-Orig...http://localhost:8100
Access-Control-Max-Age3600
Content-Length0
VaryOrigin

which seems to completely ignore the configuration.

Nicolaas Frederick Huysamen

unread,
May 4, 2015, 2:05:10 PM5/4/15
to play-fr...@googlegroups.com
OK, looking at the reference.conf in the filters plugin, it seems the names have changed to:

...
allowedOrigins
allowedHttpMethods
allowedHttpHeaders

but alas, now even the OPTIONS method fails, even with everything set to "*"


On Monday, 4 May 2015 19:53:01 UTC+2, Nicolaas Frederick Huysamen wrote:

Nicolaas Frederick Huysamen

unread,
May 4, 2015, 2:22:49 PM5/4/15
to play-fr...@googlegroups.com
Looking even further at the issue, it seems that is has to do with the CORS filter (or Filters in general) not playing well with ErrorHandler. When throwing something like a validation exception, which gets caught in the error handler and transformed into a uniform validation error json response, it seems that the CORS filter is not applied again. This seems a bit counter-intuitive.


On Monday, 4 May 2015 19:53:01 UTC+2, Nicolaas Frederick Huysamen wrote:

Nicolaas Frederick Huysamen

unread,
May 4, 2015, 2:37:03 PM5/4/15
to play-fr...@googlegroups.com
It is definitely the ErrorHandler. Changing the code to return the badRequest result form the controller (instead of throwing an exception that gets handled in the ErrorHandler), then the CORS filter works perfectly.

Nicolaas Frederick Huysamen

unread,
May 4, 2015, 4:05:49 PM5/4/15
to play-fr...@googlegroups.com
Last comment. With the above in place, with CORS working (from the same machine), it seems it still does not work when requesting from a machine with a different IP...
Reply all
Reply to author
Forward
0 new messages