Please describe your use case / problem.envoy-proxy allows for more control over the CORS allowed origins than is exposed by ambassador. For instance, they allow for prefix, suffix and regex matching, not just exact matching.
Describe the solution you'd like
I'd like to be able to take advantage of the functionality provided by envoy-proxy that is currently masked by Ambassador.
For instance, one may have an API service fronted by Ambassador (api.example.com) and several peer or subdomains that wish to access it (www.example.com, feature-branch-1.dev.example.com, etc.). Allowing suffix matching would solve this handily, especially since the CORS spec disallows hardcoded wildcards other than "*" and even that has its own issues when working with credentialed requests.
Describe alternatives you've considered
I suppose one could forego the Ambassador CORS configuration and do a heavy-handed lua script to replicate this functionality, but that seems less than ideal. I don't know if there's a way to do an end-run around Ambassador to set these settings directly on envoy-proxy itself, but that also seems needlessly cumbersome when we could pass them through Ambassador.
Additional context
I have taken a stab at updating the v2/Mapping JSONSchema (backwards compatible, I believe) to accept the documented value types and have updated ircors.py to process the new values. See that work here. I don't know how to test this yet and I'm sure there's a fair amount of effort involved in updating docs and test cases. I'm just hoping to get this ball rolling. Feel free to riff on that commit if it proves useful. I wouldn't mind helping out with updating the docs.
I found this issue #3020 shortly after creating this one. Sorry for the spam, but it looks like I'm not the only one looking for this feature.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Please describe your use case / problem.
envoy-proxy
allows for more control over the CORS allowed origins than is exposed by ambassador. For instance, they allow for prefix, suffix and regex matching, not just exact matching.See here and here for details.
Describe the solution you'd like I'd like to be able to take advantage of the functionality provided by
envoy-proxy
that is currently masked by Ambassador.For instance, one may have an API service fronted by Ambassador (
api.example.com
) and several peer or subdomains that wish to access it (www.example.com
,feature-branch-1.dev.example.com
, etc.). Allowing suffix matching would solve this handily, especially since the CORS spec disallows hardcoded wildcards other than"*"
and even that has its own issues when working with credentialed requests.Describe alternatives you've considered I suppose one could forego the Ambassador CORS configuration and do a heavy-handed lua script to replicate this functionality, but that seems less than ideal. I don't know if there's a way to do an end-run around Ambassador to set these settings directly on
envoy-proxy
itself, but that also seems needlessly cumbersome when we could pass them through Ambassador.Additional context I have taken a stab at updating the
v2/Mapping
JSONSchema (backwards compatible, I believe) to accept the documented value types and have updatedircors.py
to process the new values. See that work here. I don't know how to test this yet and I'm sure there's a fair amount of effort involved in updating docs and test cases. I'm just hoping to get this ball rolling. Feel free to riff on that commit if it proves useful. I wouldn't mind helping out with updating the docs.I found this issue #3020 shortly after creating this one. Sorry for the spam, but it looks like I'm not the only one looking for this feature.