Closed PoOnesNerfect closed 5 months ago
Hi @jplatte I'm excited about this feature. My project currently relies on workarounds that this PR could replace, improving efficiency significantly. I'm eager to integrate it without resorting to forking. Can we expedite the merge process?
Hi @jplatte I'm excited about this feature. My project currently relies on workarounds that this PR could replace, improving efficiency significantly. I'm eager to integrate it without resorting to forking. Can we expedite the merge process?
It should be merged within today or tomorrow, assuming there are no other issues. Thanks for waiting.
Congratulations! Thanks for your work!
This PR allows using async predicate for
AllowOrigin
.Motivation
This is required when the allowed origins may change depending on the origin and the requested resource; this often requires accessing some external state such as a database or another service.
Pretty common use case is SaaS like CMS where a user makes API calls to your server from their client side. The user will provide the list of allowed origins that can access their data from the client side.
Solution
AllowOrigin
now has a functionasync_predicate
which takes a closure that returns a future that returnsbool
.Internally,
AllowOrigin::to_header
is nowAllowOrigin::to_future
which returns a futureAllowOriginFuture
that returnsOption<(HeaderName, HeaderValue)>
. For existing cases likeexact
,list
, orpredicate
, the future returns immediately with the values on the first poll, so it should not incur much (if any) overhead.One unfortunate thing about this feature is that, because the returned future needs to have a static lifetime, you cannot pass references to it like:
Instead, you must make sure all the values passed into the future have static lifetimes: