IConfiguration

[anheri]

I'm using this Gremlinq section in my appsettings.json
"Gremlinq": {
// Optional. Non-provider-specific authentication. Can be overridden in provider sections.
"ConnectionPool": { // optional
"MaxInProcessPerConnection": 32, // optional default value
"PoolSize": 4 // optional, default value
},
"Alias": "g", // optional, default value
"CosmosDb": {
"Uri": "MyUri",
"Database": "Flyt",
"Graph": "Graph",
"AuthKey": "MyKey",
"EndPoint": ""
},
"QueryLogging": {
"Verbosity": "QueryOnly",
"LogLevel": "Trace",
"Formatting": "Indented",
"GroovyFormatting": "AllowInlining"
}
}

And everything works as expected.
Obviously I dont want secrets in my source control, so I'm trying to read the AuthKey from a key-vault.
And it is read into the IConfiguration in startup.cs on key: "Gremlinq:CosmosDb:AuthKey

At startup I do:
services.AddGremlinq(setup =>
{
setup.UseCosmosDb<Model.Graph.Vertex, Model.Graph.Edge>(x => x.ProjectId);
});

But it seems like gremlin only read configuration values from the json file, and not from the complete IConfiguration.

How can I set that AuthKey in startup?

[danielcweber]

Gremlinq is agnostic to where the configuration comes from. Here's how you set up configuration in Asp.NET Core. For Azure Key vault, check out this.

[anheri]

hi, thank you for reply... as I said the IConfiguration contains the key "Gremlinq:CosmosDb:AuthKey" with the password as value... But I get a access denied. But when I put the password in appsettings.json, it works...
So it seems that, servises.UseCosmosDb, reads from the appsettings.json file and not the IConfiguration

[danielcweber]

Well, the sources are open. If you can find the part where it reads specifically from appsettings.json, please open a bug report issue.

[anheri]

You are right... My problem was that the call to AddKeyVault was placed in the Startup.cs. Which apparently, is too late. The injected IConfiguration into ExRams configuration code did not have the keyvault provider.

thx

[danielcweber]

Could you put up a minimal example project showing a case when it's too late? I'd be interested in this edge case.

[anheri]

public class Startup
{
public IConfiguration Configuration { get; }
public IWebHostEnvironment Environment { get; }

    public Startup(IWebHostEnvironment env)
    {
        this.Environment = env ?? throw new ArgumentNullException(nameof(env));

        var builder = new ConfigurationBuilder()
            .SetBasePath(env.ContentRootPath)
            .AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
            .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true);

        builder.AddEnvironmentVariables();

        builder.AddUserSecrets<Startup>();
         this.Configuration = builder.Build();
       

        builder.AddAzureKeyVault(new Uri(this.Configuration["KeyVault:Url"]!), new ClientSecretCredential(this.Configuration["AzureAd:TenantId"], this.Configuration["AzureAd:ClientId"], this.Configuration["AzureAdClientSecret"]));

        Configuration = builder.Build();
    }

so my startup class looked like this...
the problem is that the framework has already built the IConfiguration and added the instance as a singleton. That happens in the BuildWebHost method i program.cs

now I've moved the config initialization to the proper place like this

public static IHostBuilder BuildHost(string[] args) =>
Host.CreateDefaultBuilder(args)
.ConfigureWebHostDefaults(webBuilder =>
{
webBuilder.ConfigureAppConfiguration((hostingContext, builder) =>
{
builder.AddUserSecrets();
IConfiguration config = builder.Build();

                        builder.AddAzureKeyVault(new Uri(config["KeyVault:Url"]!), new ClientSecretCredential(config["AzureAd:TenantId"], config["AzureAd:ClientId"], config["AzureAdClientSecret"]));
                    })
                    .UseStartup<Startup>();
                });}

The key here is to utilize the frameworks method for building the IConfiguration. In the method ConfigureAppConfiguration, the appsetting.json, appsetting.dev.json and environment varibles is added automagically. And after that the framework builds the IConfiguration and add it as singleton.

Manipulating the IConfiguration in Startup.cs has no effect on the singleton instance...

(At least this is my theory)