It appears `Access-Control-Allow-Origin: *` in the HTTP header is not enough to allow cross-site scripting. More headers, and HTTP methods, are required to unlock browsers' ability to send requests to the ActiveData server. Specifically, at least `Access-Control-Allow-Methods` and `Access-Control-Allow-Headers`. These appear to be white-listing header properties, but the extent they apply in practice is currently a mystery to me. Some of my dumb questions are: * What does it mean to "Allow-Headers"? In the case of "Content-Type", can we actually disallow "Content-Type" headers? * What other headers are gated by "Allow-Headers"? If I find <header> is not gated, how do I distinguish between a browser implementation failure and a legitimate part of the spec? How do I get informed of changes to the CORS spec as more headers are added to the list of gated headers? * It would be nice if "*" works for all the "Access-Control-*" headers. Does it? Certainly, with enough hours dedicated to research and experimentation, all these questions can be answered. Plus, a comprehensive test suite is required to be reasonably assured we can deal with the variations in implementation, ensure we have not broken other communications, and provide alerts when CORS spec/implementation inevitably change. This makes me sad, I hope there is a faster way. There may be a communications library  that manages the client communication required to establish the required client permissions. Hopefully its API has a "just work" option, unlike CORS.  https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Preflighted_requests  https://flask-cors.readthedocs.io/en/latest/  http://flask.pocoo.org/snippets/56/
Some discussion about "*" http://stackoverflow.com/questions/13146892/cors-access-control-allow-headers-wildcard-being-ignored including possible dynamic solutions: resp.setHeader("Access-Control-Allow-Headers", req.getHeader("Access-Control-Request-Headers"));
You need to log in before you can comment on or make changes to this bug.