Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds

Managing protected web.config sections using WebConfigModifications

  Asked By: Sarojini    Date: Oct 30    Category: Sharepoint    Views: 1117

We have some web parts that expect database connection strings to be
defined in the app's web.config. Instead of manually updating all the
web.config files spread across our farm, I'd like to create a single
administrative settings page that collects the required configuration
information and uses the sharepoint WebConfigModifications API to push
the changes out automatically.

What complicates matters is that it's recommended practice to encrypt
the contents of these particular sections using one of several
standard Protected Configuration Providers. Unfortunately the standard
providers seem to expect machine-specific information (e.g. keys in
machine.config), so I can't define a single section that will work on
all the WFEs. I could in theory write a custom PCP which uses some
farm-wide information, but that's starting to approach Real Work (as
then I have to build something to update *that* shared information...)

Has anyone encountered this kind of thing before? Any suggestions for
alternative places to manage (and protect) configuration information
that should *not* be included in the .webpart definition?



2 Answers Found

Answer #1    Answered By: Dominick Blake     Answered On: Oct 30

I would suggest using the property bag attached to the farm. I don't
remember if this requires Object Model permission, but if you're
connecting to a database, then you already have adjusted the trust level
or a created a custom  policy. Right?

SPFarm.Properties["key"]="your value"

When I've done this in the past, I used classed from
System.Security.Cryptography to encrypt the value before storing it. The
.Net SDK has examples - search for

Answer #2    Answered By: Randall Hunt     Answered On: Oct 30

That's more or less my conclusion -- that for the same amount of work
to build  some centralized facility to manage  *access* to the
connection strings, I could just use the same approach  (e.g. Farm
property) to manage them directly.