`addScopes` callback not called when nested about googlesignin-ios HOT 6 CLOSED

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 signIn would 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 scopes

from googlesignin-ios.

Hi! I was facing the same issue.
I've found workaround. I see that an issue is in

- (void)addCompletionCallback:(GIDAuthFlow *)authFlow 

function.
self->_currentOptions.callback(self->_currentUser, handlerAuthFlow.error);
is waiting while my second block with addScopes is working, so it calls self->_currentOptions = nil, after saving new completion block.

My working solution is to call addScopes in DispatchQueue.main.async

DispatchQueue.main.async { [weak self] in
                guard let self = self else { return }
                self.engine.addScopes(scopes, presenting: controller, callback: callback)
}

from googlesignin-ios.

The above behavior can be observed in this sample project: https://github.com/ivopintodasilva/GoogleSignIn-AddScopeTest

GoogleSignIn is added to the project as a Swift Package and there are instructions in the README.md file on how to run the project.

from googlesignin-ios.

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.

from googlesignin-ios.

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.

from googlesignin-ios.

@jkichline please refer to #23 for an explanation of the addScopes API 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.

from googlesignin-ios.