Asp.Net Forms Authentication when using iPhone UIWebView

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:

1. Add a folder in your web project named App_Browsers (right-click the project, choose: Add > Add ASP.NET Folder > App_Browsers).
2. Add a file in that folder (right-click, choose: Add > New Item). The file can have any name, but must have the .browser ending.
3. Add a good matching expression and the correct capabilities (or add changes to the Default).

Two examples:

<browsers>
  <browser id="NokiaN8" parentID="Mozilla">
    <identification>
      <userAgent match="NokiaN8" />
    </identification>
    <capabilities>
      <capability name="browser" value="NokiaN8" />
      <capability name="cookies" value="true" /> 
    </capabilities> 
  </browser> 
</browsers>

Or change the default:

<browsers>
  <browser refID="Default"> 
    <capabilities> 
      <capability name="cookies" value="true" /> 
    </capabilities>
  </browser>
</browsers>

More info: Browser Definition File Schema

---

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.

<browser refID="Mozilla" >
    <capabilities>
        <capability name="cookies"  value="true" />
    </capabilities>
</browser>

---

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.

---

From the research I did, the reason why you can't set the User-Agent is that the UIWebView is setting the User-Agent value just before it sends out the request, that is, after you've made your request from your code.

The trick to get around this problem is to use something called "method swizzling", an advanced and potentially dangerous Objective-C concept that swaps out a standard method with one you provide. The end result is that when your request is sent out and the framework code adds the User-Agent it will be fooled into using the method you provided.

The following explains what I did to implement this but I am no Objective-C expert and would suggest to you to do some research to familiarize yourself with the technique. In particular, there was a link out there explaining better than me what is going on here, but at the moment I can't find it.

1) Add a category on NSObject to allow swizzling.

@interface NSObject (Swizzle)

+ (BOOL) swizzleMethod:(SEL)origSelector withMethod:(SEL)newSelector;

@end

@implementation NSObject (Swizzle)


+ (BOOL) swizzleMethod:(SEL) origSelector withMethod:(SEL)newSelector
{
    Method origMethod= class_getInstanceMethod(self, origSelector);
    Method newMethod= class_getInstanceMethod(self, newSelector);

    if (origMethod && newMethod)
    {
        if (class_addMethod(self, origSelector, method_getImplementation(newMethod), method_getTypeEncoding(newMethod)))
        {
            class_replaceMethod(self, newSelector, method_getImplementation(origMethod), method_getTypeEncoding(origMethod));
        }
        else {
            method_exchangeImplementations(origMethod, newMethod);
        }
        return YES;
    }
    return NO;
}
@end

2) Subclass NSMutableURLRequest to allow the swizzle:

@interface NSMutableURLRequest (MyMutableURLRequest)

+ (void) setupUserAgentOverwrite;

@end
@implementation NSMutableURLRequest (MyMutableURLRequest)

- (void) newSetValue:(NSString*)value forHTTPHeaderField:(NSString*)field
{
    if ([field isEqualToString:@"User-Agent"])
    {
        value = USER_AGENT;  // ie, the value I want to use.
    }
    [self newSetValue:value forHTTPHeaderField:field];
}
+ (void) setupUserAgentOverwrite
{
    [self swizzleMethod:@selector(setValue:forHTTPHeaderField:) 
             withMethod:@selector(newSetValue:forHTTPHeaderField:)];

}

@end

3) Call the static method to swap out the method. I made this call in didFinishLaunchingWithOptions:

// Need to call this method so that User-Agent get updated correctly:
[NSMutableURLRequest setupUserAgentOverwrite];

4) And then used it like this. (The connection delegate saves the data in a mutable array and then manually sets the UIWebView using its loadData method when it finishes loading).

- (void)loadWithURLString:(NSString*)urlString
{
    NSURL *url = [NSURL URLWithString:urlString];
    NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:url];
_connection = [NSURLConnection connectionWithRequest:request delegate:self];
[_connection start];
}

---

1. Have you specified a DestinationPageUrl in markup?

2. Have you specified the defaultURL in web.config?

Example web.config

<authentication mode="Forms">
     <forms loginUrl="~/Login.aspx" defaultUrl="~/CustomerArea/Default.aspx"/>
</authentication>

Example DestinationPageUrl

 <asp:Login ID="Login" runat="server" DestinationPageUrl="~/Secret/Default.aspx" />

Lastly have you looked in the cookie jar and seen if your session cookie actually exists?

Where are an UIWebView's cookies stored?

---

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:

         routes.MapRoute(
            "CookieLess", // Route name
            "(F({Cookie}))/{controller}/{action}/{id}", // URL with parameters
            new { controller = "Home", action = "Index", id = UrlParameter.Optional } // Parameter defaults
        );

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.