✅ Lagging IOptionsMonitorCache for openidconnnect
I’m configuring a openidconnect at startup but require a change to the scope based on dynamic runtime clientid for openidconnectoptions scope. When I run this, challengeasync willl redirect to external identity provider for login but with the previous scheme. When I hit back on browser, and authenticate again, the correct clientid is passed. It lags by one. I thought optionsMonitor.tryremove and tryadd before challengeasync would take care of this, but it isn’t. What am I missing?
7 Replies
yeah, PostConfigure isn't meant for that
PostConfiguration is a mechanism by which you can apply options changes AFTER the configuration step
I.E. when you have access to the
IServiceProvider
you don't call it
it's called automatically during startup
if you want to change options values at runtime, there's a different mechanism
I dunno, personally I think the concept of Microsoft.Extensions.Options
is great, but the execution is kinda.... horrific
there is NO clear mechanism for changing options at runtime
nor is there any real documentation about it
all the docs just assume you're using it in conjunction with Microsoft.Extensions.Configuration
where you can trigger a ConfigurationProvider to re-load and re-run its bindings at runtime
but, the whole damn POINT of the options library being separate from configuration is that you don't have to do that
the closest I can find is....
IOptionsMonitorCache<TOptions> is used by IOptionsMonitor<TOptions> to cache TOptions instances. The IOptionsMonitorCache<TOptions> invalidates options instances in the monitor so that the value is recomputed (TryRemove). Values can be manually introduced with TryAdd. The Clear method is used when all named instances should be recreated on demand.which is under the ASP.NET Core doucmentation, instead of the Options library documentation and which SEEMS to me to suggest that's what you should use to change options at runtime but you claim that's not working properly if it were me, this would be the point that I just make my own service for managing this
It’s almost working, just one scheme behind each claim. I wonder if I should just reload the page with js on first attempt because each subsequent load is correct
there's gotta be a better solution than that
if you wanna stick with tge options lib, I think you're gonna have to start source diving
I have been, I’m going to make it work
lemme know if you figure out the underlying issue
I'm definitely curious
Was this issue resolved? If so, run
/close
- otherwise I will mark this as stale and this post will be archived until there is new activity.Answer was redirect to another action then ChallengeAsync(), so the postconfigure options could propagate through the context of the framework I’m using