Configuring ASP.NET authentication log


Some time ago I wrote about ASP.NET Health Monitoring – a logging infrastructure provided by the .NET framework, easily configurable through web.config. In that post I was presenting heart beat and error events. Today I would like to show you how to collect ASP.NET authentication audit logs. There are special events groups registered in the global web.config for this purpose:

        <healthMonitoring>
            ...
            <eventMappings>
                ...
                <add name="All Audits" type="System.Web.Management.WebAuditEvent,System.Web,Version=4.0.0.0,Culture=neutral,PublicKeyToken=b03f5f7f11d50a3a"
                    startEventCode="0" endEventCode="2147483647" />
                <add name="Failure Audits" type="System.Web.Management.WebFailureAuditEvent,System.Web,Version=4.0.0.0,Culture=neutral,PublicKeyToken=b03f5f7f11d50a3a"
                    startEventCode="0" endEventCode="2147483647" />
                <add name="Success Audits" type="System.Web.Management.WebSuccessAuditEvent,System.Web,Version=4.0.0.0,Culture=neutral,PublicKeyToken=b03f5f7f11d50a3a"
                    startEventCode="0" endEventCode="2147483647" />
            </eventMappings>
        </healthMonitoring>

Though, using the All Audits set will cause your application to generate an audit event for each served request. If we then would store those events in a SQL Server database we might put a heavy load on the server. In this post I will show you how to reduce the number of audit events to login attempts and then store them safely in a database.

Continue reading

Life of Exception in ASP.NET


In this post I’m going to show you the way ASP.NET (MVC) handles exceptions that occur in web applications. We will also examine different places where we can hook our own loggers. Our application will be a very basic ASP.NET MVC project with one controller and one view:

using System;
using System.Web;
using System.Web.Mvc;

[HandleError]
public class HomeController : Controller
{
    //
    // GET: /Home/
    public ActionResult Index()
    {
        return View();
    }
    
    public ActionResult Exception() {
        throw new Exception(&quot;test exception&quot;);
    }
}
@{
    ViewBag.Title = &quot;test title&quot;;
}

<h2>Index page</h2>

<a href=&quot;@Url.Action(&quot;Exception&quot;)&quot;>throw exception</a>

Continue reading

Making elmah.axd a log viewer for multiple applications


Elmah is a great exception logger for web applications. Next to the exception data (stacktrace, exception message etc.) it collects detailed request and runtime information. If I also mention that it’s easy to install and highly configurable it comes with no surprise that it became an industrial logging standard for .NET web applications. Elmah gives you a great choice of places where you can send your logs, though a database is the one I consider most useful. What I also value in Elmah is its log viewer (elmah.axd) – it has a nice exception list and a great exception details screen – I wish the ASP.NET Yellow Screen of Death had that look :). The only thing I don’t really like in this viewer is a fact that by default it is bound to the application that has Elmah installed and is accessible only under hxxp://app-address/elmah.axd. If you do not secure access to this handler everyone can see detailed information on your code and environment – just have a look how many developers forget about it. In this post I will show you how to remove the elmah.axd handler from your application and how to create a separate ASP.NET application that would be a central Elmah log viewer for your applications.

Continue reading

Diagnosing ASP.NET views compilation with FrontMan


In today’s post I will show you how we fought a pesky compilation problem with Razor views in our ASP.NET MVC application. One of the parts of our application is an email-sending engine which uses Razor templates to create message bodies. After deploying this app on IIS we started receiving the following errors (unimportant parts are stripped):

...
Line: 0\\t Col: 0\\t Error: Metadata file \u0027ev-server/dev2/appname/bin/EmailSystem.Client.DLL\u0027 could not be found

//------------------------------------------------------------------------------
// \u003cauto-generated\u003e
//     This code was generated by a tool.
//     Runtime Version:4.0.30319.235
//
//     Changes to this file may cause incorrect behavior and will be lost if
//     the code is regenerated.
// \u003c/auto-generated\u003e
//------------------------------------------------------------------------------
...

The first line suggests that it’s a compilation problem, but we didn’t really know exactly which part of the application was throwing it. I thought having a full compiler command line might help us. Unfortunately gathering it from ASP.NET application is not so easy.

Continue reading

Application Pool identity and Directory Security in IIS6


In today’s post I will describe different security settings of the application pool and the IIS6 directory. It’s not always easy to guess which permissions must be set on system folders and files in order to make the application run correctly. I will also show you how to diagnose those pesky security problems using available tracing options.

Continue reading

ASP.NET Health Monitoring


ASP.NET Health Monitoring is one of the framework gems that is often forgotten by ASP.NET developers or web server administrators. It provides great monitoring features, often allowing you to rapidly diagnose failing applications or systems. Have you ever wondered why ASP.NET errors appear in the system event log? It’s thanks to the ASP.NET Health Monitoring and its configuration in the master web.config file (the one stored in the framework installation directory):

<healthMonitoring>
    <bufferModes>...</bufferModes>
    <providers>...</providers>
    <eventMappings>...</eventMappings>
    <profiles>...</profiles>
    <rules>
        <add name="All Errors Default" eventName="All Errors" provider="EventLogProvider"
            profile="Default" minInstances="1" maxLimit="Infinite" minInterval="00:01:00"
            custom="" />
        <add name="Failure Audits Default" eventName="Failure Audits"
            provider="EventLogProvider" profile="Default" minInstances="1"
            maxLimit="Infinite" minInterval="00:01:00" custom="" />
    </rules>
</healthMonitoring>

Let’s analyze quickly the above snippet. A rule defines which ASP.NET health events will be logged (eventname) by the chosen provider and at what frequency. The ASP.NET health events hierarchy can be found here. The event name used in the rule definition is the name of the mapping that is defined earlier in the web.config file. An example event mapping looks as follows:
Continue reading