identity api does not give token for newly created email-id
Reported by
chin...@chromotif.com,
May 15 2017
|
||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 Steps to reproduce the problem: Here are the steps to reproduce in existing user: - Remove "Chrome Remote Desktop" Permission from My connected apps https://myaccount.google.com/permissions - Open Chrome identity internal chrome://identity-internals and observe - Now re launch Chrome Remote Desktop App again - You will see that it won't prompt for Google Authorisation - We have to manually remove from chrome://identity-internals - Now if u reopen Chrome Remote Desktop App you will see this error ________________________________ Hi, Testing result on identity sample app WITH newly created email id. After First click on Sign IN button -->>> {"message":"Authorization page could not be loaded."} After second click on Sign in button ->>> Token acquired:ya29.Gl5HBH84kTPY0N7wH4ZRGzc9Cjolxli-yB7FANgI-AsZJd_I1m-F0yGbw5wWjO9HcQ0v0toGN24GI5qY92AONtk5O0GfRLiFS37wyjnF3AuThyFozMkY_D52o1lhsgx5. See chrome://identity-internals for details. version 58.0.3029.110 (64-bit) on win10 This error comes only once per new e-mail id. So CRD apps give this error only one time, whoever uses it first time. This error will not happen if existing user will remove app and permission from managed app. ( use revoke token from identity-internals to re-generate this error.) What is the expected behavior? On one shot, We should get token. :-) What went wrong? app does not get token. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 58.0.3029.110 Channel: stable OS Version: 10.0 Flash Version:
,
May 16 2017
Assigning to Mihai to take a look. Mihai, feel free to re-assign if this isn't actually an issue with signin/the chrome.identity API.
,
May 16 2017
This seems like a very ugly bug for folks that are using the Chrome Identity API. We should probably tackle it before he next release.
,
May 24 2017
,
May 24 2017
I have a CL out. Not sure if this will get landed before branch point though.
,
May 24 2017
,
May 24 2017
We can always merge.
,
May 31 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a8f5066a367be8011a77a7be6a32853d3448ec06 commit a8f5066a367be8011a77a7be6a32853d3448ec06 Author: msarda <msarda@chromium.org> Date: Wed May 31 13:26:32 2017 Avoid treating the load of about:blank as a failure in the web auth flow. As part of the OAUth 2.0 protocol with GAIA, at the end of the web authorization flow, GAIA redirects to a custom scheme URL of type |com.googleusercontent.apps.123:/<extension_id>|, where |com.googleusercontent.apps.123| is the reverse DNS notation of the client ID. It look like this URL is not an web accessible URL from within a Guest WebView, so during the load of this URL, Chrome validates and changes it to "about:blank", which then fails to be loaded within the context of the Identity Scope Approval Dialog extension. Note that in fact, it is better to avoid the load of |about:blank| as the dialog will actually be closed right after this load fails. This CL avoids treating the failure of loading |about:blank| as a failure of the web auth flow. BUG= 722323 Review-Url: https://codereview.chromium.org/2901283002 Cr-Commit-Position: refs/heads/master@{#475894} [modify] https://crrev.com/a8f5066a367be8011a77a7be6a32853d3448ec06/chrome/browser/extensions/api/identity/web_auth_flow.cc
,
May 31 2017
,
Jun 1 2017
Your change meets the bar and is auto-approved for M60. Please go ahead and merge the CL to branch 3112 manually. Please contact milestone owner if you have questions. Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 1 2017
Thanks for the fix. Please confirm whether the fix is verified in canary. If yes, merge to 3112 branch ASAP.
,
Jun 2 2017
Tested on Windows Canary.
,
Jun 2 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/443ffe5729635a7e0e2313278393443c7611af66 commit 443ffe5729635a7e0e2313278393443c7611af66 Author: Mihai Sardarescu <msarda@chromium.org> Date: Fri Jun 02 15:29:11 2017 Avoid treating the load of about:blank as a failure in the web auth flow. As part of the OAUth 2.0 protocol with GAIA, at the end of the web authorization flow, GAIA redirects to a custom scheme URL of type |com.googleusercontent.apps.123:/<extension_id>|, where |com.googleusercontent.apps.123| is the reverse DNS notation of the client ID. It look like this URL is not an web accessible URL from within a Guest WebView, so during the load of this URL, Chrome validates and changes it to "about:blank", which then fails to be loaded within the context of the Identity Scope Approval Dialog extension. Note that in fact, it is better to avoid the load of |about:blank| as the dialog will actually be closed right after this load fails. This CL avoids treating the failure of loading |about:blank| as a failure of the web auth flow. BUG= 722323 Review-Url: https://codereview.chromium.org/2901283002 Cr-Original-Commit-Position: refs/heads/master@{#475894} Review-Url: https://codereview.chromium.org/2919943003 . Cr-Commit-Position: refs/branch-heads/3112@{#116} Cr-Branched-From: b6460e24cf59f429d69de255538d0fc7a425ccf9-refs/heads/master@{#474897} [modify] https://crrev.com/443ffe5729635a7e0e2313278393443c7611af66/chrome/browser/extensions/api/identity/web_auth_flow.cc
,
Jun 6 2017
Tested the issue on windows 7 using chrome M60 #60.0.3112.20 and followed below steps: - Removed "Chrome Remote Desktop" Permission from My connected apps https://myaccount.google.com/permissions - Opened Chrome identity internal chrome://identity-internals and observed - Now re launched Chrome Remote Desktop App again - observed that there is a prompt for Google Authorisation and signed into chrome and chrome remote desktop launched Attached screencast for reference. @Could someone check attached screencast and confirm us if this is the expected result or if we had missed any steps in verifying the issue. Thanks!
,
Jun 6 2017
Correct Test Scenarios To verify this fix, Method 1) Use email Id that has never used "chrome remote desktop" or use newly created email id Method 2) -1 Remove "Chrome Remote Desktop" Permission from My connected apps https://myaccount.google.com/permissions ( if one has installed. -2 Open Chrome identity internal chrome://identity-internals and observe -3 Now re launch Chrome Remote Desktop App again -4 You will see that it won't prompt for Google Authorization -5 We have to manually remove from chrome://identity-internals -6 Now if u reopen Chrome Remote Desktop App you will see this error 5th important step missed. BTW, I tested using 2) method. Please verify using 1st) method, use newly created email id.one
,
Jun 6 2017
Issue 727320 has been merged into this issue. |
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by ligim...@chromium.org
, May 15 2017