• Choose a category
• All
• Classic-Fiction

By Root 5436 0

simplifies the process of key management—keys are generated based on machine credentials and can be accessed by all processes running on the machine. For the same reason, the DPAPI provider is not ideal to protect sections in a Web-farm scenario, where the same encrypted web.config file will be deployed to several servers. In this case, either you manually encrypt all web.config files on each machine or you copy the same container key to all servers. To accomplish this, you create a key container for the application, export it to an XML file, and import it on each server that will need to decrypt the encrypted web.config file. To create a key container, you do as follows. Using the command-line utility is mandatory here.

aspnet_regiis.exe -pc YourContainerName -exp

Next, you export the key container to an XML file:

aspnet_regiis.exe -px YourContainerName YourXmlFile.xml

Next, you move the XML file to each server and import it as follows:

aspnet_regiis.exe -pi YourContainerName YourXmlFile.xml

As a final step, grant the ASP.NET account permission to access the container.

Note

For more information about the aspnet:_regiis tool and its command line, refer to the following URL: http://msdn.microsoft.com/en-us/library/k6h9cz8h(VS.80).aspx.

Creating Custom Configuration Sections

The predefined XML schema for configuration files fits the bill in most cases, but when you have complex and structured information to persist, none of the existing schemas appear to be powerful enough. At this point, you have two possible workarounds. You can simply avoid using a standard configuration file and instead use a plain XML file written according to the schema you feel is appropriate for the data. Alternatively, you can embed your XML configuration data in the standard application configuration file but provide a tailor-made configuration section handler to read it.

Creating a new section (plus an optional new section group) requires editing the web.config file to register the section (or section group). While registering the new section, you need to specify the section handler component—that is, the piece of software in charge of parsing the contents of the section to processable data. Depending on what kind of data you’re going to store in the section, you can use one of the existing handlers or, more likely, create your own section handler.

In ASP.NET, the configuration section handler is a class that ultimately inherits from the ConfigurationSection class. The section handler class defines public properties and maps them to attributes in the XML element. In addition, these class properties are decorated with a special attribute named ConfigurationProperty. The following example shows how to create the handler for a new section with just one attribute—pageBackColor:

public class MyPagesSection : ConfigurationSection

{

private static readonly ConfigurationProperty propPageBackColor = null;

static MyPagesSection()

{

MyPagesSection.propPageBackColor = new ConfigurationProperty(

"PageBackColor", typeof(string), "yellow",

ConfigurationPropertyOptions.IsRequired);

}

[ConfigurationProperty("pageBackColor")]

public string PageBackColor

{

get { return (string) base[MyPagesSection.propPageBackColor]; }

set { base[MyPagesSection.propPageBackColor] = value; }

}

}

The mapping between a property and a section attribute is established through the ConfigurationProperty attribute. The parameter of the attribute constructor indicates the name of the section attribute used to feed the decorated property.

A custom section must be registered to work properly. Here’s how to do it:

type="Samples.MyPagesSection, Samples" />

...

The type property in the

tag indicates the class being used to read and write the contents of the section. For the sample section, the system will use the MyPagesSection class in the specified assembly. If the assembly is strongly typed and located in the GAC, you