Galloway marathon calculator app

…and as a follow up to my last post, I also wanted an easy way to calculate what my overall time over 50 miles might be which is a slightly annoying calculation when you’re running for 4 minutes at speed x then walking for 45 seconds at speed y and you have z checkpoints and you spend a certain amount of time in those checkpoints. So I also wrote a calculator to capture all of those variables to help me fine tune my strategy. 

Source is also available on GitHub.

Of course in the end my strategy was just to keep going and try not to be sick, but it was nice to have the app anyway.

Android Lap Timer app

When I was training for my first ultra-marathon, I used the Galloway run-walk marathon training method, where you run for a bit and then walk for a bit (read about it here). I had been using 5 minutes running and then 1 minute walking and then later I moved to 4 minutes running and 45 seconds walking. 

I had programmed an advanced workout into my Garmin 405 to beep at me and help me maintain this cycle. On my 25+ mile training runs I realised that the Garmin (which I hate for many other reasons also) was not going to last the course before the battery died. I didn’t want to be clock watching while running this thing so I decided to create a (very) simple Android app. I just enter the run time in seconds and the walk time in seconds and hit start and it beeps and vibrates at the end of each cycle. 

On many occasions when the Garmin was having one of its hissy fits this simple Android app came to the rescue and it performed beautifully on the day of the race too. 

For the 0.000001% of the population that run for more than 6 hours, use a run-walk approach to  training, are on the exact version of Android that I am and know how to build it – you can find the source on my GitHub!

Forms Authentication for SSRS using SqlMembershipProvider

Sql Server 2008 includes a sample solution explaining for to write a security extension that will enable SSRS to work with Form Authentication. By default you will find this sample in the C:\Program Files\Microsoft SQL Server\100\Samples\Reporting Services\Extension Samples\FormsAuthentication Sample directory.

It’s reasonably easy to follow the instructions for this sample and the general idea is simple. You tell SSRS that you’re going to take care of authentication yourself and then you implement some code to capture and verify the user’s credentials.

When you’re trying to implement Forms Authentication you might be forgiven for thinking that you would just somehow use one of the membership providers already present in the .Net framework. That’s what I was expecting, but when you look at the sample code you see a class called AuthenticationUtilities containing all sorts of hideous manual Ado.Net queries (complete with hard-coded connection strings), and all sorts of nasty scary password hashing code. For example, the VerifyPassword method in this class does the following:

• Retrieves the hashed password from the UserAccounts db
• Hashes the supplied password using the same salt (though it is not necessarily using the correct hash algorithm
• Compares the two hashes to see if they match

Not too much wrong with that, but if you decompile the SqlMembershipProvider you will find that it does pretty much exactly the same thing, but the code is a more robust.

This means that you can replace the contents of VerifyPassword with a call to Membership.ValidateUser(user, password). All you have to do to make this work is to set it up in the Report Server web.config exactly like you would in a normal web application:



<connectionStrings>
    <add name="UserAccounts" connectionString="server=*******;database=UserAccounts;uid=**;pwd=*****;Connection Reset=false;" />
</connectionStrings>

<authentication mode="Windows" />

<authentication mode="Forms">
      <forms loginUrl="Logon.aspx" 
             name="SqlAuthCookie" 
             timeout="90"
             enableCrossAppRedirects="true"
             path="/" >
      </forms>
</authentication>

<identity impersonate="false" />

<authorization>
      <deny users="?" />
</authorization>

<membership defaultProvider="SqlMembershipProvider">
      <providers>
        <add applicationName="MyApp" 
             connectionStringName="UserAccounts" 
             name="SqlMembershipProvider" 
             minRequiredPasswordLength="1" 
             minRequiredNonalphanumericCharacters="0" 
             requiresQuestionAndAnswer="true" 
             requiresUniqueEmail="false" 
             type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
      </providers>
</membership>



Note that you can and should use aspnet_regiis to encrypt that connection string.

In all the hours of googling involved in getting this to work I didn’t find any reference to the fact that it was perfectly possible to use the SqlMembershipProvider just like you would in a normal web application and leave all the nasty password handling to the experts. I’ve no idea why they decided to write the samples in this way…