General CORS library

Question

General CORS library

CrowdHailer opened this issue 6 years ago · comments

This is pretty close to a feature request, but it looks like the right place for it and I'm willing to do much of the work.

Is there any interest in making this a general CORS library, i.e. not just a plug.

I think work needed would be

make some private functions public. e.g. https://github.com/mschae/cors_plug/blob/master/lib/cors_plug.ex#L78
Only compile the cors_plug if plug is installed, by using Code.ensure_loaded?
Consider renaming the project to cors on hex. It is still available.

Why.

a) Useful in tests of APIs to check that the headers include the expected CORS headers
b) I, and quite a few others, use Raxx/Ace

Michael Schaefermeyer · Answer 1 · Fri Jan 04 2019 19:49:59 GMT+0800 (China Standard Time)

Hey and thanks for your input. I understand the need for a generalized CORS library.

I wonder if the plan you laid out is the way to go or whether we should have a separate package (maybe creatively named cors) that includes all the functionality and make cors_plug use that package.

Not sure which way I prefer...

Peter Saxton · Answer 2 · Fri Jan 04 2019 21:05:47 GMT+0800 (China Standard Time)

I can see why the second one might sound a good idea, but perhaps later on.

While the API is being developed/discovered I normally think it is better to have everything in one repo.

Main reason I would do as you suggest is because I'm not sure how well hex.pm handles renaming packages

Peter Saxton · Answer 3 · Sat Jan 05 2019 22:09:29 GMT+0800 (China Standard Time)

I've started a spike at a CORS middleware for Raxx. https://github.com/CrowdHailer/raxx/pull/157/files#diff-145629a0af7f990c2e3f756d6625052aR7

I now reckon just exposing a CORS.check(method, headers, config) is the simplest generic API.
Rather than having functions like check_origin and requiring each of plug/raxx/other to combine them in the correct order