I mentioned that v1.1 of ASP.NET by default validates input received from QueryString, Form and Cookie scope. You can turn off this validation site wide by tweaking the web.config:

<configuration>
  <system.web>
    <pages validateRequest=”false” />
  </system.web>
</configuration>

But then you’re left with no validation right? Wrong. You can use the ValidateInput() method of the HttpRequest object programmatically in any code that has access to the HttpRequest instance. Very useful stuff.

One question though: What is potentially dangerous data according to Microsoft? And can you modify that definition? I’m guessing the answers are: a) we’ll never know and b) no. Given their track record, does it make sense to trust Microsoft to validate the input you receive from client browsers when the browser they created can’t be trusted?

I’m sure this is boring for about 99% of you, but I’m writing for my own benefit anyway. I mentioned the ‘out method parameter’ yesterday because I saw it used in a custom library I’m using and then today I found out that the Double class uses it as well. I think it’s a great example of how it should be used. It’s used in the TryParse method:

public static bool TryParse(
   string s,
   NumberStyles style,
   IFormatProvider provider,
   out double result
);

“The TryParse method is like the Parse method, except this method does not throw an exception if the conversion fails. If the conversion succeeds, the return value is true and the result parameter is set to the outcome of the conversion. If the conversion fails, the return value is false and the result parameter is set to zero.”

I like it because throwing an exception (ie: what the Parse() method does) violates rule #39 of Effective Java Programming which says to “… Use exceptions only for exceptional conditions.” Using an out parameter feels cleaner and simpler. Anyone else think so?

Just discovered this C# tidbit called the out method parameter. Let’s say you have a method:

public String ReplaceAll(String toReplace, String replaceWith)

and you want to know how many replacements were actually made. With a regular method you can only return the modified string. The out method parameter gives you the ability to return another variable. The modified method would look like this:

public String ReplaceAll(String toReplace, String replaceWith, out int numReplaced)

and then concretely:

String myString = “aaron”;
int replaced;
myString.ReplaceAll(“a”, “k”, out replaced);
Console.WriteLine(“The method ReplaceAll() replaced ” + replaced + ” characters.”);

Similar idea in the ref method parameter, but you have to initialize the variable before sending it to the method.

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: