CODEWITHSUNDEEP
asp.netweb-servicesconnection-string
Adam
Adam

Reputation: 73

Accessing Connection Strings via a Web Service

The idea of storing connection strings in a data base is a perverse idea, but please hear me out first. We all know that it’s best practice to encrypt connection strings in the web.config file, but what if we just skip the web.config file completely?

A couple of months ago I was asked to move databases from one server to another. This meant having to update connection strings in every program that accessed these various databases. This is the 3rd time in 2 years I’ve had to move databases from one server to another. So I thought of storing connection strings in a database and assigning each a GUID to be accessed via a web service. Instead of placing connection strings in a web.config, you would just need to store the connection string GUID in the web.config, and reference the connection string web service so that you could request that connection string. Encryption can be done at the application level and connection strings are just stored encrypted in the database.

I’ve created a proof of concept and it works fine (its just on a local intranet and not exposed to the internet).

The benefit is obvious to me; such as being able to quickly update connection strings without having to touch the web application. This means that you could build a web application just for editing connection string in the database, that a DBA could use on there own, so they never have to bother a programmer when moving databases.

But the benefit is not what I’m interested in. I’m interested in what everyone here thinks about doing something like this?

Upvotes: 6

Views: 1732

Answers (6)

Steve
Steve

Reputation: 579

I see I'm not the only one who has had this idea. I've only recently began pondering it after some contemplation about the assortment of custom applications and Intranet sites (never mind the numerous databases and servers). Seems like to me the WCF service could or should be written in such a way as to return database connection info in a number of ways: connection string, an actual connection, or just the server and database name. Moreover the service itself should likely get its information from a central auxiliary database and table that can be used to manage the various connection points. For example: Give me the accounting database connection, production or development, etc.

Upvotes: 0

Piotr Owsiak
Piotr Owsiak

Reputation: 6259

Very interesting question. I found it because I just had the same idea.

It seems very similar to UDDI to me and it gives you another layer of indirection with possible security enhancements & improved maintainability (except for single point of failure which you can solve anyway).

Of course there's DNS which would solve the problem of host names, but with such web service you have incredible possibilities like returning different connection strings based on who's asking (depending on i.e. SSL cert or user/pass or token, directory services like AD, LDAP, user role, etc. - the sky is the limit :)

Additionally all connection strings would be properly protected and inaccessible for prying eyes of curious users.

At first this idea seems perverse, but the more I think about it the more I'm convinced that an Enterprise-level company could benefit a lot from introducing such solution.

Upvotes: 1

Yossi Dahan
Yossi Dahan

Reputation: 5377

The main disadvantages I can see are the obvious performance penalty (and if you then cache the connection string) and the single point of failure you are likely to introduce to all your applications(unless you're going to load balance this service, which would seem a bit of an overkill)

Upvotes: 2

Chris Simpson
Chris Simpson

Reputation: 8000

Take your connection strings out of the main web.config and put them in a separate config file. This file will then be the same for all your apps so if they have to change you just have to copy and paste the same file into all your app folders instead of edit each config separately.

Upvotes: 4

JoshBerke
JoshBerke

Reputation: 67108

I tend to do one of two things. I will store the connections in Machine.Config, or I will create a new host name which just refers to the DB Server. I then put a record in the hosts file.

The benefit of this is I never have to change a config file when I move from my local box, to dev qa or production environments.

Upvotes: 1

cjk
cjk

Reputation: 46475

What about when your webservice changes location? Then you would have to update all of the web.configs anyway.

Are your applications on the same server, or spread across just a few servers? You could edit the machine web.configs to incldue the DB connection strigns to save a lot of repitition.

Upvotes: 1

Related Questions