Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CORS Handling #2

Open
ghivert opened this issue Nov 11, 2018 · 0 comments
Open

CORS Handling #2

ghivert opened this issue Nov 11, 2018 · 0 comments
Labels
design discussion Discussion about actual and future design

Comments

@ghivert
Copy link
Member

ghivert commented Nov 11, 2018

I'm still not sure about how to properly handle CORS in MilleFeuille. I personally always set my servers to be open from everywhere, because I'm mostly building SPA and open my API to anyone. This forces me to secure my servers correctly, but I think it's worth it.

I'm often making something like this:

const handleCORS = handler => request => {
  const response = handler(request)
  return Promise.resolve(response)
    .then(res => ({
      ...res,
      headers: {
        ...res.headers,
        'Access-Control-Allow-Origin': '*',
        'Access-Control-Allow-Methods': 'GET, PUT, POST, DELETE',
        'Access-Control-Allow-Headers': 'Content-Type'
      }
    }))
}

Of course, this could be served directly as a package from NPM, and everyone could be able to add it to their project when they need it. But MilleFeuille aims to be a central server for the future decade. So it should obviously think on SPA and micro-services above all. In micro-services, this is not a problem, but for SPA, it could quickly becomes complicated. For example we used to serve our front from Netlify for commodity, and creates custom API from Heroku or AWS (or whatever) for custom purposes. CORS are forced to achieve it.

So I'm thinking whether I should include them directly into the server options. Maybe something like:

const server = MilleFeuille.create(handler, {
  allowCORS: true
})

What I dislike about this approach is that it seems like it broke the contract we pass with our users "build your stack from the ground up, customized to your needs", because it packs more things the user can't change on its own. On the other hand, it easy things, and simplify process for boring stuff like CORS (which are alway painful for me), and remains modular, because it's always possible to handle CORS differently (because the handler function remains so simple, we can add CORS with third-party package). But it makes things simpler if getting the @frenchpastries/millefeuillle package is the only thing really needed to start your server without having to think "what other packages should I need?", especially if the CORS package only provides one unique middleware to add three headers instructions.

Maybe someone with more experience / more use cases in mind could help me on that subject? Maybe there is real utility for CORS I don't see right now (mostly because I can work without them)? Maybe they really are an essential security feature?

@ghivert ghivert added the design discussion Discussion about actual and future design label Nov 11, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
design discussion Discussion about actual and future design
Development

No branches or pull requests

1 participant