Support environments without popups (phonegap, etc.)

[callahad]

Several folks on dev-identity are asking about getting BrowserID to work with things like PhoneGap. Apparently one of the primary issues is opening a popup: it opens in a browser outside of the PhoneGap application, breaking the connection between Persona and the app.

[callahad]

I imagine that simply redirecting into and out of our login flow, instead of using a popup, might Just Work with the Observer API, since we would automatically fire an assertion when landing back on the RP...

[benadida]

@callahad yes, that's exactly the idea I've been discussing with Dan for Chrome/iOS support and UIWebView support.

[seanmonstar]

I have always found it skeptical when an app uses an internal webview to
show me an oauth page. Its trivial to inject your own JavaScript to read
your credentials as you type them.

[benadida]

@seanmonstar I'm with you except.... what other option do we have? Eventually I'd like Firefox to act as the Persona implementation, no passwords. But that's a bit further down the line.

[seanmonstar]

Yea I know.

Well, for Android at least, we could offer a Persona app, and then other
apps can launch an org.persona.INTENT_AUTH intent.

Not possible on iOS, plus it requires Android users to download a second
app, which might discourage devs from using Persona as a login....

[vthunder]

That would be possible on iOS, apps use custom protocol handlers to do that. But having to download a second app is, IMO, a non-starter. Our only hope is to piggy-back onto another app (like Firefox or Marketplace).

[max-mapper]

there is a plugin for phonegap called ChildBrowser that is cross-platform and lets you open browser window popups for doing things like oauth. it can be used right now for browserid on phonegap

[sintaxi]

Happy to see this issue on the list. This is an important use case to cover.

As @maxogden says, ChildBrowser is the way to go. The problem is that persona (as far as I know) doesn't give you control over how the popup window opens.

[callahad]

This feels really high priority, but low urgency at the moment. It'd be awesome to have a really well fleshed out mobile story in Q3. Especially with Chrome on iOS needing this, etc.

[shane-tomlinson]

Making this the new consolidated tracker bug so we can close down others.

issue #75
issue #428
issue #1822
issue #1870
issue #1946

[warner]

This feels like a candidate for the new beta2-req label.

[lloyd]

now part of our Q3 goals... 👍 to the beta2 label.

[wfwalker]

I have similar symptoms, Ben asked me to mention them here.

Steps to reproduce:

1. visit marketplace.mozilla.org from Mobile Safari on iPhone 4 running iOS 5.
2. choose "Add to Home Screen" from links at the bottom
3. launch the newly created marketplace icon in the home screen
4. click on the "log in / register" button
5. sit at the "Connecting to Persona..." screen forever

[redalastor]

It should also be possible to use the redirection even if you aren't on a mobile app.

I have a use case where a forum I use supports single sign on by opening my "login page" in a popup. My login page would simply use the persona redirection to do its job. Right now, it gives me a popup opening a new popup.

[jchris]

Just want to add that I was able to reproduce @wfwalker's 5 steps on iPad running iOS 6.1

As someone trying to put together a PhoneGap app, it would definitely be helpful to have a comment on this bug with an idea of the priority or the blockers for adding robust PhoneGap support. I'm about to brute-force my app to work, which probably won't be pretty, and if there was a little more guidance about design issues, I'd be more likely to do work that could be contributed back to Browserid.

If my brute force hacks are at all illuminating, I'll follow up with links.

[marknutter]

Decided not to use Persona as a result of this issue. Definitely high priority if you ask me.

[benadida]

@marknutter thanks for the feedback, we are working on this and we do plan a fix. Please consider watching this bug and adding Persona once we've addressed your issue!

[marknutter]

What's the general plan for solving this problem? An in-page javascript modal or something? Also, how can I contribute as a developer?

[benadida]

@marknutter I'll let @seanmonstar give you details, but high-level we're thinking that we'll detect when popups are not possible and implement a redirection-based flow. If you're using the Persona Observer API, i.e. .watch(), you don't need to do anything: it will just work.

[marknutter]

oh, wait, so there's actually a way to do this manually right now via the Observer API? From the blog post about the Observer api: "Whenever a user clicks the login button on your site, you request() a verified email from your user, which opens the Persona dialog." - is that Persona dialog a popup window?

[callahad]

@marknutter Alas, not quite yet. I believe the plan is to have the Observer API automatically detect when popups aren't enabled, and then switch to a redirect-based workflow. So if you implement the Observer API now, you'll eventually get a popup-free experience where needed.

For what it's worth... what specific aspects of the popup blocked you from using Persona? Was it the lack of support in Phonegap or similar?

[redalastor]

Will there be an option to choose the redirection workflow even if popups
are detected as possible?

