Repository navigation
addScopes callback not called when nested #24
Description
Hi, I'm working on updating GoogleSignIn to the latest version and facing a problem regarding the addScopes function.
Since we are now not able to Sign In with the necessary scopes, I am trying to add them as soon as the user is signed in.
It turns out that by chaining both methods, the callback I send to addScopes is never executed.
GIDSignIn.sharedInstance.signIn(with: configuration, presenting: presentingViewController) { user, error in
guard error == nil else {
completion(user, error)
return
}
GIDSignIn.sharedInstance.addScopes(
scopes,
presenting: presentingViewController,
callback: {
// This callback is never executed
print(">>> addScopes callback")
completion($0, $1)
}
)
}
Testing it manually I'm able to see:
- The web view being presented for the regular sign in and being dismissed when it succeeds
- The web view for allowing permissions to be added and dismissed when tapping "Allow"
After these two steps, nothing happens 😔 Am I missing something?
In my opinion the optimal solution would be being able to supply the scopes directly to the signIn method so that both tasks could be done in one step instead of two (like suggested on #23) but I wanted to flag this finding I'm running into as well.
Thanks for the great work!
Reacted by Ivan Smetanin, Vadim Vitvickiy, Oleg Kornienko, Yesbolat, Kundan Jadhav and Marco Milovanovic
Reacted by dmamie
Activity
ivopintodasilva commentedon Jul 14, 2021
The above behavior can be observed in this sample project: https://github.com/ivopintodasilva/GoogleSignIn-AddScopeTest
GoogleSignInis added to the project as a Swift Package and there are instructions in theREADME.mdfile on how to run the project.ismetanin commentedon Jul 15, 2021
Hi! I faced the same issue when migrating to 6.0.0. In my case the web view for allowing permissions dismissing immediately after present
Agree with @ivopintodasilva that setting scopes in
signInwould be way more convenient. For me, it looks strange when we need to show sign-in flow and then right after that ask for scopes in the case when we immediately need to do something with these scopeskundanjadhav commentedon Jul 17, 2021
Hi, I am facing similar issue. Due to this I am not able to update to latest version. Let me know when you get any update regarding this.
AntonKozlovskyi commentedon Jul 19, 2021
Hi! I was facing the same issue.
I've found workaround. I see that an issue is in
function.
self->_currentOptions.callback(self->_currentUser, handlerAuthFlow.error);is waiting while my second block with
addScopesis working, so it callsself->_currentOptions = nil, after saving new completion block.My working solution is to call
addScopesinDispatchQueue.main.async[-]`addScopes` callback is never called[/-]jkichline commentedon Jul 19, 2021
Why are Google products always in beta and we are the guinea pigs? This addScopes method is idiotic. We used to be able to set the scope and sign in. Why is the user now having to be presented with another interface for approval? Why completely change your SDK and not provide deprecation notes to aid in the transition? This seems poorly executed. We need the ability to set the scopes required prior to sign-in as before and which is possible in the "internal options".
Also, it appears that even if I execute the addOptions method after the signIn method, that I am not actually getting those scopes. When attempting to access Google Drive, I get...
Error Domain=com.google.GTLRErrorObjectDomain Code=403 "Insufficient Permission: Request had insufficient authentication scopes." UserInfo={GTLRStructuredError=GTLRErrorObject 0x7fb2614681c0: {code:403 errors:[1] message:"Insufficient Permission: Request had insufficient authentication scopes."}, NSLocalizedDescription=Insufficient Permission: Request had insufficient authentication scopes.}
This is likely because it's not clear that the underlying user isn't changing and you have the return the new user from the secondary call. What a mess.
petea commentedon Jul 19, 2021
@jkichline please refer to #23 for an explanation of the
addScopesAPI surface change you're referring to and feel free to leave any relevant feedback there. The implications of the change you mention are called out in the changelog but not elaborated on in the migration guide, which I'll address. You can refer to the Client-side Access guide for a detailed discussion.