Umbraco, ELMAH (with SQL CE 4.0) and authentication

So this is the second blogpost I’m writing about Umbraco, ELMAH and authentication.
My previous blogpost wasn’t really good, because with forms-authentication authenticated members could also access elmah, which is not the way to go. So I’ve dropped MADAM.

This time I’ve managed to get both forms-authentication for umbraco and basic/windows-authentication for ELMAH. The trick is to create a subfolder called ‘elmah’, which we’ll convert to an application and enable basic/windows-authenticatioin for this app.
This is kind of tricky, because all web.config configurations will be inherited by the web.config for any sub-application. Also ELMAH filters the errors in the database based on the current Application string property, for example “/LM/W3SVC/24/ROOT”, but if you configure the elmah.axd handler in a sub-application, the application for the handler will be “/LM/W3SVC/24/ROOT/elmah” and you won’t see any logged errors of the main application.

To overcome this I had to make changes to ELMAH’s source code. I’ve cloned the Mercurial repo and changed some files. This way it’ll be easy to keep it up-to-date without losing my changes. There’s one extra thing I’ve changed; I’ve disabled logging the current user’s password, because of privacy reasons.

A step-by-step guide to get ELMAH and umbraco to play nicely side-by-side:

1. Download this zipfile (which contains 3 other zip files)
2. Unzip the file ‘1. elmah.zip‘ in the root of your project and include the whole folder in Visual Studio (so it’ll get deployed with WebDeploy)
3. Unzip the file ‘2. elmah assemblies.zip‘ somewhere in your project, where all third party assemblies reside and optionally add a reference in Visual Studio (if you’d like to use Error Signalling and if you’re using something like WebDeploy)
4. Unzip the file ‘3. sqlce assemblies.zip‘ in the root of your project and include both folders in Visual Studio. Inside VS select all files underneath the AMD64 and X86 folders and go to their properties. Set ‘Build action’ to ‘None’ and ‘Copy to Output Directory’ to ‘Copy if newer’ (screenshot below)
   
5. Add the following to your web.config:
   <system.data>
   <DbProviderFactories>
   <remove invariant=”System.Data.SqlServerCe.4.0″ />
   <add name=”Microsoft SQL Server Compact Data Provider 4.0″ invariant=”System.Data.SqlServerCe.4.0″ description=”.NET Framework Data Provider for Microsoft SQL Server Compact” type=”System.Data.SqlServerCe.SqlCeProviderFactory, System.Data.SqlServerCe, Version=4.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91″ />
   </DbProviderFactories>
   </system.data>
6. Add the following to your web.config (inside the runtime\assemblyBinding element):
   <dependentAssembly>
   <assemblyIdentity name=”System.Data.SqlServerCe” publicKeyToken=”89845dcd8080cc91″ culture=”neutral” />
   <bindingRedirect oldVersion=”0.0.0.0-4.0.0.0″ newVersion=”4.0.0.0″ />
   </dependentAssembly>
7. If you were using ELMAH already in your project, remove any elmah.axd handlers in your web.config
8. If you’ve registered none-umbraco httpModules, please add them to the removal list in ~\elmah\web.config so they won’t be loaded for the ELMAH sub-application
9. Open IIS Manager and navigate to your website underneath ‘Sites’. Expand you site so you’ll see the directories underneath it and right-click the ‘elmah’ folders and select ‘Convert to Application’ and select the AppPool your site is running in
10. Next make sure this newly created sub-application is selected in the tree and open up ‘Authentication’. Enable ‘Basic Authentication’ and you’re ready to start logging and reading errors!

The ELMAH page can be accessed by navigating to ‘/elmah/’ or just ‘/elmah/elmah.axd’.
The SQL CE error log database will be stored in ‘~/App_Data/’. You could monitor the size of this file as it will grow to max 1024MB.

Umbraco, ELMAH, MADAM and authentication

Please refer to this blogpost

