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?
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 usingFormsAuthentication.GetAuthCookie()
followed by aResponse.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 onFormsAuthentication.CookieMode
property, which relies on the<forms cookieless="">
attribute.By default, if the
<form>
cookieless
property is not set, it defaults toUseDeviceProfile
, which 51degrees reportsfalse
for so forms authentication will not look at or set the cookie.Manually setting
<form cookieless="UseCookies">
forcesFormsAuthentication.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 acookieless
attribute. It's set toUseCookies
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