NelmioCorsBundle
NelmioCorsBundle copied to clipboard
nelmio
Abstract CORS handling into a separate library
A quick search on packagist for cors (https://packagist.org/search/?q=cors) shows me there are a dozen or so projects that address CORS subject but NelmioCorsBundle is by far the most popular and mature of them.
Therefore my question: is there a chance that the the functionality of this bundle be part of a non Symfony dependant library?
As you can see all existing packages target specific frameworks, because this functionality is very tied to the request/response. I'll try to look over the code a bit and see if it can be abstracted, but I'm not sure yet if it makes sense.
@Seldaek the event listener implementing the logic could be usable in any HttpKernel based project (I mean a project using the HttpKernel implementation of the interface, so dispatching the kernal events). this includes Symfony, Silex, flint (which is based on Silex), Drupal 8, and many other stuff. Only the configuration layer actually depend on the framework.
The dependency could be changed to depend on HttpKernel and EventDispatcher, and only suggest FrameworkBundle. This way, all HttpKernel-based project can reuse the logic (with the need to configure it themselves). For instance, this would allow providing a clean implementation of a Silex CorsProvider (the existing one is really hacky)
@stof to add to your above comment: this is exactly what http://stackphp.com is trying to achieve: framework-agnostic HTTP filters! As a matter of fact there is already a stack-cors implementation at https://packagist.org/packages/asm89/stack-cors But it's not as mature as the code in this Bundle and obviously not as popular hence my initial request.
@Seldaek if you are ok in principle with this "feature" we then agree an approach to attack it. As far as I can see we have 2 options:
- abstract away the functionality in a base class (within this same bundle) that can be used by other projects
- we could make this bundle dependant on a separate base library which implements the actual functionality based on HttpFoundation, EventDispatcher and Response components;
Actually we could do both options :)
@andreiashu Except that stackphp cannot be as feature-rich as a listener running inside your app, except by duplicating the routing logic, as it cannot know the allowed methods for instance (it has to allow the same methods for all urls).
And abstracting the base functionality without depending on the Response does not make sense IMO. the base functionality is precisely about dealing with a response. Creating an abstraction of the Response object is not worth it IMO.
@andreiashu I know my repository is called stack-cors but it's actually a library working with sf2 Request/Response and a small stackphp integration. The CORS part is already well tested, I'd be more than happy to work it out to a full library.
Some additional background: I started the stack-cors project after I needed CORS support in a Silex application. At first I wanted to extract the CORS logic from this bundle, but at the time there were no tests. I wrote tests following the CORS spec and than wrote the library with it. I even discussed/offered @Seldaek to integrate the CorsService in this bundle to join efforts.
I'd be more than happy to look into the possibilities to add some extra functionality to the lib (so it can be integrated with for example allowed methods on routing via events etc). (Also see this comment: https://github.com/asm89/stack-cors/pull/2#issuecomment-31161888).
I created https://github.com/barryvdh/laravel-cors based on this library, but would we happy to use an existing CORS middleware, where I only have to register the settings and register the middleware. Is there still interest in creating a generic library, so nothing has to be duplicated?
@barryvdh you could use @asm89's package for this as far as I know since Laravel is also based on symfony's http-foundation.
Yes https://github.com/asm89/stack-cors is quite good, I've been using it in a Silex project.