New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OAuth redirect does not work properly on Chrome for iPhone #2302

Closed
gdiab opened this Issue Jul 11, 2014 · 28 comments

Comments

Projects
None yet
7 participants
@gdiab

gdiab commented Jul 11, 2014

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

This comment has been minimized.

Contributor

estark37 commented Jul 11, 2014

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

This comment has been minimized.

Contributor

timhaines commented Jul 11, 2014

@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

This comment has been minimized.

Contributor

pscanf commented Jul 14, 2014

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. :-)

@estark37 estark37 closed this in 8236854 Jul 14, 2014

@gdiab

This comment has been minimized.

gdiab commented Jul 29, 2014

Fix appears to be working great! Thank you Emily!

@estark37

This comment has been minimized.

Contributor

estark37 commented Jul 29, 2014

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.

jperl added a commit to jperl/meteor-phonegap-oauth that referenced this issue Aug 2, 2014

@gdiab

This comment has been minimized.

gdiab commented Aug 9, 2014

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

This comment has been minimized.

Contributor

estark37 commented Aug 10, 2014

@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

This comment has been minimized.

gdiab commented Aug 11, 2014

Perfect. Thanks!

@Gerst20051

This comment has been minimized.

Gerst20051 commented Aug 11, 2014

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

@gdiab

This comment has been minimized.

gdiab commented Aug 11, 2014

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

@Gerst20051

This comment has been minimized.

Gerst20051 commented Aug 11, 2014

@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

This comment has been minimized.

gdiab commented Aug 11, 2014

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

This comment has been minimized.

Contributor

estark37 commented Aug 11, 2014

@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

This comment has been minimized.

gdiab commented Aug 11, 2014

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

@estark37

This comment has been minimized.

Contributor

estark37 commented Aug 11, 2014

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

This comment has been minimized.

gdiab commented Aug 11, 2014

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

This comment has been minimized.

Contributor

estark37 commented Aug 11, 2014

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

@estark37

This comment has been minimized.

Contributor

estark37 commented Aug 11, 2014

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

This comment has been minimized.

gdiab commented Aug 11, 2014

awesome. thanks.

@gdiab

This comment has been minimized.

gdiab commented Aug 12, 2014

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

This comment has been minimized.

Contributor

estark37 commented Aug 12, 2014

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

@gdiab

This comment has been minimized.

gdiab commented Aug 12, 2014

ah! I thought it was already available...

@gdiab

This comment has been minimized.

gdiab commented Aug 15, 2014

@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

This comment has been minimized.

Contributor

estark37 commented Aug 15, 2014

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

@gdiab

This comment has been minimized.

gdiab commented Aug 15, 2014

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

@estark37

This comment has been minimized.

Contributor

estark37 commented Aug 15, 2014

@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

This comment has been minimized.

jggonz commented Nov 6, 2014

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.

@Krisa

This comment has been minimized.

Krisa commented Dec 16, 2015

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment