Ability for CORS domains to be evaluated at runtime via service #63011
Description
Is there an existing issue for this?
- I have searched the existing issues
Is your feature request related to a problem? Please describe the problem.
Situation: We have embedded resources that can be added to our customer's websites that run under ___domain ABC, and that needs to communicate with our backend that lives at XYZ. This is dynamic and we would not like to be creating separate policies for any ___domain any time we have a new customer.
We have a ___domain setup process where our customer's domains are stored on our side, very similar to allowing redirect urls of OAuth. This problem is conceptionally resolving an origin at runtime to decide if it's allowed for CORS.
Today, there are two options I can think of to allow the concept of Dynamic CORS origins evaluated at runtime:
- implementing custom middleware - this middleware would have to re-invent the CORS wheel and fetchspec, not ideal.
- Inheriting and overriding the exiting CorsService, ICorsService .Evaluate and .Apply methods and DI-ing that in place of the canned CorsService. (this is the option I'm using today)
some issues with option 2: We can't resolve any scoped services here, only transient/singleton, which can be a pain for multi-tenancy in some setups (namely ours). this leads to having to tack things on to the httpContext.Items array in other scoped middleware for use during the CORS policy step, which feels janky.
Describe the solution you'd like
It would be great to have a policy option that has a Func<> able to load an IServiceProvider to resolve a service that decides if a ___domain was valid or not. I don't think scoped service is required here but a nice to have. This way a lookup service, caching, etc, can all be leveraged and injected at runtime when deciding if the Origin was valid and allowed for a CorsPolicy.
Think of this as the existing .SetIsOriginAllowed(___domain => ) on steroids.
Additional context
No response