Authentication on iOS Chrome / WebKitView

This forum is only for questions or discussions about working with the mojoPortal source code in Visual Studio, obtaining the source code from the repository, developing custom features, etc. If your question is not along these lines this is not the right forum. Please try to post your question in the appropriate forum.

Please do not post questions about design, CSS, or skinning here. Use the Help With Skins Forum for those questions.

This forum is for discussing mojoPortal development

This forum is only for questions or discussions about working with the mojoPortal source code in Visual Studio, obtaining the source code from the repository, developing custom features, etc. If your question is not along these lines this is not the right forum. Please try to post your question in the appropriate forum.

You can monitor commits to the repository from this page. We also recommend developers to subscribe to email notifications in the developer forum as occasionally important things are announced.

Before posting questions here you might want to review the developer documentation.

Do not post questions about design, CSS, or skinning here. Use the Help With Skins Forum for those questions.
This thread is closed to new posts. You must sign in to post in the forums.
8/15/2013 1:42:06 PM
Gravatar
Total Posts 3

Authentication on iOS Chrome / WebKitView

I have a small web application that I need to work on as many mobile devices as possible. One of the problems I'm running into is on Chrome on iOS, and/or in any WebKit view. It appears to be that cookieless mode is getting set, so they can't authenticate. The postbacks and asp:Buttons themselves work.

We're using a custom login page that inherits the Web.UI.Pages.LoginPage, so the <add key="LoginPageRelativeUrl"> is set. 

Basically, how can I force cookie authentication on this form?

Thanks.

8/15/2013 2:06:20 PM
Gravatar
Total Posts 18439

Re: Authentication on iOS Chrome / WebKitView

This is not a bug report so I moved this question to the developer forum.

I just tested logging into demo.mojoportal.com using Chrome browser on my iPad and it worked just fine. If you experience a problem with your own custom login page then look to how or if you are setting a cookie, I have no way to diagnose it for you.

As far as I know cookieless authentication in asp.net can only be configured by web.config and mojoportal will not be able to use that.

It is not something negotiated by the web browser. 

I do believe web browsers can be configured to not accept a cookie, but nothing in mojoportal code nor in your custom code could overcome that if the browser is configured that way.

8/15/2013 4:20:39 PM
Gravatar
Total Posts 3

Re: Authentication on iOS Chrome / WebKitView

Thanks for the response.

I'm honing in on the solution, I think, but it's still weird. For example, in mobile Chrome, when I "Request Desktop Site", authentication works fine. All that button does is change the UA String

From: Mozilla/5.0 (Linux; Android 4.0.4; Galaxy Nexus Build/IMM76K) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.166 Mobile Safari/535.19

To: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.45 Safari/535.19
 

Also, there are no cookies or anything manually set in the custom login form. It's simply a wrapper around the default mojo forms.

8/15/2013 5:12:43 PM
Gravatar
Total Posts 3

Re: Authentication on iOS Chrome / WebKitView

For anyone else who ever has this problem:

The problem was the User Agent strings combined with .NET 4. The solution was to check the Request.UserAgent in the page's Pre_Init, and if it contains "CriOS", to do this.ClientTarget = "uplevel".

8/16/2013 12:05:04 PM
Gravatar
Total Posts 18439

Re: Authentication on iOS Chrome / WebKitView

If that was the solution, my guess is it could also be solved by installing .NET 4.5, or you could use the solution here (found just now by a quick google) if you are compiling your own build, it requires adding a file to the /App_Browsers folder which requires rebuilding the project.

There are also other bug fixes in .NET 4.5, so if you have control of the machine, the best solution is to install .NET 4.5.

You must sign in to post in the forums. This thread is closed to new posts.