Feature - OAuth Pinterest

[Slessi]

Added Pinterest OAuth

[nraboy]

Can you verify that this has been tested and working correctly? If yes, I will merge it because it looks good :)

[Slessi]

@nraboy Not sure this is possible actually :/ pinterest force me to use an httpS callback and if i make the callback https://localhost/callback I get a not found error in my app on callback.

Tried using v1.1.0 of inappbrowser too, as there was an issue open about that, but it didn't resolve it

[nraboy]

And when you override the options parameter it still fails?:

{
    redirect_uri: "https://localhost/callback"
}

Put that in there so people could override it, but for Pinterest, if it absolutely requires https and it works in the app, we can default it.

Let me know if an override to https fixes it.

Best,

[Slessi]

var redirect_uri = "https://localhost/callback";
if (options !== undefined) {
    if (options.hasOwnProperty("redirect_uri")) {
        redirect_uri = options.redirect_uri;
    }
}

That ^ results in -> this

After I get the prompt for "MyApp would like to access your information" and click "OK"

[nraboy]

Yea connection refused errors have to do with all the InAppBrowser nonsense that is circulating. I am going to keep this pull request open for a few days to see if Apache pushes a fix.

[Slessi]

@nraboy InAppBrowser v1.2.1 fixed the bug I was having. Turns out loadstart just wasn't firing on Android. Proceeded to test and it works OK.

Only issue there is is that the Pinterest OAuth page also has its own social logins (FB/Twitter/G+) and logging in with those instead of email & password actually logs you into pinterest. Though if you press back and wait a bit it asks if you want to validate your app which is weird.

Thoughts on how you would resolve this? Was thinking of using Insert CSS feature of in app browser to hide the buttons on load.

[nraboy]

What is the landing page after you sign in via social media? I don't feel right altering the provider determined flow UI since it was put there to build trust. Would feel better if we intercept the landing page instead. Do we still get an access token in this scenario?

Best,

[Slessi]

Here -> Click FB Login -> Here -> Login -> Here (a spinner appears on top of another "Login with facebook" button) -> You are now logged into pinterest Here.

Same happens with Twitter and Google+ lands you on a blank page. The regular email/password sign in works as intended though.

This is the response from logging in with FB.

[Slessi]

Pasted below the contents of event.url for the loadstart event throughout the process of FB/Twitter/G+ logins. FB Had a moment where the code was present and I could intercept but G+ and Twitter did not.

On my own fork I implemented the following which is sufficient for my purposes so I will be using this for now

var browserRef = window.cordova.InAppBrowser.open('https://...', '_blank', '...hidden=yes');

browserRef.addEventListener('loadstop', function(event) {
  browserRef.insertCSS({'code': '.socialLogin {display: none !important;}'});
  browserRef.show();
});

Pinterest social login flows:

------- FACEBOOK ----------
"https://www.pinterest.com/connect/facebook/"
"https://www.facebook.com/v2.2/dialog/oauth?scope=email%2Cuser_likes%2Cuser_about_me%2Cuser_birthday%2Cuser_friends&redirect_uri=https%3A%2F%2Fwww.pinterest.com%2Fconnect%2Ffacebook%2F&display=popup&client_id=xxx"
"https://m.facebook.com/v2.2/dialog/oauth?redirect_uri=https%3A%2F%2Fwww.pinterest.com%2Fconnect%2Ffacebook%2F&scope=email%2Cuser_likes%2Cuser_about_me%2Cuser_birthday%2Cuser_friends&client_id=xxx"
"https://m.facebook.com/login.php?skip_api_login=1&api_key=274266067164&signed_next=1&next=https%3A%2F%2Fm.facebook.com%2Fv2.2%2Fdialog%2Foauth%3Fredirect_uri%3Dhttps%253A%252F%252Fwww.pinterest.com%252Fconnect%252Ffacebook%252F%26scope%3Demail%252Cuser_likes%252Cuser_about_me%252Cuser_birthday%252Cuser_friends%26client_id%3D274266067164%26ret%3Dlogin&cancel_url=https%3A%2F%2Fwww.pinterest.com%2Fconnect%2Ffacebook%2F%3Ferror%3Daccess_denied%26error_code%3D200%26error_description%3DPermissions%2Berror%26error_reason%3Duser_denied%23_%3D_&display=touch&_rdr"
"https://m.facebook.com/login.php?api_key=274266067164&auth_token=xxx&skip_api_login=1&signed_next=1&next=https%3A%2F%2Fm.facebook.com%2Fv2.2%2Fdialog%2Foauth%3Fredirect_uri%3Dhttps%253A%252F%252Fwww.pinterest.com%252Fconnect%252Ffacebook%252F%26scope%3Demail%252Cuser_likes%252Cuser_about_me%252Cuser_birthday%252Cuser_friends%26client_id%3D274266067164%26ret%3Dlogin&refsrc=http%3A%2F%2Fwww.pinterest.com%2F&app_id=274266067164&lwv=100&refid=9"
"https://m.facebook.com/v2.2/dialog/oauth?redirect_uri=https%3A%2F%2Fwww.pinterest.com%2Fconnect%2Ffacebook%2F&scope=email%2Cuser_likes%2Cuser_about_me%2Cuser_birthday%2Cuser_friends&client_id=xxx&ret=login&ext=1454506177&hash=Aebc2RbXHr4E4a-z&refsrc=http%3A%2F%2Fwww.pinterest.com%2F&refid=9&_rdr#_=_"
"https://www.pinterest.com/connect/facebook/?code=xxx"
"https://www.pinterest.com/?auto_facebook_signup=true"
"https://www.pinterest.com/?auto_facebook_signup=true"

