Why doesn't AddCors or AddJwtBearer have support for getting a registered DI/IoC item?

[PureKrome]

Hi folks,

So we have AddCors and AddJwtBearer in our code. both of these have some specific code to set values which are based on Configuration.

for example:

The allowed origins are defined in configuration files/environment variables.

Likewise with setting up authentication's AddJwtBearer .. we have this:

again, some settings via configuration.

I couldn't find any way to grab this from the existing DI/IoC if we have previously registered it. My guess is that the above code is still being handled/called during registration of all our services.

So could this be added to the code? Would this mean that cors and jwtsettings would be setup upon first instansiation / request of the instance/data?

It's like I wish to load all configuration data before configuring any services .. but this problem is that i load configuration settings during service configuration (into IOptions<SomeConfigSection>).

so confused :(

[pinkfloydx33]

Those are just the initial setting values, you can still configure the values after the calls to AddCors/AddJwtBearer but before the service provider is built. Just register IConfigureOptions<CorsOptions> or IConfigureOptions<JwtBearerOptions> and inject your configuration dependencies into those. You can then use Configure (or PostConfigure with IPostConfigureOptions<>) to complete the configuration using your dynamic values

[PureKrome]

Hi @pinkfloydx33 - sorry for the late reply. I don't understand this :(

can you provide some code example?

[pinkfloydx33]

Something like the below (typing from mobile so may not be exactly correct). You can inject any DI service, including IConfiguration or IOptions<>

public sealed class ConfigureMyJwtOptions(ISomeService myService) : IPostConfigureOptions<JwtBearerOptions>
{
    public void PostConfigure(string name, JwtBearerOptions opts) 
    {
        // limit to the specific JWT  registration since you can technically have multiples by 
        // checking the name matches the one you used in the call to AddJwtBearer. 
        // If you don't specify one it uses the name from JwtBearerDefaults.
        // Or you can ignore the name parameter and apply to all JetBearerOptions
        // if (name == JwtBearerDefaults.AuthenticationScheme) {...} 
        opts.TokenValidationParameters.ValidIssuer = myService.GetIssuer();
    } 
}
// in startup 
services.ConfigureOptions<ConfigureMyJwtOptions>();

Or implement IConfigureOptions<> and it's Configure method. Registration order matters; since AddJwtBearer also registers options configuration you'd either need to call ConfigureOptions before AddJwtBearer to ensure your configuration takes precedence, or you can use IPostConfigureOptions like my example which will run after all other options setup

[PureKrome]

oh even better!

[pinkfloydx33]

Personally I avoid this route and will almost always use IConfigureOptions/IPostConfigureOptions implementations, especially since those then because very easily unit testable.

[PureKrome]

Can you provide an example of using IConfigureOptions please? to compare to the .Configure<...> example.

[pinkfloydx33]

I did above.... But here's another one

public sealed class ConfigureMyCorsOptions(IOptions<CorsSettings> corsOpts) : IConfigureOptions<CorsOptions>
{
    public void Configure(CorsOptions opts) 
    {
        var corsSettings = corsOpts.Value;
        opts.AddDefaultPolicy(policy =>
        {
            policy
                .AllowAnyHeader()
                .AllowAnyMethod()
                .AllowCredentials()
                .SetIsOriginAllowedToAllowWildcardSubdomains()
                .WithOrigins(corsSettings.Origins)
                .WithExposedHeaders("Location");
        });
    } 
}

// in startup 
// registers all IConfigureOptions, IPostConfigureOptions and IValidateOptions in the target class 
services.ConfigureOptions<ConfigureMyCorsOptions>(); 

// or directly
services.AddSingleton<IConfigureOptions<CorsOptions>, ConfigureMyCorsOptions>();

There's definitely a bit more ceremony since you need to define a whole class. But now you can write tests to verify you're configuration logic is working correctly (without needing to startup an entire copy of the application)

[pinkfloydx33]

You could even define a single class that Configures CORS and Jwt options, and maybe validates them too

public sealed class MyConfigurator(IOptions<CorsSettings> corsOpts, IOptions<JwtSettings> jwtOpts) :
  IConfigureOptions<CorsOptions>,
  IPostConfigureOptions<JwtBearerOptions>,
  IValidateOptions<JwtBearerOptions>
{
  public void Configure(CorsOptions opts)
  {
    var corsSettings = corsOpts.Value;
    // configure opts
  }

  public void PostConfigure(string name, JwtBearerOptions opts)
  {
    if (name != JwtBearerDefaults.AuthenticationScheme)
      return;
    
    var jwtSettings = jwtOpts.Value;
    // configure opts 
  }

  public ValidateOptionsResult Validate(string name, JwtBearerOptions opts)
  {
    if (name != JwtBearerDefaults.AuthenticationScheme) 
      return ValidateOptionsResult.Skip;

    if (string.IsNullOrWhiteSpace(opts.TokenValidationParameters?.ValidIssuer)) 
      return ValidateOptionsResult.Fail("valid issuer is missing");

    return ValidateOptionsResult.Success;
  } 
} 

And then you can register them all at once:

services.ConfigureOptions<MyConfigurator>();

Though I wouldn't personally combine configuration like this into one class unless they were all for the same options type... This is just for demo purposes (and again, it was all typed from mobile, so hopefully there's no typos)