Open rastrup opened 1 year ago
Agreed. The library should not make any assumptions on where the user has its Configuration values stored.
Taking a dependency on the IConfiguration abstractions from netcore is fine. But then accept an IConfiguration instance for when building the TokenAcquirerFactory
or the call to AddMicrosoftIdentityWebApp
. And use that.
Making assumptions that a client application always uses the appsettings.json is wrong. Besides that this hurts the most for NET Framework solutions, its also wrong for NETCORE solutions. Because there are plenty of occasions where people use environment flags to load in different config files specific for each environment. For example appsettings.dev.json, appsettings.test.json, etc etc.
The current code always forces you to put everything in appsettings.json.
If we want to use anything else, we need to inherit the TokenAcquirerFactory class, and override the DefineConfiguration
method to provide our own.
Is your feature request related to a problem? Please describe. For MVC .Net Framework OWIN solutions. The solution for .Net Framework OWIN projects makes it possible to use an appsettings.json file for configuration values. But for some basic values inside AddMicrosoftIdentityWebApp and AddMicrosoftIdentityWebApi there is no simple way to use anything but the appsettings.json values. I am talking about the lines 121-124 inside AppBuilderExtension.AddMicrosoftIdentityWebApp
string instance = configuration.GetValue<string>($"{configurationSection}:Instance"); string tenantId = configuration.GetValue<string>($"{configurationSection}:TenantId"); string clientId = configuration.GetValue<string>($"{configurationSection}:ClientId"); string postLogoutRedirectUri = configuration.GetValue<string>($"{configurationSection}:SignedOutCallbackPath");
And the same for AppBuilderExtension.AddMicrosoftIdentityWebApi
Most other values can be set via configuration values in the configureMicrosoftIdentityApplicationOptions input but not these.