feat(ios): run verification and OAuth through ASWebAuthenticationSession

The captcha/OAuth flow relied on the OS routing the spotiflac://
callback back into the app. In sideload containers (LiveContainer)
the guest app's URL scheme is never registered with iOS, so after
solving the challenge the redirect went nowhere and the user could
not return to the app (LiveContainer#242/#162 — unresolved upstream).

ASWebAuthenticationSession intercepts the callback scheme in-process,
so no OS-level scheme registration is involved: the session sheet
closes itself on completion and the callback URL is fed into the same
deep-link handler the OS path uses. Verification challenges, the help
dialog's open-browser action, and extension OAuth logins all prefer
the session on iOS, falling back to url_launcher if it fails to start.
Safari's cookie store is shared so captcha providers see an
established browsing context.
This commit is contained in:
zarzet
2026-07-10 11:25:55 +07:00
parent b28e8a83a8
commit 196fd0f651
4 changed files with 109 additions and 3 deletions
+17
View File
@@ -547,6 +547,23 @@ class PlatformBridge {
await _channel.invokeMethod('resetDownloadCancel', {'item_id': itemId});
}
/// iOS only: run a verification/OAuth page inside ASWebAuthenticationSession.
/// The session intercepts the callback scheme in-process, so the flow
/// completes even where the app's URL scheme is not registered with the OS
/// (e.g. sideload containers like LiveContainer). Returns true when the
/// session was presented; the callback is delivered through the native side
/// exactly like an OS deep link.
static Future<bool> startIosWebAuthSession(
String url, {
String callbackScheme = 'spotiflac',
}) async {
final result = await _channel.invokeMethod('startWebAuthSession', {
'url': url,
'callback_scheme': callbackScheme,
});
return result == true;
}
static Future<void> setDownloadDirectory(String path) async {
await _channel.invokeMethod('setDownloadDirectory', {'path': path});
}