Should an ASP.NET application allow administrators to change SQL Server connection?

Question

As the title suggests:

What is your opinion on allowing administrators to update the SQL Server Connection string dynamically from the application versus just showing them the connection details in the application?

Because the database connection is so important and on a heavily used system the abrupt change to the connection seems like it could cause problems. However I would think displaying the server and catalog and whether the connection is using SSPI or SQL Auth could be helpful for administrators who don't like playing with .NET config files.

Thoughts?

Answer 1

Sounds like two bad ideas. Allowing changes to connection strings while the app is running is sure to cause disruption (broken connections, data out of sync, and who knows what else). And even displaying connection details to anyone (even admins) seems like a dangerous security hole.

What kind of site do you have where this sort of thing would be necessary?

Answer 2

Requires that your application run in full trust, otherwise it's just using the System.Web.Configuration namespace:

http://www.beansoftware.com/ASP.NET-Tutorials/Modify-Web.Config-Run-Time.aspx

On any change to the web.config the app will recycle, so still isn't something you'd want to in the middle of the day if sales might be in flight.

Also, usually authentication and authorization relies on the database. So if you can't authenticate and authorize, you won't be able to get to the admin page to change the connection string! (Unless your authorization and authentication has nothing in it that touches the database, at least for the admin page your considering)

Answer 3

How are you identifying administrators? Presumably not by looking at the database. Because if you do use the db and then change the database to another server, it's possible they aren't administrators or there's no database, and then bam - they can't get in to fix it.

Typically, I like to do maintenance on this out-of-band (the config file or even in Active Directory, so it's in a centrally administered resource). We also typically have application administrators (roles, maintenance, approvals, workflow-related "administrators") who really are not system administrators in a technical sense. And often, we do not allow system administrators as user, managers or administraors within the application. i.e. I might have a purchase order system administrator who can void a purchase order, but they can't change a database connection and I have a sys admin who can't even create or approve a purchase order, let alone void one, but they can change the database connection in the config or in Active Directory as part of an upgrade or migration.

I agree that a debug page, help page or about page can be useful to show information to both system administrators and application administrators. Whether they should be allowed to change things there really depends.

Answer 4

Personally I don't like letting administrators change ANYTHING on a live site. All configuration changes should go through the same version-controlled, time-stamped, user-attributed, build-system-checked process that source code goes through. Only then can you draw connections "this stopped working at time X because user Y changed configuration A at time B".

An extreme view on the topic I know, but given the huge proportion of downtime that can be traced back to operator error I believe is justified, and I honestly can't understand the fascination people have for being able to edit fragile XML files on live servers where a single extra '>' can bring the entire site down.