SP2010: Custom FBA login form and mobile access

Logging from a mobile device into SharePoint sometimes causes unexpected problems / behaviour. This has different causes, which I want to review here. There are probably more possible problems then I have encountered, so when you know any other goods tips when it comes to mobile use of SharePoint, feel free to leave a comment!

To begin with, I want to share my setup with you. We have a dual front-end setup which uses claims based authentication. On one side, there are Active Directory users logging in with their AD account (Windows). On the other there’s a SQL database with ASP.NET membership users which log in forms based. On top of that, we also have a customized login form which gives a better login experience than the default login form with the dumb dropdown box no one understands.

For the client, I’m mainly talking phones and tablets, and in particular Windows Phone 7.5 (Mango) devices with the Office hub. To be clear: I don’t have such a phone myself (yet), so I collaborated with a colleague of mine to test all of this. Here’s what we encountered.

Our site seemed to be unavailable through the Office hub. Since this works for sites with the standard login page, our custom one was most likely the culprit. On other devices like my Android tablet; the login works in some browsers, but others will throw a 403 unauthorized exception. It seems like this is caused by our custom login form not being provided to those browsers due to compatibility settings. Our login form is a ‘grown up’ aspx page and SharePoint has a browser compatility list which prevents normal pages from being rendered onto mobile devices. If you want to alter that list, you can find it at c:\inetpub\wwwroot\wss\virtualdirectories\site\App_Browser\compat.browser.  Look for the isMobileDevice property set to true; for those browsers / devices your normal pages won’t render.

I was unable to overcome this. Either the Office hub knows how to handle the default page and doesn’t understand our custom one, or SharePoint’s default login has somekind of redirect mechanism for mobile devices. Either way, a 403 was all we were getting out of it.

To get around this, we tried extending our web application with a second entry point, not having our custom login page in place. And hey! That seemed to work! We were getting the default login (unfortunately with the stupid dropdown, but that’s better than nothing right?). But now, after selecting Windows authentication, an error was thrown about strReturnUrl not being a valid property for SPMobilePage. Eehhh… whut?

After some looking around on the net, I found some sites claiming that this error didn’t exist untill the December 2011 CU (see http://www.spugs.ch/SPUGSBlog/Lists/Posts/Post.aspx?ID=64, which is in German). The fix turned out to be pretty easy. Open up this file:

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\MOBILE\mbllogin.aspx

And look for SPMobilePage.strReturnUrl appearances. There are three. Simply replace those by strReturnUrl instead, which is a valid variable in this script. Seems like one MS engineer made a bit of a fuck up and packed an invalid form into one of the updates. At least I don’t see any way this could have got anything to do with our custom login page.

Anyways, after fixing that error; you should be able to do a normal mobile login with your device and be redirected to a SharePoint page. This will also be enough to fix access via the Office Hub on your Windows Phone device. It started working for us at least! The only downside to this approach is that you’ll need a second URL for mobile usage. Should we find a way to handle all of this without extending a web application, I’ll make sure to update this blogpost.

Ah, and one final notice. It’s not unlikely Microsoft didn’t fix the MBLLOGIN.ASPX page in the current CU (which I haven’t installed yet). So it could well be overwritten once you install that, make sure you check your file after updating!

Leave a Reply

Your email address will not be published. Required fields are marked *