Warning – read first: There is an issue with this approach; when you’re authenticated via Forms Authentication (like being logged in on the website), you’re ALSO allowed to access elmah.axd.
I have looked for a solution, but I haven’t figured one yet. Do you have the solution? Please reply on this blog and I’ll include your information.

---

We’re using ELMAH in every single umbraco project we built, it’s an awesome error logging module for .NET.

To protect ELMAH, we were using Basic Authentication, which is built-in in .NET and IIS.
But since umbraco v4.7.1, umbraco relies on Forms Authentication for the Members. As you might know, it’s impossible to have Basic AND Forms Authentication enabled at the same time, so the quick conclusion was to go with Forms Authentication, else umbraco’s membership provider wouldn’t work anymore.

So now we have a problem: whenever someone’s logged in as a member, he/she can access elmah.axd (assuming that you’ve got elmah.axd protected as described here).
Wouldn’t it be awesome  if we could still use some sort of Basic Authentication AND Forms Authentication? Ofcourse! That’s where MADAM steps in (from the creator of ELMAH, isn’t that coincidental?).

So here’s a guide how to set-up your project (which I assume already has ELMAH running and configured, as described here for example):
Add the MADAM assembly to the bin folder (+ reference if you use VS)
Some stuff in the web.config:

• Add sectionGroup for madam:

<sectionGroup name="madam">
<section type="Madam.FormsAuthenticationDispositionSectionHandler, Madam"/>
<section type="System.Configuration.SingleTagSectionHandler, System, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
</sectionGroup>

• Add httpModules to system.web/httpModules and system.webServer/modules:

<add name="FormsAuthenticationDisposition" type="Madam.FormsAuthenticationDispositionModule, Madam"/></pre>
<!-- IMPORTANT! The actual HTTP authentication module MUST appear  AFTER the FormsAuthenticationDisposition module. -->
<add name="BasicAuthentication" type="Madam.BasicAuthenticationModule, Madam"/>

• Extend the <authentication mode=”Forms” /> tag in <system.web>:

<authentication mode="Forms">
<forms>
<credentials passwordFormat="SHA1">
<user name="elmah" password="<<<YOUR_SHA1_HASHED_PASSWORD>>"/>
</credentials>
</forms>
</authentication>

• Add a location element to protect elmah.axd:

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

• Add a madam element, like after the elmah element:

<madam>
<userSecurityAuthority realm="ELMAH" provider="Madam.FormsUserSecurityAuthority" exposeClearTextPassword="false "/>
<formsAuthenticationDisposition>
<discriminators all="true">
<!-- This discriminator helps detect redirection to the Forms login page. -->
<discriminator inputExpression="Response.RedirectLocation" pattern="login\.aspx\?returnurl\=" type="Madam.RegexDiscriminator"/>
<!-- These discriminators are based on the various locations  and requests for which Forms should be discriminated.  The conditions expressed by these discriminators  are OR'ed together in the absence of the all attribute. -->
<discriminator>
<discriminator inputExpression="Request.RawUrl" pattern="^/elmah\.axd"/>
</discriminator>
</discriminators>
</formsAuthenticationDisposition>
</madam>

That’s “all” Good luck!

Asp.NET + IIS 6 – Assembly caching?!

The last weeks am employee of one of our clients and me had some problems getting a project, I’ve build, running on IIS 6.
There was a website configured in IIS for the main webapplication, which was already running on their server, and my project would be placed in a subdirectory of that webapplication.
So I deliverd the project with the following files:

• Aspx pages
• A bin directory
• Stylesheet directory
• Images directory
• No web.config, because the root application already has one

We just couldn’t get it to work properly and I thought IIS was caching assemblies, even after a IIS reset and server reboot.
After some time someone found the problem; the assemblies in the bin directory cannot be placed in a subdirectory, if a website isn’t configured for that specific directory. So we placed the assemblies in the root webapplication’s bin directory, and it worked!