19

Where should the production and staging connection strings be stored in an ASP.NET Core application, when deploying into IIS 7 (not Azure) ?

I am looking for the recommended way of doing it / best-practice, especially security-wise.

Ian Kemp
  • 28,293
  • 19
  • 112
  • 138
Daniel
  • 1,034
  • 1
  • 10
  • 27

1 Answers1

5

In ASP.NET 5 it's possible to specify multiple configuration sources. Thanks to this welcoming change to previous model you can store your development connection string in simple json file, and your staging and production connection string in environment variables directly on the respective servers.

If you configure your app like this : 

var config = new Configuration()
.AddJsonFile("config.json")
.AddEnvironmentVariables();

and there is connection string in both config.json and environment variable then environment source will win.

So, store your development connection string in config.json(and freely check in in source control) and production one in environment variable. More info here and here.

Marko M.
  • 789
  • 3
  • 9
  • 9
    Ok, but if keeping the connection string in an environment variable in production environment, that means we're loosing applications isolation. What if 2 apps use same environment variable (ConnectionString) ? This means we should have some kind of namespace for the variables names. That doesn't look good at all... And apart from that, it also means an application can access the password in an other app's connection string (security ?) – Daniel Jul 15 '15 at 13:10
  • 2
    Ah, sure. IIS support Application pool identities and loading of user profiles. Check that out. Also check the second link i provided and Secrets API. Either of those two options should solve your problem. – Marko M. Jul 15 '15 at 13:48
  • 3
    I eventually made up my own solution by travelling all the way from the root directory to the config.{env}.json, adding all config.{env}.json found in directories in between. So I can have a config.{env}.json in a directory that doesn't get overwritten when publishing the website, and keep the connectionstring in there (still missing encryption...). I did it this way because creating a user for every website seemed to me like too much overhead, and the Secrets API is rather intended for user environment. But I'll accept your solution because I guess that's the recommended way of doing it... – Daniel Jul 16 '15 at 09:09
  • in shared hosting there is no environment variables available. – EKanadily May 07 '22 at 02:27