0

I have an existing ASP.NET MVC app that uses custom forms-based authentication, by creating a FormsAuthenticationTicket and writing the auth cookie per the example at http://msdn.microsoft.com/en-us/library/system.web.security.formsauthenticationticket(v=vs.110).aspx.

Now, when I add a reference to the 51degrees mobile device detection framework, I'm stuck in an auth loop, with context.Request.IsAuthenticated permanently reporting false.

I've tracked it down to the fact that context.Request.Browser.Cookies is now also reporting false, which explains why my auth cookie isn't having any effect. But what would cause the library to think my desktop browser (Chrome in this case, if that makes any difference) suddenly didn't support cookies? Bug in the detection library? Misconfiguration or code error on my end? Something else?

drwestco
  • 142
  • 1
  • 9

1 Answers1

1

I just upgraded to 51degrees V3 using nuget and ran into the same problem.

You are correct - context.Request.Browser.Cookies is false so the authentication cookie doesn't get set AND even if one is there it doesn't get read. I tried manually setting it using FormsAuthentication.GetAuthCookie() followed by a Response.Cookies.Add() and it still didn't work.

I think it's a bug in the 51degrees library. But I do have a solution.

According to MSDN, FormsAuthentication.CookiesSupported relies on FormsAuthentication.CookieMode property, which relies on the <forms cookieless=""> attribute.

By default, if the <form> cookieless property is not set, it defaults to UseDeviceProfile, which 51degrees reports false for so forms authentication will not look at or set the cookie.

Manually setting <form cookieless="UseCookies"> forces FormsAuthentication.CookiesSupported to be true, so the auth cookie is set and read.

I tried that and authentication works again.

Source: http://msdn.microsoft.com/en-us/library/system.web.security.formsauthentication.cookiessupported(v=vs.110).aspx

--Edit--: The <sessionState> system.web element also has a cookieless attribute. It's set to UseCookies by default so that's why session state using a session cookie still works. Source: http://msdn.microsoft.com/en-us/library/h6bb9cz9(v=vs.100).aspx

Philip Holly
  • 713
  • 7
  • 18