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

[request] Some mechanism to add CORS-rules to an endpoint/a router/everything. #31

Open
megri opened this issue May 4, 2020 · 3 comments

Comments

@megri
Copy link
Contributor

megri commented May 4, 2020

Here's what I've found so far:

  • Adding a custom decorator won't work for OPTIONS-requests as the routes are tried before the decorators come into play.
  • Overriding the Main#defaultHandler seems to be the way forward but this feels very "low-level" and introduces some concern-splitting

I'm willing to do some legwork here but I'd like to know if you have any ideas on how this can best be solved.

@jodersky
Copy link
Member

jodersky commented May 6, 2020

Overriding the Main#defaultHandler seems to be the way forward but this feels very "low-level" and introduces some concern-splitting

Would it be possible to put into a trait? I could imagin that a user who needs cors could just mix in the trait to their routes.

@megri
Copy link
Contributor Author

megri commented May 7, 2020

I think it's a bit trickier—but I may be wrong.

To add CORS in a somewhat convenient manner we'd need to:

  • For simple requests, make sure we attach the proper response headers;
  • For preflighted requests
    • intercept OPTIONS requests for all routes and attach an Access-Control-Allow-Methods response header, listing all methods defined on the endpoint;
    • allow configuration of the Origin header and filter incoming requests based and
      1. attach an Access-Control-Allow-Origin with the correct origin if it is allowed or;
      1. reject(?) the request (not sure exactly, I'm new to the CORS specification);
  • also handle/attach headers for Access-Control-Allow-Headers and such.

Preferably it should be possible to configure at least some of these aspects.

To get access to an endpoint's allowed methods the only way I found was to apply the CORS-rules to cask.Main by overriding defaultHandler : non-endpoint decorators do not have information about the downstream endpoint, and from my experiments there can only be one endpoint decorator for any given route. This also means the interface you're working against is the underlying undertow (I feel potential in creating more abstraction here, to make it possible to inject custom handling/filtering at the edge of cask, but that's a story on its own.)

Perhaps it is possible to wrap an endpoint decorator with a cors-decorator? That would make things slightly simpler—provided the cors-decorator can access the endpoint-decorator—but would still have to be repeated for all endpoints of a route, as I see no way to automatically attach one.

@objektwerks
Copy link

objektwerks commented Mar 7, 2022

FYI, I've built a CorsHandler that works in initial tests. See:

Naturally, this can be built multiple ways. Note how a CorsHandler is initialized in Server, which extends cask.Main.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants