GTMAppAuth flow breaks if using Google Chrome

[dsanghan]

Steps to reproduce (Mac):

1. Ensure default browser is Google Chrome
2. Begin auth flow from app
3. Sign-in to reach the consent page in Chrome
4. Click Allow
5. If opening native callback url via Chrome for the first time, an "Open App" dialogue is shown.
6. Wait until auth page navigates away to google.com and click "Open App"
7. Notice callback URL is not called and flow breaks.

Issue does not happen on Firefox/Safari. I figure this is more of a Chromium bug than an GTMAppAuth bug, but there needs to be a more graceful way of handling this on the client end.

[dsanghan]

    BOOL openedBrowser = [[NSWorkspace sharedWorkspace] openURLs:@[URL]
                                         withAppBundleIdentifier:kSafariBundleID
                                                         options:0
                                  additionalEventParamDescriptor:nil
                                               launchIdentifiers:nil];
    if (!openedBrowser) {
        openedBrowser = [[NSWorkspace sharedWorkspace] openURL:URL];
    }

[dsanghan]

Just in case someone else runs into it. Just default it to open with safari instead

[StevenEWright]

@dsanghan Would you be willing to make a pull request?

[StevenEWright]

I feel we should plumb the desired bundle identifier out so that clients can use an explicit value, as in the example here. We should also expose some common browser bundle identifiers as constants for convenience. Default behavior can remain as-is, but clients who want to opt-in to safari-only or X-only can.

I believe this issue is otherwise more generally solved with the built-in callback server in AppAuth?

[grantkemp]

Hi I added a sample project which included MacOs and swift support. I tested it on Chrome and it worked fine. The only thing I can think might be causing above is if the Url is not entered correctly into your Info.plist

#60 has the pull request - feel free to try it if it's still an issue.

[dsanghan]

@grantkemp: I'd also opened an issue on chromium. Might have been fixed at their end. I'll recheck and close if needed. Thanks.

[StevenEWright]

As of Safari 11, Safari exhibits similar behavior (it closes the native prompt instead of ignoring user input like Chrome does).

The previous suggestion remains the best one (use the built-in callback server to avoid the dialogs altogether when using an IdP that supports PKCE, like Google).

Otherwise, this is a browser and IdP issue.