[flutter_appauth] macOS: also resume the authorization flow from the app lifecycle - #672
Open
cristianmgm7 wants to merge 1 commit into
Open
Conversation
…fecycle too `registerWithRegistrar:` installs a kAEGetURL handler so an authorization redirect delivered from outside the app's own browser session can resume the pending flow. That handler never runs in a large class of host apps. `NSAppleEventManager setEventHandler:` replaces any existing handler for that event, and AppKit installs its own during `finishLaunching` — the one that drives `application:openURLs:`. Plugin registration happens earlier, during nib loading, so AppKit's registration wins and the plugin's handler is silently dead in every app whose delegate implements `application:openURLs:`. That is any app with deep links. The symptom is a login that hangs with no error and no cancellation: the redirect reaches the host app, the plugin never sees it, and the pending `OIDExternalUserAgentSession` is never resumed. It shows up with flows whose redirect legitimately comes back through a different browser — an emailed magic link, for example, where the user opens the link from their mail client. Registering the plugin as a `FlutterAppLifecycleDelegate` makes `FlutterAppDelegate` forward `application:openURLs:` to it as well, so the resume happens on whichever path actually delivers the URL. The two paths are safe together: the flow is cleared after the first successful resume, and `handleOpenURLs:` returns YES only when a pending flow accepted the URL, leaving unrelated deep links to the host app. Verified on macOS against a Keycloak realm: without this the flow hangs indefinitely; with it the authorization completes normally. iOS already registers via `addApplicationDelegate:` and is unaffected.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
On macOS the plugin installs a
kAEGetURLApple Event handler so an authorization redirect delivered from outside the app's own browser session can resume the pending flow. In a large class of host apps that handler never runs.NSAppleEventManager setEventHandler:replaces any existing handler for the event. AppKit installs its own duringfinishLaunching— the one that drivesapplication:openURLs:— and plugin registration happens earlier, during nib loading. So AppKit's registration wins andhandleGetURLEvent:is silently dead in any app whose delegate implementsapplication:openURLs:, which is any app with deep links.The symptom is a login that hangs with no error and no cancellation: the redirect reaches the host app, the plugin never sees it, and the pending
OIDExternalUserAgentSessionis never resumed. It shows up with flows whose redirect legitimately returns through a different browser — an emailed magic link, where the user opens the link from their mail client.The change: also register the plugin with
addApplicationDelegate:and implementhandleOpenURLs:, so the resume happens on whichever path actually delivers the URL. The two paths are safe together — the flow is cleared after the first successful resume, andhandleOpenURLs:returnsYESonly when a pending flow accepted the URL, leaving unrelated deep links to the host app. The macOS header declaresFlutterAppLifecycleDelegateconformance, whichaddApplicationDelegate:requires.Verified on macOS against a Keycloak realm: without this the flow hangs indefinitely; with it the authorization completes normally. iOS already registers via
addApplicationDelegate:and is untouched by this change.