New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 722323 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: May 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows
Pri: 1
Type: Bug



Sign in to add a comment

identity api does not give token for newly created email-id

Reported by chin...@chromotif.com, May 15 2017

Issue description

UserAgent: 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:
 
Selection_033.png
28.8 KB View Download
Selection_035.png
123 KB View Download
Labels: Needs-Triage-M58

Comment 2 by ew...@chromium.org, May 16 2017

Cc: ew...@chromium.org
Components: -Blink>Internals Services>SignIn
Labels: -Needs-Triage-M58 OS-Linux
Owner: msarda@chromium.org
Status: Assigned (was: Unconfirmed)
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.

Comment 3 by msarda@chromium.org, May 16 2017

Labels: -Pri-2 M-60 Pri-1
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.

Comment 4 by msarda@chromium.org, May 24 2017

Status: Started (was: Assigned)

Comment 5 by msarda@chromium.org, May 24 2017

I have a CL out. Not sure if this will get landed before branch point though.
Labels: -Hotlist-Interop

Comment 7 by ew...@chromium.org, May 24 2017

We can always merge.
Project Member

Comment 8 by bugdroid1@chromium.org, 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

Comment 9 by msarda@chromium.org, May 31 2017

Labels: Merge-Request-60
Status: Fixed (was: Started)
Project Member

Comment 10 by sheriffbot@chromium.org, Jun 1 2017

Labels: -Merge-Request-60 Hotlist-Merge-Approved Merge-Approved-60
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
Thanks for the fix. 

Please confirm whether the fix is verified in canary. If yes, merge to 3112 branch ASAP.
Tested on Windows Canary.
Project Member

Comment 13 by bugdroid1@chromium.org, Jun 2 2017

Labels: -merge-approved-60 merge-merged-3112
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

Cc: hdodda@chromium.org
Labels: Needs-Feedback
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!
722323.mp4
5.9 MB View Download
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
Cc: msarda@chromium.org rdevlin....@chromium.org mmanchala@chromium.org
 Issue 727320  has been merged into this issue.

Sign in to add a comment