ASP Forms Authentication in myFerry

  • Article

As a previous post mentioned, I’ve added the AspProviders Azure sample to the myFerry app to provide for login and profile storage.

It works to allow me to login and retrieve and save profile information.  But there is – of course – a problem.  We developers live for these sorts of squirrelly problems.  If everything just went fine, our lives would be too boring.

The problem is that the “Remember me” checkbox isn’t working for some reason.  Poking around a bit, I found that this section of web.config sets up how authentication should work:

<!--
The <authentication> section enables configuration
of the security authentication mode used by
ASP.NET to identify an incoming user. Cookie is set
to expire 30 days after they use the site
-->
<authentication mode="Forms">
<forms loginUrl="signin.aspx"
defaultUrl="default.aspx"
timeout="43200"
path="/"
requireSSL="false"
slidingExpiration="true"
cookieless="UseDeviceProfile"
/>
</authentication>

 

Now this should set up a 30-day expiration policy (the timeout is specified in minutes, and it turns out that 30 days is 43,200 minutes).  The cookieless parameter has to do with what happens if the browser doesn’t accept cookies (e.g. in an Internet cafe).  In that case, the URL is mangled to include the cookie information to preserve it through the session, but of course the “remember me” won’t work in that case (which is by design – we don’t want to be remembered in an Internet cafe).   But in the normal case, the cookie should be set with the login information and then sent back to the site when the user returns.

In investigating this, I first grabbed a useful tool called ieHttpHeaders from Jonas Blunck which allows you to see the HTTP traffic between the browser and the server.  I’m a huge fan of Fiddler written by my friend Eric Lawrence but Fiddler doesn’t see localhost (127.0.0.1) traffic because of where it sits in the TCP/IP stack – ieHttpHeaders because it sits within the browser does see this traffic.  While debugging, of course, I’m running my Azure app in Development Fabric which uses 127.0.0.1.

Sure enough, I see the cookie set when I login and the expiration seems to be set with the correct expiration date (the red text below); this handshake that is part of forms authentication is discussed in this post on support.microsoft.com):

HTTP/1.1 302 Found
Cache-Control: private
Content-Type: text/html; charset=utf-8
Location: /Default.aspx
Server: Microsoft-IIS/7.5
X-AspNet-Version: 2.0.50727
Set-Cookie
.ASPXAUTH=D67AD6DEE17590B7121D1D084793A818E5D10CF61E58FDEEB44ACCC5FCFF365 C87D523013DF772761A54405811BFAA56A1CBE4A1385362BDAB1971 C6C5FB1518C0129D211EEB048DCF4DF847DA549BDF; expires=Sun, 07-Mar-2010 21:35:21 GMT; path=/; HttpOnly
X-Powered-By: ASP.NET
Date: Fri, 05 Feb 2010 21:35:21 GMT
Content-Length: 7210

And sure enough, when I return to the site later, I see the .ASPXAUTH cookie sent back as part of the get for default.aspx:

GET /Default.aspx HTTP/1.1
Accept: */*
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; InfoPath.2; OfficeLiveConnector.1.3; OfficeLivePatch.0.0; Tablet PC 2.0)
Accept-Encoding: gzip, deflate
Host: 127.0.0.1:82
Connection: Keep-Alive
Cookie: .ASPXANONYMOUS=0GoL6z3dygEkAAAAYTEzMDViOGQtNzI0Yi00Njh kLTkzY2ItZTgzMjM5MGIwNzE57PT5gooN5iH-wlyWqTBYSOPEYIo1; .ASPXAUTH=D67AD6DEE17590B7121D1D084793A818E5D10CF61E58FDEE B44ACCC5FCFF365C87D523013DF772761A54405811BFAA56A1CBE4A1385 362BDAB1971C6C5FB1518C0129D211EEB048DCF4DF847DA549BDF

But it doesn’t get seem to get used by ASP.Net – when I execute this code in my default.aspx PageLoad method:

 

if (HttpContext.Current.Profile.IsAnonymous)

I get that I am an anonymous user, not logged in as I would expect.  But the profile is empty.

I eventually tracked this down to a bogus SetCookie call at the beginning of the session – so each time I return, a new .ASPXANONYMOUS cookie value is set, overwriting the one from the previous session.

I finally decided to deploy my app to the Azure cloud even with this glitch – and was amazed that it stopped happening!  So the problem only occurs on the 127.0.0.1 localhost address used for debugging Azure – not with https://myferry.cloudapp.net, deployed in the cloud.

I still haven’t figured out why that is – but a debug-only bug I can live with!