------- GOOGLE ------------
"https://accounts.google.com/o/oauth2/auth?client_id=xxx&redirect_uri=postmessage&response_type=code%20token%20id_token%20gsession&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fplus.login%20email&access_type=offline&after_redirect=keep_open&cookie_policy=single_host_origin&include_granted_scopes=true&proxy=oauth2relay376673711&origin=https%3A%2F%2Fwww.pinterest.com&state=842612657%7C0.1075040606&"
"https://accounts.google.com/ServiceLogin?passive=1209600&continue=https://accounts.google.com/o/oauth2/auth?%26proxy%3Doauth2relay376673711%26access_type%3Doffline%26after_redirect%3Dkeep_open%26scope%3Dhttps://www.googleapis.com/auth/plus.login%2Bemail%26origin%3Dhttps://www.pinterest.com%26response_type%3Dcode%2Btoken%2Bid_token%2Bgsession%26redirect_uri%3Dpostmessage%26state%3D842612657%257C0.1075040606%26client_id%3D694505692171-31closf3bcmlt59aeulg2j81ej68j6hk.apps.googleusercontent.com%26cookie_policy%3Dsingle_host_origin%26include_granted_scopes%3Dtrue%26hl%3Den-GB%26from_login%3D1%26as%3D-3a2b575342705912&ltmpl=popup&oauth=1&sarp=1&scc=1"
"https://accounts.google.com/ServiceLoginAuth"
"https://accounts.google.com/o/oauth2/auth?&proxy=oauth2relay376673711&access_type=offline&after_redirect=keep_open&scope=https://www.googleapis.com/auth/plus.login+email&origin=https://www.pinterest.com&response_type=code+token+id_token+gsession&redirect_uri=postmessage&state=842612657%7C0.1075040606&client_id=xxx&cookie_policy=single_host_origin&include_granted_scopes=true&hl=en-GB&from_login=1&as=-3a2b575342705912"

------- TWITTER -----------
"https://www.pinterest.com/connect/twitter/"
"https://api.twitter.com/oauth/authenticate?oauth_token=xxx"
"https://api.twitter.com/oauth/authorize?oauth_token=xxx"
"https://api.twitter.com/oauth/authorize"
"https://www.pinterest.com/connect/twitter/?oauth_token=xxx&oauth_verifier=xxx"
"https://www.pinterest.com/?auto_facebook_signup=true"

[nraboy]

Out of curiosity, did injecting CSS solve it?

@matheusrocha89 do you think it would be inappropriate to alter the provider screens in the main repository? Maybe I'm worrying too much on it.

[Slessi]

Injecting CSS does hide the buttons successfully but I had to start the inAppBrowser with hidden=true as shown in my snippet, and show it later on loadstop which introduces a slight delay of ~5 seconds? Not a problem for me as my app is set to instantly display a loader overlay until the $cordovaAuth promise resolves so my UX isn't affected.

Injecting it inside loadstart doesn't work as the event fires before the page actually opens up at all so any injected CSS gets removed. Additionally the page would partially load before loadstop fires so this was the best way I found to prevent buttons showing up and disappearing.

I get what you mean with altering the provider's screens but at the same time it seems kind of weird of Pinterest that it even allows your app to try authenticate with Pinterest with Facebook on their OAuth page? You could simply have your own implementation for a direct Facebook OAuth along side it and bypass Pinterest.

Other OAuth services that don't necessarily require an email just give you the alternative functionality to log in with your username instead so I can't understand their reasoning really.

NOTE: I didn't actually include the change in this branch yet as I wasn't sure if you'd approve, but if you do I'll commit it.

[nraboy]

From what you describe, the behavior seems too wild for me to feel comfortable adding this. I must say that you made an incredibly good attempt, so please don't be offended when I say I'm not going to merge it.

I do find it weird that a company would include other providers in their own Oauth flow API. Seems like those other providers should be an option only prior to deciding that they want username and password login.

I encourage you to contribute again in the future :-)