CORS allow_origins to take future predicate

[PoOnesNerfect]

I think it may be useful to have allow origin to take future as a predicate as an option.

I have a fork that does this, and opened a PR against my own forked main branch, because I wanted to discuss before just opening a PR.

Please take a look when you have time; it's totally fine if it's not something that should be part of the library.
Implementation may also not be ideal.

thuo-io#1

[jplatte]

Hi. The implementation looks solid at first glance, but can you expand on what you need(ed) this for?

[PoOnesNerfect]

Thank you.
My use-case is sort of a content management service:

1. users can store data on my backend, and they can set allowed origins that can access the data from the client side.
2. From user's sites, the client fetches data from my backend.
3. My backend server, on receiving CORS request, looks up if the resource that's being fetched is allowed for the origin, set by the user.

So, it requires dynamically fetching allowed origins from database/cache to see the origin requesting the resource is allowed.

I think a decent number of SaaS that allow fetching user data from the client side have these approaches.

So, I thought it may be useful for others as well.

[jplatte]

I suppose that makes sense. Can you open a PR against this repo? And two small nitpicks already:

• Can you rename the new AllowOrigin::future constructor to async_predicate?
• Can you change its argument type from -> BoxFuture<...> to -> Fut where Fut is a second generic parameter that implements Future? (if you can't figure this one out I can also adjust the PR after you've created it)

[PoOnesNerfect]

yep, I'll create a PR. Thank you.

[PoOnesNerfect]

Opened the pr: Allow async predicate for cors AllowOrigin #478