router
router copied to clipboard
Dynamic CORS header configuration
Description
This is perhaps something that will require out-of-tree extensions or more extensive YAML configuration, as it asks for the ability to run conditionals on the origin. E.g.:
- [x] If the domain ends with zyx.com #965
- [ ] If the path includes
/admin/
(likely regex) - [ ] If the user passed a header
I thought we'll be able to use router as a library where we can do everything that can be done with apollo gateway today in nodejs, I'd think it'd be a middleware. Is that not the case anymore?
@cyberhck This issue is about building out a particular feature, not a general conversation about how the Gateway and Router will work similarly/differently or precisely how the all the same functionality will be offered — those are going to be their own specific conversations which live in different tickets. I don't personally think it did, but if what I said above suggested to you that something was changing about the way the Router will work in terms of general design principles, I didn't mean to convey that! 😅
I'll briefly try to explain some of our intent but still want to note that, unless I'm misunderstanding, I think any larger conversation about this is probably off-topic for this issue:
As this particular issue suggests itself, much like the Gateway, functionality in the Router will sometimes be implemented natively, sometimes via configuration and other times there will be other avenues (e.g., extensions of sorts). It's worth noting that the Router is written in Rust, not Node.js, so implementations will vary from what you have today.
One hope here is that the Router might offer improved solutions over implementations in the Gateway, or solutions that necessitate less complexity. CORS header configuration is just one example. Of course, if you're comfortable writing Rust, you're certainly able to use this as a library: This is the Git repository that you'd checkout to make any customizations you'd necessitate that we haven't built solutions that don't require compiling your own binary. Feel free to do that, but we definitely hope that everyone doesn't need to always compile the Router to use it though, and exploring configuration is a way to potentially avoid that.
Hope this helps alleviate any concerns you had!
I feel like now that we're closing in on extensibility, we might give this one a go!
The Router now supports Regex configuration of CORS origins based on the work in https://github.com/apollographql/router/pull/1444. The remaining piece of this issue is now entirely to allow something more dynamic by enabling Rhai to be used to selectively enable or disable CORS based on other context (like request headers, an external network request, or something along those lines).
We'll close this for now as the flexibility you can get with regex for CORS is actually pretty good for most cases but feel free to open a new issue if your needs don't match what's currently offered. thanks!