On Wednesday, March 6, 2013, Dan Callahan wrote:

@marknutter https://github.com/marknutter Alas, not quite yet. I
believe the plan is to have the Observer API automatically detect when
popups aren't enabled, and then switch to a redirect-based workflow. So if
you implement the Observer API now, you'll eventually get a popup-free
experience where needed.

For what it's worth... what specific aspects of the popup blocked you from
using Persona? Was it the lack of support in Phonegap or similar?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2034#issuecomment-14507461
.

[callahad]

@tavisrudd This should now work in production on Chrome / iOS. Can you please confirm?

[tavisrudd]

Yep, it works fine now. Thanks :)

[jamesshore]

Could somebody clarify what went into production? I just had a user complain that they couldn't login when using iOS Chrome.

[shane-tomlinson]

@jamesshore - if a site uses the navigator.id.watch API, users of Chrome for iOS will be able to sign in. Chrome for iOS has a technical limitation where a dialog window is unable to communicate with its parent window. To get around this, we do what is called the "redirect flow" where a user is redirected from your site to Persona to authenticate, then back to your site. This only works for the navigator.id.watch API because neither .get nor .getVerifiedEmail provide us with a way to pass an assertion back to the RP after redirecting back from Persona. If your site uses .get or .getVerifiedEmail, please update to .watch - more information can be found on MDN.

[jamesshore]

@shane-tomlinson Ah, that explains it. Yes, I'm using the old API. I've been meaning to update it anyway. Thanks!

[aravindet]

I have a use case for a preferRedirect option on navigator.id.request():

My application (Scrollback) is an IRC widget embedded on third party sites, and I'd like to open a popup to sign users in; if I use Persona there would now be two popups.

As an analogy, imagine if Gmail or Yahoo decided that their OAuth sign in pages wouldn’t support a redirect flow - the Persona identity bridges would have to spawn additional popups, and the experience would be terrible.

We're currently working around this issue by opening our login screen in an iframe on the third-party sites; this still results in three layers showing up: The host site, the scrollback login iframe, and the persona popup. You can see this happen on mozillaindia.org (which uses Scrollback).

[lloyd]

@aravindet so this is the 4th similar request I've heard in the last several weeks. I think delegating control over the experience to the website via such a flag might be the right thing to do. please open another issue specifically about this. there's also a thread in the mailing list where we discussed this, feel free to start a new thread or re-open that one.

[stadja]

Right now, it works very well on my windows phone 7 lumia 710 !
thanks guys....
What a wonderful improvement :)

[abritez]

I just attempted to build PhoneGap application using their Command Line process

    > cordova build ios
    > cordova emulate

I change my original get() call to a watch() . The sample i used was grabbed from here https://npmjs.org/package/express-persona

Javascript (should I be using another file?)

         <script src="https://login.persona.org/include.js"></script>

Watch code

      navigator.id.watch({
        onlogin: function(assertion) {
            var xhr = new XMLHttpRequest();
            xhr.open("POST", "/auth/browserid", true);
            xhr.setRequestHeader("Content-Type", "application/json");
            xhr.addEventListener("loadend", function(e) {
                var data = JSON.parse(this.responseText);
                if (data && data.status === "okay") {
                    console.log("You have been logged in as: " + data.email);
                }
            }, false);

            xhr.send(JSON.stringify({
                assertion: assertion
            }));
        },
        onlogout: function() {
            var xhr = new XMLHttpRequest();
            xhr.open("POST", "/persona/logout", true);
            xhr.addEventListener("loadend", function(e) {
                console.log("You have been logged out");
            });
            xhr.send();
        }
    });

OnClick call to signal Login request

  navigator.id.request();

Also took an unsuccessful chance at using

  navigator.id.request({preferRedirect: true}); 

Everything works fine on the desktop, and iOS safari. Issue with PhoneGap and iOS Safari that has been added to HomeScreen. Am I missing an opt-in flag or something? According to previous comments is sounded like this should work.

[seanmonstar]

A proposed declarative HTML API could solve most the rest of the issues involved, as it proposes POSTing back to a URL. See discussion: https://groups.google.com/d/topic/mozilla.dev.identity/12PW2Z-YPps/discussion

[kahing]

I am using persona on my own "app", which is now just a website (so no phonegap). Everything works fine, except if I use chrome on android and use the "add to home screen" feature to pin the website to the android home screen. If I do that then I get an error like #2034 (comment)

[lefos987]

Hi.
I tried to use Persona with a standard PhoneGap application. I keep getting the same error as the one descirbed above.
From my understanding reading through this thread it seems that there has been a fix that went through however it still does not seem to work for me. I would appreciate any indication/help of how to resolve this.
Thank you

