Contribution offering: abstracted CORS configuration providers

[bdunogier]

Contributed as #15

We are currently implementing CORS support into our REST API at http://github.com/ezsystems/ezpublish-kernel.

As it turns out, this bundle really does what needs to be done, and it does it well. We have a partially working implementation, but I'm thinking that I'd like to use NelmioCorsBundle instead of writing our own thing.

But the thing is: we need to make some stuff dynamic (methods list per URI, etc).

I was thinking that we could propose support for some cors_request_matcher service tag. Those services would provide a couple methods used to check a CORS request. A default one would be implemented that uses the bundle's semantical configuration as a source.

What do you think ? Would you be willing to accept such a contribution.

NB: there is also a need for a security request matcher in order to ignore auth on preflight requests. We should be able to contribute that as well.

[Seldaek]

Sounds reasonable so I'd say go for it. Not sure I got the point about the security request matcher though, IIRC the security component is not an issue because we register our listener with a higher prio than the security one, but I could be wrong on that.

[bdunogier]

Nice, i'll work on the PR then !

About Security, there is a reasonable chance that we missed something. I'll see once the CorsBundle is integrated.

[lolautruche]

@bdunogier, @Seldaek is right. CorsListener has a priority of 10000, so far more than the security firewall 😄 . Furthermore, it does return a response when needed, so it will never go through the firewall. 👍

[stof]

regarding the CorsListener priority, it should be lower than that: it should run after the ProfilerListener, otherwise it could break it (this is not an issue anymore in 2.4 because the ProfilerListener has been refactored to use the RequestStack instead of managing its own stack)

[bdunogier]

See #15 for the pull-request.