New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Google Sign In - OAuth Consent Screen Shows Once #68882
Comments
flutter doctor -v: [√] Android toolchain - develop for Android devices (Android SDK version 30.0.2) [√] Chrome - develop for the web [√] Android Studio (version 4.0) [√] VS Code (version 1.50.1) [√] Connected device (3 available) • No issues found! Code Snippet: |
@chowdud Can you also post |
Without applying the fix suggested in the following PR: https://github.com/flutter/plugins/pull/2792/files. The serverAuthCode is returned as null. At the moment, I am able to get the serverAuthCode with the scopes for Adwords and this is what I am using to pass to the backend WebAPI to facilitate the linking between user and MCC. |
logs
|
I agree that the serverAuthCode returning as null is also a problem, but for the time being the workaround proposed in that open issue works. The main problem is how the Google Sign In package behaves when a user tries for a second time to grant consent on the adwords scope, where the OAuth screen fails to present itself again. |
I am currently using the Google Sign In package to facilitate Social Sign In and also to request consent with the scope, "https://www.googleapis.com/auth/adwords".
The issue I am having involves the serverauthcode that is generated from the requesting of the above scope. It is known that the package itself has some issue with returning the serverauthcode, and based on a PR floating on this repo, a workaround for it has been suggested but not officially supported yet (to my knowledge). The actual problem is when sending this serverauthcode to the backend WebAPI and trying to establish a link between the Google Ads account and the MCC, there is some unexpected behaviour occurring.
I am not sure as to why this might be the case, but when a user consents and gives access to their account for some app, the serverauthcode and the subsequent credentials generated (access token and refresh token) seem to be valid and manages to establish the link properly. However if the user decides to unlink their account from the MCC and then at a later point try to link again, the OAuth consent screen no longer appears, but the serverauthcode is still generated, but the linking in the backend fails due to the refresh token being set to null in some part of the flow.
In summary, I am not too clear as to why there's a difference between the two serverauthcodes generated (one from the initial consent prompt scenario and another from the no consent prompt scenario) and if there is some sort of setting in the package I am aware of that would resolve this.
The text was updated successfully, but these errors were encountered: