Registering Transient Stores

[ChristianRiedl]

I am working with idsrv4 using your EF persistence 👍 .
I see this potential problem :

Idsrv4, inside AddIdentityServer always registers the InMemory transient stores
public static IServiceCollection AddInMemoryTransientStores(this IServiceCollection services) { services.TryAddSingleton<IAuthorizationCodeStore, InMemoryAuthorizationCodeStore>(); services.TryAddSingleton<IRefreshTokenStore, InMemoryRefreshTokenStore>(); services.TryAddSingleton<ITokenHandleStore, InMemoryTokenHandleStore>(); services.TryAddSingleton<IConsentStore, InMemoryConsentStore>(); return services; }

Then your code registers the EF based stores :

public EntityFrameworkOptions RegisterOperationalStores<TOperationalContext>() { _builder.Services.AddScoped<OperationalContext, TOperationalContext>(); _builder.Services.AddScoped<IAuthorizationCodeStore, AuthorizationCodeStore>(); _builder.Services.AddScoped<ITokenHandleStore, TokenHandleStore>(); _builder.Services.AddScoped<IConsentStore, ConsentStore>(); _builder.Services.AddScoped<IRefreshTokenStore, RefreshTokenStore>(); return this; }

So this stores are registered twice, once a singleton once in scoped mode. I am not sure what happens if the same Interface is registered twice.

[jarroda]

Hmm, let me investigate this... Thanks for the heads up.

[ChristianRiedl]

Today I tested AspNetCores DI and I found out that you can register different implementation classes with different modes (singleton, transient, scoped) for the same service interface. When DI has to resolve the interface it uses always the last registered implementation class.

I also made some performance tests for the EF "find object" operations. It typically costs some milliseconds. So I think in real world it is necessary to cache this objects.