Last March I wrote about how handy it is that ASP.NET enables you to add your own custom settings to the web.config file using syntax like this:

<appSettings>
<add key=”connString” value=”user id=sa;password=mypassword;” />
</appSettings>

This is nice, but can quickly get unwieldy if you have alot application settings to maintain. Back in March I failed to mentioned (because I didn’t know about it) that you can extend your web.config even further by creating your own custom configuration sections. You can read more about the ConfigurationSettingsSchema on msdn, but here’s a quick example. First you define the custom application settings:

<configSections>
   <sectionGroup name=”myapplication”>
      <section name=”types” type=”System.Configuration.NameValueSectionHandler”/>
      <section name=”security” type=”System.Configuration.NameValueSectionHandler”/>
    </sectionGroup>
</configSections>

and then you add the actual settings:

<myapplication>
   <types>
      <add key=”section” value=”com.ignitionlabs.Section” />
      <add key=”template” value=”com.ignitionlabs.Template” />
   </types>
   <security>
      <add key=”/controlpanel/” value=”Systems Administrators,Project Managers” />
      <add key=”/members/” value=”members” />   
   </security>
</myapplication>

Finally, you can use the exact same XPATH syntax that you use when retrieving other application settings. In the above example, there are multiple ‘type’ elements, so I’d first get a NameValueCollection object:

NameValueCollection config = (NameValueCollection)System.Configuration.ConfigurationSettings.GetConfig(“myapplication/types”);

and then retrieve the value of the “section” key using the name:

string section = config[“section”];

Enjoy!

I wrote a short bit about HttpHandlers and HttpModules a couple weeks ago and recently had decided to use an HttpModule to function as a security gateway for specific parts of the application I’m developing.

If you have any experience with ASP.NET, you’ll wonder why I didn’t just use the declarative Forms security. The one shortcoming that I could see of Forms security is that it requires that you only have one form for your application. For example, in your web.config, you’d have something like this:

<authentication mode="Forms">
  <forms name=".ASPXAUTH" loginUrl="/login.aspx" />
</authentication>
<authorization>
  <allow users="*"/>
</authorization>


and then users that access any directory you protected using the <location path=”administrators”> syntax would be redirected to the /login.aspx script. If you have two different types of users though, each requiring a different login page, you’re stuck. The web.config XML schema only allows you to have one <forms> element per application. I could have split up the applications in IIS, but then I’d have to replicate application settings and libraries to each application’s bin directory. So, long story short, I wrote a short bit of code that authenticates and authorizes users in the Application BeginRequest event. Pseudo code looks like this:

public class SecurityHttpModule : IHttpModule {
// implemented per the interface
public String ModuleName {
   get { return "SecurityHttpModule"; }
}   
// register for the HttpApplication BeginRequest event
public void Init(HttpApplication application) {
   application.BeginRequest += (new EventHandler(this.Application_BeginRequest));
}
// handle the begin request event
private void Application_BeginRequest(Object source, EventArgs e) {
   HttpApplication application = (HttpApplication)source;
   HttpContext context = application.Context;
   // get the user, populate the Thread.CurrentUser...
   HttpCookie cookie = context.Request.Cookies.Get(".ASPXAUTH");
   if (peanutButterCookie != null) {
      FormsAuthenticationTicket fat = FormsAuthentication.Decrypt(cookie.Value);
      // get the user & the roles that this user is in using your own logic
      string[] roles = User.Roles;
      GenericIdentity identity = new GenericIdentity(fat.Name);
      GenericPrincipal principal = new GenericPrincipal(identity, roles);
      context.User = principal;
   }
   // find out if the section we're viewing is meant to be secure
   // pessimistic: default to forcing a login
   Boolean forceLogin = true;
   // if the section has security and we're not on the login form for this section
   if (s.isSecure() && thisSection.LoginForm != scriptName) {
      // groups allowed in this section
      ArrayList groups = s.GroupsAllowed();
      // loop over all allowed groups, see if this user is in one of those groups
      for (int x=0; x
I left out some of the implementation as well as the import statements, so this obviously won't compile if you drop it into your favorite IDE. Couple things to note in this example: