Consider allowing session, cache and approval params to be configured

[kmturley]

If you allow these params to be configured, then the user is able to login much faster without forcing login and permission prompts:

ng-cordova-oauth.js
line 164

var redirect_uri = "http://localhost/callback",
    clear_cache = 'no',
    clear_session = 'no',
    approval_prompt = 'auto';
if(options !== undefined) {
    if(options.hasOwnProperty("redirect_uri")) {
        redirect_uri = options.redirect_uri;
    }
    if(options.hasOwnProperty("clear_cache")) {
        clear_cache = options.clear_cache === true ? 'yes' : 'no';
    }
    if(options.hasOwnProperty("clear_session")) {
        clear_session = options.clear_session === true ? 'yes' : 'no';
    }
    if(options.hasOwnProperty("approval_prompt")) {
        approval_prompt = options.approval_prompt === true ? 'force' : 'auto';
    }
}
var browserRef = window.open('https://accounts.google.com/o/oauth2/auth?client_id=' + clientId + '&redirect_uri=' + redirect_uri + '&scope=' + appScope.join(" ") + '&approval_prompt=' + approval_prompt + '&response_type=token', '_blank', 'location=no,clearsessioncache=' + clear_session + ',clearcache=' + clear_cache);

[nraboy]

This will be considered. It was also suggested in PR #94

Thanks,

[veernimbus]

@kmturley I really like the code that you wrote above. i was thinking of modifying the plugin with the same code that you wrote above. Obviously for my personal use. i really need this feature now. What do you say?

[veernimbus]

@nraboy Not to be impolite but i really need @kmturley implementation right now. I hope you update this plugin soon with this feature.

[nraboy]

Well this is an open source project. You can go ahead and fork / add the change yourself if you need it in a hurry.

This is a hobby project for me and I only work on it as time permits.

Best,

[bertramn]

Hi guys, reading this and #94 I am just wondering if you are discussing a non-issue. When you open the inapp browser and navigate to the identity provider the cookies that end up on the device are within the domain of that identity provider. OAuth spec does not perscribe the relying party (your app) to manage identify provider cookies and neither should your browser allow access to these cookies from other domains, thats the whole idea about cookies sandboxing in the browser. So keeping your cache in the inapp browser should be as secure as you doing the same on a desktop browser.

The other discussion about logout is also pretty straight forward, since your app is not holding a user session but merely a granted access token you can choose wether to destroy that token (and possible refresh token) locally in your app. Next time you need such token just go to the identity provider and get a new one. If you want to log out of your identity provider then call their api but just be clear about what that actually does.

A discussion on the very same topic can be found here:

http://stackoverflow.com/questions/12909332/how-to-logout-of-an-application-where-i-used-oauth2-to-login-with-google

Hope this provides a little different angle to the discussion.

[kmturley]

I agree on your comment about logout, they should get logged out of our app not Google, but if they want to switch Google accounts that's a different matter!

The suggestion we made here was to allow us to configure whether the user needs to login every time or not. By having these extra url params we can control whether they log in once, or each time the popup is launched.

A workaround for this would be to store the logged in token and presume the user is logged in, if it fails then create the login popup. But I'd rather not store tokens in my particular instance.