Skip to content

Allowing secure, remote access to your ELMAH error log

This is part of a series of posts on using ELMAH to handle error logging for your ASP.NET web applications.  We’ve already looked at how to get started with ELMAH and how to send email alerts when errors occur.  Now we’re going to configure remote access to ELMAH’s error logs and add authentication so that only permitted users may read our exception details.

By default, ELMAH is configured to deny access to the error log it produces unless you are accessing it from the server the site is hosted on. To safely access our logs remotely we need to do two things. First, we need to enable remote access. Second, we need to add authentication so that random users and people of ill-intent cannot access our error reports and see sensitive details of the inner workings of our application.

Enabling Remote Access to ELMAH

To enable remote access we need to add the security section to ELMAH and set allowRemoteAccess="yes".

	<sectionGroup name="elmah">
		<section name="errorLog"
				 type="Elmah.ErrorLogSectionHandler, Elmah"/>
		<section name="security"
				 type="Elmah.SecuritySectionHandler, Elmah"/>

	<errorLog type="Elmah.SQLiteErrorLog, Elmah" connectionStringName="..." />
	<security allowRemoteAccess="yes" />

With those definitions added anybody can navigate to /elmah.axd and browse through the exceptions that have been logged.  This is clearly a Bad Thing™ as our error logs contain details of how our application works and may even expose usernames and passwords.  So, we need to prevent unauthorized access.

Add Authentication to ELMAH Error Logs

Using ASP.NET’s Membership Provider and in-built authorization system we can deny anonymous access by adding the following definition to our web.config file. It can go anywhere inside the root configuration element.

<location path="elmah.axd">
			<deny users="?" />

This will allow any authenticated user to view the error log. If you only want a select group of people to be able to view the log, you could put those users into a ‘Developers’ role and use something like:

	<allow roles="Developers" />
	<deny users="*" />

If you are unfamiliar with ASP.NET’s authentication and authorization features, you might find this Microsoft KB article helpful.

That’s all there is to it.  By now you should’ve set up automated error logging, secure access to the reports and configured email alerts which pipe straight into your bug tracking software and it’s probably taken less than an hour – how awesome is that!