chrome.identity.launchWebAuthFlow caching user information in Chrome

[Adish]

I am using chrome.identity.launchWebAuthFlow to get OAuth2.0 token for a user's Google account. I know the recommended way is to use chrome.identity.getAuthToken for Google accounts but I do not want to force the user to sign into Chrome browser. When the user first opens the browser and sign in to my extension, user is presented with the "Sign In" screen and then the "Authorization" screen. Now, if I revoke the token and user clicks sign in again, user is not presented with the "Sign In" screen but directly the "Authorization" screen. Chrome is caching the signed in user, how do I get the user truly signed out? Closing the browser and re-opening it signs the user out completely.

[Liam Lin]

Hi Adish,

I have the same problem, and I find the cause of this issue, in my case, is that the web view of the "Identity API Scope Approval UI" itself would store the signed-in cookie, separately from the chrome browser and your extension, I think.

You can try to see that with developers tool (by right-clicking on the page -> Inspect Element) when you're in your "authorization" screen. If you clear that cookie and try again then everything might just work fine. 

My problem, however, is that I have no idea how to programmatically clear those cookies in that approval UI orz....

[Cyrus Adkisson]

I've got the exact same problem. The only way I found to handle it (which you may have found from my previous posts) is to ask the user to log out, then restart browser which is just horrible UX.

After letting a few users test my new extension, I also found out a new "problem" with chrome.identity.launchWebAuthFlow()... the overlays look really scary and suspicious to users. There is no URL bar with a comforting green-colored "https:" google or facebook url. I had several users balk at logging in because of this.

Note to Googlers/moderators: Can you identify the person or persons who is responsible for chrome.identity? It's very promising and I (maybe we) would like to start a more active dialog with them re: these concerns.

Cyrus

[Adish]

I agree that the Authentication/Authorization screen shown by the chrome.identity.launchWebAuthFlow is scary and will put users off. I have moved on to use the JavaScript client library gapi.auth.authorize() to sign in the user and then communicate the login status back to the extension via the content script.

Adish

[Olga Khylkouskaya]

Hello, I also have the same problem. Any updates for that?

On Thursday, July 17, 2014 6:49:08 PM UTC-7, Adish wrote:

[Rafael Hovsepyan]

There is no way to control webview tag's storage or cookies of "auth flow", but you can add prompt=select_account param to your authorization url, and after users can switch between their accounts.

пятница, 18 июля 2014 г., 5:49:08 UTC+4 пользователь Adish написал: