Home/ Questions/Q 841695
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-15T05:50:26+00:00

I know there are plenty of questions here already about this topic (I’ve read

  • 0

I know there are plenty of questions here already about this topic (I’ve read through as many as I could find), but I haven’t yet been able to figure out how best to satisfy my particular criteria. Here are the goals:

  1. The ASP.NET application will run on a few different web servers, including localhost workstations for development. This means encrypting web.config using a machine key is out. Each “type” or environment of web server (dev, test, prod) has its own corresponding database (dev, test, prod). We want to separate these connection strings so that a developer working on the “dev” code is not able to see any “prod” connection string passwords, nor allow these production passwords to ever get deployed to the wrong server or committed to SVN.

  2. The application will should be able to decide which connection string to attempt to use based on the server name (using a switch statement). For example, “localhost” and “dev.example.com” will should know to use the DevDatabaseConnectionString, “test.example.com” will use the TestDatabaseConnectionString, and “www.example.com” will use the ProdDatabaseConnectionString, for example. The reason for this is to limit the chance for any deployment accidents, where the wrong type of web server connects to the wrong database.

  3. Ideally, the exact same executables and web.config should be able to run on any of these environments, without needing to tailor or configure each environment separately every time that we deploy (something that seems like it would be easy to forget/mess up one day during a deployment, which is why we moved away from having just one connectionstring that has to be changed on each target). Deployment is currently accomplished via FTP. Update: Using “build events ” and revising our deployment procedures is probably not a bad idea.

  4. We will not have command-line access to the production web server. This means using aspnet_regiis.exe to encrypt the web.config is out. Update: We can do this programmatically so this point is moot.

  5. We would prefer to not have to recompile the application whenever a password changes, so using web.config (or db.config or whatever) seems to make the most sense.

  6. A developer should not be able to get to the production database password. If a developer checks the source code out onto their localhost laptop (which would determine that it should be using the DevDatabaseConnectionString, remember?) and the laptop gets lost or stolen, it should not be possible to get at the other connection strings. Thus, having a single RSA private key to un-encrypt all three passwords cannot be considered. (Contrary to #3 above, it does seem like we’d need to have three separate key files if we went this route; these could be installed once per machine, and should the wrong key file get deployed to the wrong server, the worst that should happen is that the app can’t decrypt anything—and not allow the wrong host to access the wrong database!)

  7. UPDATE/ADDENDUM: The app has several separate web-facing components to it: a classic ASMX Web Services project, an ASPX Web Forms app, and a newer MVC app. In order to not go mad having the same connection string configured in each of these separate projects for each separate environment, it would be nice to have this only appear in one place. (Probably in our DAL class library or in a single linked config file.)

I know this is probably a subjective question (asking for a “best” way to do something), but given the criteria I’ve mentioned, I’m hoping that a single best answer will indeed arise.

Thank you!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Integrated authentication/windows authentication is a good option. No passwords, at least none that need be stored in the web.config. In fact, it’s the option I prefer unless admins have explicity taken it away from me.

    Personally, for anything that varies by machine (which isn’t just connection string) I put in a external reference from the web.config using this technique: http://www.devx.com/vb2themax/Tip/18880

    When I throw code over the fence to the production server admin, he gets a new web.config, but doesn’t get the external file– he uses the one he had earlier.

    • 0