Why don't we use secret.json when creating an admin account?

[sadqiang]

Putting the following data

"Administrator" : {
     "UserName" : "admin@todo.local",
     "Email" : "admin@todo.local",
     "Password" : "NotSecure123!!"
}

in secret.json and loading them via IConfiguration con should be safer as well as it promotes a better practice.

private static async Task EnsureTestAdminAsync(UserManager<ApplicationUser> userManager, IConfiguration con)
{
    // ........

    testAdmin = new ApplicationUser { UserName = con["Administrator:UserName"], Email = con["Administrator:Email"] };
    await userManager.CreateAsync(testAdmin, con["Administrator:Password"]);
    await userManager.AddToRoleAsync(testAdmin, Constants.AdministratorRole);
}

Note: secret.json will not be uploaded to github repository.

[OlekRia]

AFAIK, secret.json used for development only. When you as a user have own password and want to override your development configuration. So, data in this json will be only in your computer, not in SVN.
{ "Administrator": { "Password": "My onw developer password" }}

So, secrets.json might be useful for scenario like u have different users, passwords, etc. in different machines, for example of SQL connection.

And for most securable reason in production we have to use Environment variable which overrides both appsettings.json and secret.json:
set Adminitrator__Password TopSecretPasswordForRealDevOps

[nbarbettini]

The example in the book is meant to be for demonstration purposes only, hence a goofy password like NotSecure123!!. It's a value only used once to seed the database, and the instructions tell the user to change it immediately.

If you need to store and retrieve a sensitive configuration value repeatedly, you should definitely use environment variables (in production) or secrets.json (in development). This example doesn't really fall into that category in my opinion.

I'll investigate not using a hardcoded password in #58.