<configSections> contains the "Microsoft.Csf" and "Microsoft.Web.Services2" <sectionGroup> tags - these <sectionGroup> tags need to be specified in order for the sections to be used properly.
One ASP.NET Security Task that was essentially impossible to perform in a shared ASP.NET 1.1 hosting environment was connection string encryption. Encrypting connection strings, encrypting application settings, or any part of Web.config required additional access to the hosting environment above and beyond what most 3rd party host providers were willing to provide to their customers.
ASP.NET 2.0 has now made this monumental task of encrypting configuration sections within Web.config a snap. There are no more excuses in .NET 2.0 as to why you haven't encrypted sensitive information, such as connection strings, in your Web.config. Not only can you encrypt config sections using aspnet_regiis from the command line, but you can also encrypt and unencrypt Web.config on the fly in code.
Encrypt AppSettings Programatically by programmer.
Shown below is a snippet of the application settings in Web.config in ASP.NET 2.0. Unprotected, you can read the application settings really easily. However, if this is private data that you don't want people to know, it is best to encrypt it.
<appSettings>
<add key="SiteName" value="My Website" />
<add key="SecretKey" value="56789012" />
appSettings>
The code for protecting and unprotecting sections in your Web.config is fairly trivial, because WebConfigurationManager-related classes handle all the work for you. I added two buttons to a web page, called btnProtect and btnUnProtect, to protect and unprotect on the fly. Here is the code of interest:
protected void UnProtect_Click(object sender, EventArgs e)
{
UnProtectSection("appSettings");
}
protected void Protect_Click(object sender, EventArgs e)
{
ProtectSection("appSettings",
"DataProtectionConfigurationProvider");
}
private void ProtectSection(string sectionName,
string provider)
{
Configuration config =
WebConfigurationManager.
OpenWebConfiguration(Request.ApplicationPath);
ConfigurationSection section =
config.GetSection(sectionName);
if (section != null &&
!section.SectionInformation.IsProtected)
{
section.SectionInformation.ProtectSection(provider);
config.Save();
}
}
private void UnProtectSection(string sectionName)
{
Configuration config =
WebConfigurationManager.
OpenWebConfiguration(Request.ApplicationPath);
ConfigurationSection section =
config.GetSection(sectionName);
if (section != null &&
section.SectionInformation.IsProtected)
{
section.SectionInformation.UnprotectSection();
config.Save();
}
}
The code is very self-explanatory. The amazing part is how trivial it is. Here is what the application settings look like when encrypted:
<appSettings configProtectionProvider=
"DataProtectionConfigurationProvider">
<EncryptedData>
<CipherData>
<CipherValue>
AQApppsswertyERjHoAwE/Cl+sBAAA
AXmrl4EN1VUSGDS9ZSSydRwQAAAACAA
AAAAADZgAAqAAAABAAAAA280OtZlZwu
D3U+ihvi23456gtfrdAEAAAr655566
AJ6AnDzWM1o3osh/Y6fcYtwAAQAA1PR
+wzfwgBgZ4y0yHU4uxaaMET13u21Bv3
zVE7aA7Z5pCWAYs54LNLNYQ673kmzAL
osWb7OMuzW6BPwMpwer456tggy
...
CipherValue>
CipherData>
EncryptedData>
appSettings>
One ASP.NET Security Task that was essentially impossible to perform in a shared ASP.NET 1.1 hosting environment was connection string encryption. Encrypting connection strings, encrypting application settings, or any part of Web.config required additional access to the hosting environment above and beyond what most 3rd party host providers were willing to provide to their customers.
ASP.NET 2.0 has now made this monumental task of encrypting configuration sections within Web.config a snap. There are no more excuses in .NET 2.0 as to why you haven't encrypted sensitive information, such as connection strings, in your Web.config. Not only can you encrypt config sections using aspnet_regiis from the command line, but you can also encrypt and unencrypt Web.config on the fly in code.
Encrypt AppSettings Programatically by programmer.
Shown below is a snippet of the application settings in Web.config in ASP.NET 2.0. Unprotected, you can read the application settings really easily. However, if this is private data that you don't want people to know, it is best to encrypt it.
<appSettings>
<add key="SiteName" value="My Website" />
<add key="SecretKey" value="56789012" />
appSettings>
The code for protecting and unprotecting sections in your Web.config is fairly trivial, because WebConfigurationManager-related classes handle all the work for you. I added two buttons to a web page, called btnProtect and btnUnProtect, to protect and unprotect on the fly. Here is the code of interest:
protected void UnProtect_Click(object sender, EventArgs e)
{
UnProtectSection("appSettings");
}
protected void Protect_Click(object sender, EventArgs e)
{
ProtectSection("appSettings",
"DataProtectionConfigurationProvider");
}
private void ProtectSection(string sectionName,
string provider)
{
Configuration config =
WebConfigurationManager.
OpenWebConfiguration(Request.ApplicationPath);
ConfigurationSection section =
config.GetSection(sectionName);
if (section != null &&
!section.SectionInformation.IsProtected)
{
section.SectionInformation.ProtectSection(provider);
config.Save();
}
}
private void UnProtectSection(string sectionName)
{
Configuration config =
WebConfigurationManager.
OpenWebConfiguration(Request.ApplicationPath);
ConfigurationSection section =
config.GetSection(sectionName);
if (section != null &&
section.SectionInformation.IsProtected)
{
section.SectionInformation.UnprotectSection();
config.Save();
}
}
The code is very self-explanatory. The amazing part is how trivial it is. Here is what the application settings look like when encrypted:
<appSettings configProtectionProvider=
"DataProtectionConfigurationProvider">
<EncryptedData>
<CipherData>
<CipherValue>
AQApppsswertyERjHoAwE/Cl+sBAAA
AXmrl4EN1VUSGDS9ZSSydRwQAAAACAA
AAAAADZgAAqAAAABAAAAA280OtZlZwu
D3U+ihvi23456gtfrdAEAAAr655566
AJ6AnDzWM1o3osh/Y6fcYtwAAQAA1PR
+wzfwgBgZ4y0yHU4uxaaMET13u21Bv3
zVE7aA7Z5pCWAYs54LNLNYQ673kmzAL
osWb7OMuzW6BPwMpwer456tggy
...
CipherValue>
CipherData>
EncryptedData>
appSettings>
ASP.NET provides a configuration system we can use to keep our applications flexible at runtime. In this article we will examine some tips and best practices for using the configuration system for the best results.
The five sections of the Web.config file that are critical to the operation of the CSF connectors - <configSections>, <system.web><httpHanders>, <Microsoft.Csf>, <microsoft.web.services2>, and <appSettings>.
<appSettings> holds the path to the EnterpriseInstrumentation.config file, as well as additional configuration parameters:
<appSettings>
<add key="instrumentationConfigFile" value="C:\CsfConfig\EnterpriseInstrumentation.config" />
</appSettings>
The <appSettings> element of a web.config file is a place to store connection strings, server names, file paths, and other miscellaneous settings needed by an application to perform work. The items inside appSettings are items that need to be configurable depending upon the environment, for instance, any database connection strings will change as you move your application from a testing and staging server into production.
The web.config file in ASP.NET is the central location for your web applications configuration.
you want to add you own settings into the web.config file. This tutorial will explain how it's done.
To create your own custom configuration handler, it will require two parts: writing some code, and editing your web.config file.
using System;
using System.Collections;
using System.Xml;
using System.Configuration;
using System.Web.Configuration;
namespace MyTest {
internal class PageStyleHandler:IConfigurationSectionHandler {
public virtual object Create(Object parent, Object context, XmlNode node) {
PageStyle config = new PageStyle((PageStyle)parent);
config.LoadValuesFromConfigurationXml(node);
return config;
}
}
public class PageStyle {
string _backColour;
internal PageStyle(PageStyle parent) {
if (parent != null)
_backColour = parent._backColour;
}
internal void LoadValuesFromConfigurationXml(XmlNode node) {
XmlAttributeCollection attribCol = node.Attributes;
_backColour = attribCol["backColour"].Value;
}
public string BackColour {
get {
return _backColour;
}
}
}
}
There are two classes here, the PageStyleHandler class which implements the IConfigurationSectionHandler, and the PageStyle class which is used
to store and retrieve the configuration data.
The PageStyleHandler contains the Create method. It is used to create and instance of the PageStyle class to pass the data from the web.config file.
The PageStyle class will accept an XML node which comes from the web.config file, it reads the attribute from the XML node and it will save the data for future retrieval by the BackColour property.
ASP.Net Web.config file
To add your custom handler to the web.config file for this application, it requires simply editing the web.config file so that it will accept your new handler. Your new web.config file will look like this:
<configuration>
<configSections>
<sectionGroup name="MyTest">
<section name="pageStyle" type="MyTest.PageStyleHandler, PageStyle" />
</sectionGroup>
</configSections>
<MyTest>
<pageStyle backColour="blue" />
</MyTest>
</configuration>
This example will only apply to the web application that this file resides in. If you would like this new handler to apply to all web applications on this server, the <sectionGroup> tag can be moved to the machine.config.
Using an ASPX page
Here is an example of our new custom handler in action:
<%@ Import Namespace="MyTest" %>
<html>
<head>
<title>ASP.NET Configuration</title>
<script language="C#" runat="server">
void Page_Load(Object sender, EventArgs e) {
PageStyle _pageStyle;
_pageStyle = (PageStyle) Context.GetConfig("MyTest/pageStyle");
bodyTag.Attributes["bgcolor"] = _pageStyle.BackColour;
}
</script>
</head>
<body id="bodyTag" runat="server">
<table bgcolor="white" align="center" width="400"><tr><td>
<p align="center">
<font size=+2>This background is blue!</font>
</p>
</td></tr></table>
</body>
</html>
The custom configuration handler in ASP.NET is a useful addition for creating really flexible web pages. Usage for custom configuration handlers can be for: allowing the web applications style to be defined in one web.config file, saving information that is commonly used.
The five sections of the Web.config file that are critical to the operation of the CSF connectors - <configSections>, <system.web><httpHanders>, <Microsoft.Csf>, <microsoft.web.services2>, and <appSettings>.
<appSettings> holds the path to the EnterpriseInstrumentation.config file, as well as additional configuration parameters:
<appSettings>
<add key="instrumentationConfigFile" value="C:\CsfConfig\EnterpriseInstrumentation.config" />
</appSettings>
The <appSettings> element of a web.config file is a place to store connection strings, server names, file paths, and other miscellaneous settings needed by an application to perform work. The items inside appSettings are items that need to be configurable depending upon the environment, for instance, any database connection strings will change as you move your application from a testing and staging server into production.
The web.config file in ASP.NET is the central location for your web applications configuration.
you want to add you own settings into the web.config file. This tutorial will explain how it's done.
To create your own custom configuration handler, it will require two parts: writing some code, and editing your web.config file.
using System;
using System.Collections;
using System.Xml;
using System.Configuration;
using System.Web.Configuration;
namespace MyTest {
internal class PageStyleHandler:IConfigurationSectionHandler {
public virtual object Create(Object parent, Object context, XmlNode node) {
PageStyle config = new PageStyle((PageStyle)parent);
config.LoadValuesFromConfigurationXml(node);
return config;
}
}
public class PageStyle {
string _backColour;
internal PageStyle(PageStyle parent) {
if (parent != null)
_backColour = parent._backColour;
}
internal void LoadValuesFromConfigurationXml(XmlNode node) {
XmlAttributeCollection attribCol = node.Attributes;
_backColour = attribCol["backColour"].Value;
}
public string BackColour {
get {
return _backColour;
}
}
}
}
There are two classes here, the PageStyleHandler class which implements the IConfigurationSectionHandler, and the PageStyle class which is used
to store and retrieve the configuration data.
The PageStyleHandler contains the Create method. It is used to create and instance of the PageStyle class to pass the data from the web.config file.
The PageStyle class will accept an XML node which comes from the web.config file, it reads the attribute from the XML node and it will save the data for future retrieval by the BackColour property.
ASP.Net Web.config file
To add your custom handler to the web.config file for this application, it requires simply editing the web.config file so that it will accept your new handler. Your new web.config file will look like this:
<configuration>
<configSections>
<sectionGroup name="MyTest">
<section name="pageStyle" type="MyTest.PageStyleHandler, PageStyle" />
</sectionGroup>
</configSections>
<MyTest>
<pageStyle backColour="blue" />
</MyTest>
</configuration>
This example will only apply to the web application that this file resides in. If you would like this new handler to apply to all web applications on this server, the <sectionGroup> tag can be moved to the machine.config.
Using an ASPX page
Here is an example of our new custom handler in action:
<%@ Import Namespace="MyTest" %>
<html>
<head>
<title>ASP.NET Configuration</title>
<script language="C#" runat="server">
void Page_Load(Object sender, EventArgs e) {
PageStyle _pageStyle;
_pageStyle = (PageStyle) Context.GetConfig("MyTest/pageStyle");
bodyTag.Attributes["bgcolor"] = _pageStyle.BackColour;
}
</script>
</head>
<body id="bodyTag" runat="server">
<table bgcolor="white" align="center" width="400"><tr><td>
<p align="center">
<font size=+2>This background is blue!</font>
</p>
</td></tr></table>
</body>
</html>
The custom configuration handler in ASP.NET is a useful addition for creating really flexible web pages. Usage for custom configuration handlers can be for: allowing the web applications style to be defined in one web.config file, saving information that is commonly used.
The machine configuration file, Machine.config, contains settings that apply to an entire computer. This file is located in the %runtime install path%\Config directory. Machine.config contains configuration settings for machine-wide assembly binding, built-in remoting channels, and ASP.NET.
The configuration system first looks in the machine configuration file for the element and other configuration sections that a developer might define. It then looks in the application configuration file. To keep the machine configuration file manageable, it is best to put these settings in the application configuration file. However, putting the settings in the machine configuration file can make your system more maintainable. For example, if you have a third-party component that both your client and server application uses, it is easier to put the settings for that component in one place. In this case, the machine configuration file is the appropriate place for the settings, so you don't have the same settings in two different files.
The configuration system first looks in the machine configuration file for the
When the site goes live change the debug setting to false which will make the site have a little better performance.
<compilation defaultLanguage="C#" debug="true" />
Customer errors can be handled be turned off but I prefer them to be turned on as below.
<customErrors mode="Off" />
You can also do per page tracing so that you can turn off application Tracing and have trace="true" at the top of a single page.
<trace enabled="true" requestLimit="10" pageOutput="true" traceMode="SortByTime" localOnly="true"/>
ASP.NET provides a configuration system we can use to keep our applications flexible at runtime. In this article we will examine some tips and best practices for using the configuration system for the best results.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key="ConnectionInfo" value="server=(local);database=Northwind;Integrated Security=SSPI" />
</appSettings>
</configuration>
Multiple File Configuration
The appSettings element may contain a file attribute that points to an external file. Let’s change our web.config to look like the following
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings file="dbsettings.config"/>
</configuration>
Next, we can create the external file ‘dbsettings.config’ and add an appSettings section with our connection information.
<appSettings>
<add key="ConnectionInfo" value="server=(local);database=Northwind;Integrated Security=SSPI" />
</appSettings>
If the external file is present, ASP.NET will combine the appSettings values from web.config with those in the external file. If a key/value pair is present in both files, ASP.NET will use the value from the external file.
Session States:
Session in Asp .net web application is very important. As we know that HTTP is a stateless protocol and we needs session to keep the state alive. Asp .net stores the sessions in different ways. By default the session is stored in the asp .net process. You can always configure the application so that the session will be stored in one of the following ways
[1] Session State Service
There are two main advantages of using the State Service. First the state service is not running in the same process as the asp .net application. So even if the asp .net application crashes the sessions will not be destroyed. Any advantage is sharing the state information across a Web garden (Multiple processors for the same computer).
Lets see a example of the Session State Service.
<sessionState mode="StateServer" stateConnectionString="tcpip=127.0.0.1:55455" sqlConnectionString="data source=127.0.0.1;user id=sa;password='' cookieless="false" timeout="20"/>
The attributes are self explanatory but I will go over them.
mode: This can be StateServer or SqlServer. Since we are using StateServer we set the mode to StateServer.
stateConnectionString: connectionString that is used to locate the State Service.
sqlConnectionString: The connection String of the sql server database.
cookieless: Cookieless equal to false means that we will be using cookies to store the session on the client side.
[2.] SQL Server
The final choice to save the session information is using the Sql Server 2000 database. To use Sql Server for storing session state you need to do the following:
Run the InstallSqlState.sql script on the Microsoft SQL Server where you intend to store the session.
You web.config settings will look something like this:
<sessionState mode = "SqlServer" stateConnectionString="tcpip=127.0.0.1:45565" sqlConnectionString="data source="SERVERNAME;user id=sa;password='' cookiesless="false" timeout="20"/>
SQL Server lets you share session state among the processors in a Web garden or the servers in a Web farm. Apart from that you also get additional space to store the session. And after that you can take various actions on the session stored.
The downside is SQL Server is slow as compared to storing session in the state in process. And also SQL Server cost too much for a small company.
[3] InProc:
This is another Session State. This one is mostly used for development purposes. The biggest advantage of using this approach is the applications will run faster when compared to other Session state types. But the disadvantage is Sessions are not stored when there is any problem that occurs with the application, when there is a small change in the files etc., Also there could be frequent loss of session data experienced.
Error Handling:
<customErrors mode = "On">
<error statusCode = "404" redirect = "errorPage.aspx" />
</customErrors>
Security:
The most critical aspect of any application is the security. Asp.net offers many different types of security method which can be used depending upon the condition and type of security you need.
[1] No Authentication:
No Authentication means "No Authentication" :) , meaning that Asp.net will not implement any type of security.
[2] Windows Authentication:
The Windows authentication allows us to use the windows user accounts. This provider uses IIS to perform the actual authentication, and then passes the authenticated identity to your code. If you like to see that what windows user is using the Asp.net application you can use:
User.Identity.Name;
This returns the DOMAIN\UserName of the current user of the local machine.
[3] Passport Authentication:
Passport Authentication provider uses Microsoft's Passport service to authenticate users.
[4] Forms Authentication:
Forms Authentication uses HTML forms to collect the user information and than it takes required actions on those HTML collected values.
In order to use Forms Authentication you must set the Anonymous Access checkbox checked. Now we need that whenever user tries to run the application he/she will be redirected to the login page.
<authentication mode="Forms">
<forms loginUrl = "frmLogin.aspx" name="FAutho" timeout="1"/>
</authentication>
<authorization>
<deny users="?" />
</authorization>
<compilation defaultLanguage="C#" debug="true" />
Customer errors can be handled be turned off but I prefer them to be turned on as below.
<customErrors mode="Off" />
You can also do per page tracing so that you can turn off application Tracing and have trace="true" at the top of a single page.
<trace enabled="true" requestLimit="10" pageOutput="true" traceMode="SortByTime" localOnly="true"/>
ASP.NET provides a configuration system we can use to keep our applications flexible at runtime. In this article we will examine some tips and best practices for using the configuration system for the best results.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key="ConnectionInfo" value="server=(local);database=Northwind;Integrated Security=SSPI" />
</appSettings>
</configuration>
Multiple File Configuration
The appSettings element may contain a file attribute that points to an external file. Let’s change our web.config to look like the following
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings file="dbsettings.config"/>
</configuration>
Next, we can create the external file ‘dbsettings.config’ and add an appSettings section with our connection information.
<appSettings>
<add key="ConnectionInfo" value="server=(local);database=Northwind;Integrated Security=SSPI" />
</appSettings>
If the external file is present, ASP.NET will combine the appSettings values from web.config with those in the external file. If a key/value pair is present in both files, ASP.NET will use the value from the external file.
Session States:
Session in Asp .net web application is very important. As we know that HTTP is a stateless protocol and we needs session to keep the state alive. Asp .net stores the sessions in different ways. By default the session is stored in the asp .net process. You can always configure the application so that the session will be stored in one of the following ways
[1] Session State Service
There are two main advantages of using the State Service. First the state service is not running in the same process as the asp .net application. So even if the asp .net application crashes the sessions will not be destroyed. Any advantage is sharing the state information across a Web garden (Multiple processors for the same computer).
Lets see a example of the Session State Service.
<sessionState mode="StateServer" stateConnectionString="tcpip=127.0.0.1:55455" sqlConnectionString="data source=127.0.0.1;user id=sa;password='' cookieless="false" timeout="20"/>
The attributes are self explanatory but I will go over them.
mode: This can be StateServer or SqlServer. Since we are using StateServer we set the mode to StateServer.
stateConnectionString: connectionString that is used to locate the State Service.
sqlConnectionString: The connection String of the sql server database.
cookieless: Cookieless equal to false means that we will be using cookies to store the session on the client side.
[2.] SQL Server
The final choice to save the session information is using the Sql Server 2000 database. To use Sql Server for storing session state you need to do the following:
Run the InstallSqlState.sql script on the Microsoft SQL Server where you intend to store the session.
You web.config settings will look something like this:
<sessionState mode = "SqlServer" stateConnectionString="tcpip=127.0.0.1:45565" sqlConnectionString="data source="SERVERNAME;user id=sa;password='' cookiesless="false" timeout="20"/>
SQL Server lets you share session state among the processors in a Web garden or the servers in a Web farm. Apart from that you also get additional space to store the session. And after that you can take various actions on the session stored.
The downside is SQL Server is slow as compared to storing session in the state in process. And also SQL Server cost too much for a small company.
[3] InProc:
This is another Session State. This one is mostly used for development purposes. The biggest advantage of using this approach is the applications will run faster when compared to other Session state types. But the disadvantage is Sessions are not stored when there is any problem that occurs with the application, when there is a small change in the files etc., Also there could be frequent loss of session data experienced.
Error Handling:
<customErrors mode = "On">
<error statusCode = "404" redirect = "errorPage.aspx" />
</customErrors>
Security:
The most critical aspect of any application is the security. Asp.net offers many different types of security method which can be used depending upon the condition and type of security you need.
[1] No Authentication:
No Authentication means "No Authentication" :) , meaning that Asp.net will not implement any type of security.
[2] Windows Authentication:
The Windows authentication allows us to use the windows user accounts. This provider uses IIS to perform the actual authentication, and then passes the authenticated identity to your code. If you like to see that what windows user is using the Asp.net application you can use:
User.Identity.Name;
This returns the DOMAIN\UserName of the current user of the local machine.
[3] Passport Authentication:
Passport Authentication provider uses Microsoft's Passport service to authenticate users.
[4] Forms Authentication:
Forms Authentication uses HTML forms to collect the user information and than it takes required actions on those HTML collected values.
In order to use Forms Authentication you must set the Anonymous Access checkbox checked. Now we need that whenever user tries to run the application he/she will be redirected to the login page.
<authentication mode="Forms">
<forms loginUrl = "frmLogin.aspx" name="FAutho" timeout="1"/>
</authentication>
<authorization>
<deny users="?" />
</authorization>