I am writing a Asp.net MVC 2 application that uses Forms Authentication and currently I am having a problem with our iPhone application in regards to the authentication/login over the web. We have developed a simple iPhone app that uses the the UIWebView control. At this stage, all the app does is navigate to our Asp.Net website. Simple, right? The problem is, that the user cannot get past the login page. The repro steps are:
- Open iPhone app.
- The app navigates to the home page.
- the user is not authenticated, so they are redirected to the login screen/page
- The user enters the correct user name and password. clicks submit.
- on the server side, the user is authenticated and a cookie is generated and sent to the client using FormsAuthentication.GetAuthCookie.
- The server sends are redirect to send the user to the correct home page.
But the user is then redirected BACK to the login screen!
I've done some extensive debugging on this and what I do know is:
The cookie is being sent to the client, and the client is storing the cookie. Verified this in the iPhone debugger and also by using Javsascript to display cookie data on the page. The cookie is being sent back to the server. Verified this in the Visual Studio debugger. It is the correct cookie (it's the same one that was set). The property User.Identity.IsAuthenticated returns false for some reason, even though the auth cookie is contained in the Request object. I have verified that the iPhone app is setup to accept cookies, and they are on the client.
Here is the funny thing: It works fine if you open the Safari browser on the iPhone and go to our site directly.
It has the same behaviour on the iPad too in that it doesn't get past the login screen. This repros on the emulators, and on devices.
This same web site has been tested with IE 7-8, Safari (for Windows), Blackberry, IEMobile 6.5, Phone 7 and it works find. The only circumstance that it doesn't work on is the UIWebView in the iPhone app.
I had exactly the same problem, but with another device (NokiaN8), and also traced the problem back to the User-Agent.
IIS uses regular expressions to match against the User-Agent string. The root of the problem was that it didn't have any matching regular expressions for the specific device, and ended up in one of the lowest levels of match, where the Default properties were used. The default properties said that the browser didn't support cookies.
Solution:
App_Browsers
(right-click the project, choose:Add > Add ASP.NET Folder > App_Browsers
).Add > New Item
). The file can have any name, but must have the.browser
ending.Default
).Two examples:
Or change the default:
The solution we found was to create a file (generic.browser) and include this xml to tell the web server that "Mozilla" and the Default browser settings should all support cookies.
This is fixed in ASP.NET 4.5 and all browsers are assumed to support cookies, so the extra .browser file won't be needed.
The reason of this happening apparently has to do with the fact that if the user-agent is not known then the browser is assumed to not accept cookies (as others have answered), and instead IIS puts the ASPXAUTH value in the URL.
However the MVC routing system apparently missed that possibility, which is clearly a bug, and therefore it is getting messed up.
While adding the .browser with a custom user-agent solves the problem, it does not guarantee that other user-agents will also be solved, and in fact I have found the K9 Browser for the android also has this problem, and as such it is only a solution if one has a logging system such as elmeh to track down such errors.
On the other hand adding a default brings up the question if it is true that all browsers accept cookies, which is apparently the reason why IIS does not assume so.
However besides adding explictly the user-agents one can add in the global.asax RegiterRoutes() method an explicit handler to ignore it, as follows:
However in this case one will have to copy all route entries to match with the cookie-less situation, unless one is about to write a custom route handler.
Or we can use the above cookie-less route to send the user to an error page explaining that his browser is not supported on the moment, and send an alert to the web-master with the user-agent to handle it.
Have you specified a DestinationPageUrl in markup?
Have you specified the defaultURL in web.config?
Example web.config
Example DestinationPageUrl
Lastly have you looked in the cookie jar and seen if your session cookie actually exists?
Where are an UIWebView's cookies stored?
I had the same exact problem, researched & consolidated a complete solution (from above answers and other threads) here: http://www.bloggersworld.com/index.php/asp-net-forms-authentication-iphone-cookies/