OAuth redirect does not work properly on Chrome for iPhone

[gdiab]

Chrome for iPhone version 35.0.1916.41

OAuth login redirect will either fail (blank white page in a new tab) or the redirect takes place but sign in does not take place.

the same steps work fine on Safari on iPhone as well as Chrome on the desktop.

[estark37]

Hi @gdiab -- thanks for the report. It looks like this is happening because iOS Chrome doesn't implement window.opener: https://code.google.com/p/chromium/issues/detail?id=136610

We'll have to work around this somehow, but not sure how off the top of my head (for example, we could store the credential secret in sessionStorage instead of using window.opener, but that won't work in Safari private browsing mode: http://stackoverflow.com/questions/18860098/on-a-browser-sessionstorage-in-safaris-private-browsing-does-not-work-the-same). I'll keep you posted!

[timhaines]

@estark37 I wouldn't be surprised if this is because Chrome is simply using iOS's UIWebView. Meteor will have this problem in all non-safari apps on the iPhone.

[pscanf]

Just my two cents if they can help.

My solution to the problem was to post a message to the popup window every 100ms. When the popup picks up the message, it gets a reference to the opener window, so it can reply.

I (hopefully) avoided possible security breaches by restricting message posting only to certain domains the user configures.

I'm not sure it works on chrome for iOS though, but I post it anyway as a suggestion for a possible alternative. :-)

[gdiab]

Fix appears to be working great! Thank you Emily!

[estark37]

Glad to hear that, @gdiab. To be honest, though, I should point out that it's a very brittle fix, so it's possible that some future Chrome update could cause it stop working. I wasn't able to really figure out when window.close() works (or doesn't work) in iOS Chrome, so we're now doing a hack to close the popup window that depends on what is almost certainly a Chrome bug.

Our next steps are to implement redirect-based OAuth (which should work much more reliably in iOS apps that use UIWebViews), and to file a Chromium bug to straighten out just how window.close() should work and in what cases we can rely on it to close the OAuth popup.

[gdiab]

I have noticed an issue with the redirect inside a webview. For example if a user clicks a link for the meteor app from the facebook app, the app opens inside facebooks webview. Trying to Auth inside this webview redirects to a blank white page.

should I open a new bug?

[estark37]

@gdiab This fix was specifically for iOS Chrome and won't work in any other app. We're currently working on a redirect-based OAuth implementation that should work much more reliably on mobile.

[gdiab]

Perfect. Thanks!

[Gerst20051]

@gdiab is there a way to detect if you're in a webview?

[gdiab]

I would assume the useragent might offer a hint? But I am not sure. What are you thinking @Gerst20051?

[Gerst20051]

@gdiab you're right. http://stackoverflow.com/questions/4460205/detect-ipad-iphone-webview-via-javascript

you could check and degrade gracefully until we come up with a workaround.

[gdiab]

I think we could do that...but I am not sure I understand the flow. What should I do if I detect I am in a webview? Am I changing the loginUrl?

var loginUrl =
'https://www.facebook.com/dialog/oauth?client_id=' + config.appId +
'&redirect_uri=' + Meteor.absoluteUrl('_oauth/facebook?close') +
'&display=' + display + '&scope=' + scope + '&state=' + credentialToken;

[estark37]

@gdiab Current plan is that one the redirect flow is implemented, there will be an option to Meteor.loginWith<ExternalService> to choose the login style, so something like this:

if (inUIWebView) {
  Meteor.loginWithFacebook({ loginStyle: "popup" }, callback);
} else {
  Meteor.loginWithFacebook({ loginStyle: "redirect" });
}
``

[gdiab]

ok. If I want to override this package, I just can copy and modify these files in a local package?

[estark37]

Yes, you can always change a package by copying it into your app, but I'm not sure why you need to override anything to do this (unless maybe you're referring to the 'accounts-ui-unstyled' package?)

[gdiab]

We are currently using meteor-accounts-ui-bootstrap-3. So I guess I need to get into the guts in this package to get the workaround done?

[estark37]

Yep. Or maybe the author of that package will expose a similar API for you to use once the redirect flow is released.

[estark37]

Oh, another hacky option is that you could just override Meteor.loginWith<ExternalService>, and then you wouldn't have to fork any packages:

var origLogin = Meteor.loginWithFacebook;
Meteor.loginWithFacebook = function (options, cb) {
   if (insideUIWebView) {
     origLogin(_.extend(options, { loginStyle: "redirect" }), cb);
   } else {
     origLogin(options, cb);
   }
};

[gdiab]

awesome. thanks.

[gdiab]

is loginStyle redirect the right option to set? any other options to consider? looking at the source of the facebook package, permissions are the only thing set

[estark37]

We're not sure yet since it isn't implemented. I'll let you know.

[gdiab]

ah! I thought it was already available...

[gdiab]

@estark37 Any idea when it might be available to check out? I'm antsy for a fix, and I don't want to spin my wheels if you're close.

[estark37]

I would guess 1-2 weeks until there's a working version on a branch (or maybe even on devel)

[gdiab]

Thanks. I'll see if I can hack together a workaround.

[estark37]

@gdiab If you're super adventurous you can run off #2394. That should be more or less working, but the 'loginStyle' option that I mentioned above isn't implemented yet, and you won't get any callback (either for error or success) when the user lands back on the app after going through the login flow. You'll have to do a Deps.autorun that uses Meteor.user() to check whether the user has successfully logged in.

[jggonz]

I was having the same issue with a Linux version of Chrome and Safari. Here's what I did to resolve it:

Before building or deploying, edit the file:
/home/quikdash/.meteor/packages/oauth/1.1.2/os/packages/oauth/end_of_popup_response.html

and move the line

div id="config" style="display:none;"##CONFIG##/div

right after the body tag.

Some browsers run

document.getElementById("config").innerHTML

from storeAndClose() before rendering the div id='config' .... tag.

Hope that helps.

[0cv]

@estark37 Coming back on your latest comment, this is a quite old issue, which has been closed, but could it be that the callback is not yet called when the loginStyle is a redirect? This is at least what I see in my flow.