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

Feature request: allow setting allowed origin #214

Closed
dimhoLt opened this issue Aug 23, 2017 · 2 comments
Closed

Feature request: allow setting allowed origin #214

dimhoLt opened this issue Aug 23, 2017 · 2 comments
Milestone

Comments

@dimhoLt
Copy link

dimhoLt commented Aug 23, 2017

Hello!

I'm using the router for my RESTful JSON API, and intended to use the built-in options handler.

However, the built-in OPTIONS-handler is not aware of Access-Control-Allowed-Origins, making it meaningless for CORS-safe browsers. This means that if you are going to use the API with such browsers, you will have to build your own implementation of the OPTIONS-handler.

This would be fine, as it's a simple method, except that you no longer know which methods have registered handlers, and since the root-object is (correctly) not exported there's no way to extract this.

Solutions
There are, in my opinion, two potential solutions to this problem.

  1. Alongside the HandleOPTIONS-setting, add an AllowedOrigins []string-setting which, if not empty, sends the Access-Control-Allow-Origin-header with its data.

  2. On the router, add a method such as GetRegisteredMethods(path string) []string, or similar, returning an array of http.Method*-constants which can be easily strings.Join-ed into a custom Allow or Access-Control-Allow-Methods header, enabling a complete custom OPTIONS-handler.

I prefer the first option, as I believe it simply completes the HandleOPTIONS-setting which already exists.

@cristiangraz
Copy link

cristiangraz commented Oct 18, 2017

You can implement this yourself pretty simply -- we have a "framework" that standardizes multiple routers to add router groups, upstream/downstream middleware, context, CORS support, etc -- and implemented this exact thing for several routers. Most of the routers provide a way for you to match a path/HTTP method so you can create your own list of allowed routes to respond to CORS/OPTIONS requests.. You can see an example that has been working well for us here:
https://github.com/cristiangraz/kumi/blob/master/router/httprouter.go#L54-L65

@julienschmidt julienschmidt added this to the v1.3 milestone Sep 29, 2019
julienschmidt added a commit that referenced this issue Sep 29, 2019
julienschmidt added a commit that referenced this issue Sep 29, 2019
@julienschmidt
Copy link
Owner

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