[callahad]

Looks like we may need to force PhoneGap / Cordova into the redirect workflow, instead of using popups. That would require editing this set of regexes to add PhoneGap detection: https://github.com/mozilla/persona/blob/32af5485ec5368cd0634d6ebd74f9a53a37f313f/resources/static/include_js/_include.js#L133-138

Patches welcome :)

(Whitelisting isn't ideal, but it's the most expedient thing we have at the moment.)

[lefos987]

Don't know if you can find it with via userAgent but windows.cordova object might do the trick. What do you think?

[callahad]

That sounds reasonable. I can have something up for testing tomorrow, or you could grab the repo and try it yourself :)

[lefos987]

Trying to test this locally. Not sure if I am doing it correctly:

1. npm install and npm start -> results in a local version running in http://127.0.0.1:10002
   (checking the console i get the following errors:
   GET http://localhost:10002/i18n/en/client.js 404 (Not Found)
Resource interpreted as Script but transferred with MIME type text/html: "http://localhost:10002/common/js/templates.js".
2. in my local include.js i changed the ipServer to point to the above.
3. added an extra check for window.cordova in the needsPopupFix
   4.in layout.ejs I updated the reference from https://login.persona.org/include.js to my local include.js file.
   Now when I open my phonegap app and click login I get a different error:
   
   Checking my simulator's console with Safari, I see that I also get the same errors as described in step 1.
   I am sure I miss something but can't really test this properly. Wish I could help more...
   @callahad Let me know if you manage to get something up for testing or point me to what i am doing wrong so i can test it locally properly. Thanks a lot :-)

[callahad]

Doh! You're doing everything right, but I forgot that Cordova / PhoneGap will have a file:// URI instead of an http:// or https:// URI, and we limit the available schemes here: https://github.com/mozilla/persona/blob/32af5485ec5368cd0634d6ebd74f9a53a37f313f/resources/static/common/js/lib/urlparse.js#L72-73

Basically, using file:// opens up a lot of security issues: we can't easily differentiate between your app and other local apps, which opens the door for re-using assertions (see issue #3323).

This is going to sound ridiculously convoluted, but can you place the Persona login button in an iframe that points to an actual website? (Wow, this is not easy. Sorry!)

[lefos987]

Thanks a lot @callahad
Yes I was pretty sure it was a problem with file://. Will try the iframe solution.
Just to be sure that I do not miss something obvious. There is no other way at the moment (eg. phonegap plugins) to get Persona to work as expected in a Phonegap application?

[callahad]

@lefos987 I haven't actually worked with PhoneGap, but earlier in the thread the Child Browser plugin was suggested. Maybe that will work for you?

[lefos987]

Tried the iframe solution. Basically put my login/logout buttons in an iframe served by a nginx webserver. When I click login now:

1. the persona server does indeed receive a GET request for /sign_in but does not successfully process it.
2. debugging I see that my sign_in view is not served since one of the response headers is x-frame-deny which i guess stops it from working (although i get 200 back )
3. tried to add the /sign_in path in the X_FRAME_ALLOWED constant in lib/static/views.js and although I do not get the x-frame-deny response header the view is not successfully loaded (although i still get 200 back).
   Just thought I would share this. Happy to try something else or change my approach if there are any suggestions.

[callahad]

@lefos987 Oof. I'm sorry again about the pain here. Realistically, this might not be cleanly solvable in the near future, as we don't have a lot of development bandwidth on our side, so you might want to go with an alternative option if getting your project out the door is the most important. On the other hand, if you're enjoying hacking on this, I'd love to review a pull request to make this work, or review a blog post detailing necessary workarounds to get Persona running under PhoneGap.

[lefos987]

@callahad sure thing! Will keep trying to see what the best way to achieve this is.
Thanks for the suggestions

[cappelaere]

Bummer... I am stuck at the same place. So close....getting persona to work with Ionic-angular-cordova... Any progress by any chance? Just asking :)

[callahad]

Hi! To help us better focus, I'm "closing" all issues that have been open for more than six months. These have been tagged "cleanup-2014" so that we can go back and review them in the future.

For more information, check out this thread: http://thread.gmane.org/gmane.comp.mozilla.identity.devel/7394

If you believe this bug is still a major issue for you, please comment, submit a pull request, or discuss it on our mailing list: https://lists.mozilla.org/listinfo/dev-identity

Sorry for GitHub notification spam!

[sbirch]

+1, just got bitten by this.

IMO a disclaimer you might want to make up front -- IIUC Persona doesn't work for any kind of mobile web app.

[djc]

The latter is not true; it works fine for me on Firefox for Android.