`ClientConfigurationStore` depends on `ConfigurationDbContext` instead of the `IConfigurationDbContext` interface

[aurecchia]

Hi folks 👋

Which version of Duende IdentityServer are you using?

7.0.7

Which version of .NET are you using?

SDK 8.0.300

Describe the bug

Not exactly a bug, more an inconvenience. We added the configuration API to our instance of IdentityServer (shared host setup), and we had dependency injection issues with the ClientConfigurationStore.

We have a custom implementation of ConfigurationDbContext that inherits from the Duende one to customize the OnModelCreatingMethod. Our custom type is registered in DI instead of the built-in one. The ClientConfigurationStore depends on the concrete type from Duende. This means that we cannot just call .AddClientConfigurationStore() like shown in the documentation, but have to provide our own implementation of the ClientConfigurationStore.

Is there a reason why the dependency is on the ConfigurationDbContext class instead of the IConfigurationDbContext interface?

I wanted to understand if this was done deliberately before opening a PR.

To Reproduce

• Inherit from ConfigurationDbContext and register the custom implementation
• Register the ClientConfigurationStore using .AddClientConfigurationStore()

An error will be thrown when the ClientConfigurationStore is first instantiated or when DI scope validation runs.

Expected behavior

It should be possible to use the built-in ClientConfigurationStore with custom ConfigurationDbContext and using the provided configuration extensions.

Let me know if you require additional details or I can help in any other way.

[AndersAbel]

It looks like our code does not work that well with a custom configuration context.

For now, you can add a workaround by registering your own implementation class with the ConfigurationDbContext service registration:

services.AddScoped<ConfigurationDbContext>(svcs => 
  svcs.GetRequiredService<MyDerivedConfigurationDbContext>());

This need to be done after the call to AddConfigurationStore, because it need to overwrite the built in service registration.

[aurecchia]

Hi @AndersAbel

Thanks for getting back to us. We were able to put in place a slightly different work-around, but things are working anyway.

I guess this can be closed since the issue is tracked by #1616