feat(ios): cablear github, microsoft, twitter, facebook y teléfono en el demo - #15
Closed
rndevelo wants to merge 2 commits into
Closed
feat(ios): cablear github, microsoft, twitter, facebook y teléfono en el demo#15rndevelo wants to merge 2 commits into
rndevelo wants to merge 2 commits into
Conversation
… el demo MainViewController ya habilitaba los cinco providers, así que la pantalla pintaba sus botones, pero en Swift no había ningún handler: cada pulsación registraba un warning, devolvía null y el usuario veía "cancelled or failed". Con Apple ya resuelto, quedaban estos. FirebaseOAuthCoordinator cubre los cuatro que Firebase resuelve por su flujo OAuth web, igual que WebOAuthProviderAndroid en la otra plataforma. Aquí es Swift quien completa el login entero y la librería solo necesita saber que ocurrió: eso es el centinela PLATFORM_AUTH_HANDLED, que se lee de cada objeto en vez de repetir la cadena mágica. Los scopes replican los de LoginLibraryConfig para que ambas plataformas pidan lo mismo. El OAuthProvider se guarda en un diccionario por provider id porque el SDK no lo retiene mientras dura el flujo: en una variable local se libera antes del callback y el navegador abre para no volver nunca. PhoneAuthCoordinator cubre los dos saltos del OTP. La parte que faltaba en ambos y que no está en el código de login: el callback de vuelta. Con el ciclo de vida de SwiftUI, application(_:open:options:) no se llama —las URLs llegan a la escena—, así que el flujo web y el fallback reCAPTCHA del teléfono no volvían nunca. Se añade .onOpenURL sobre el WindowGroup y un AppDelegate.handle(_:) que da prioridad a Auth.auth().canHandle(url) antes que a GoogleSignIn. Se implementan también setAPNSToken y canHandleNotification, que son lo que permite a Firebase verificar la app con un push silencioso en vez de mandar al usuario a una página de reCAPTCHA. Solo cambia el demo y el README: la librería no se toca. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Rkh7MzVRj5iXT2rLiqyW6A
…de iOS Se implementó como fix directo, fuera del harness. El spec se escribe después para que el trabajo quede documentado en specs/ como el resto: alcance, quién firma en cada provider, los tres detalles que deciden si el flujo funciona y una tabla de trazabilidad honesta —ningún AC es unitario, todo el código nuevo es Swift y el repo no tiene target de test de iOS. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Rkh7MzVRj5iXT2rLiqyW6A
hgarciaalberto
pushed a commit
that referenced
this pull request
Aug 19, 2026
…21) Cierra de una vez la pila 003→010, que estaba encadenada PR sobre PR. Sustituye a #14, #15, #16, #17, #18, #19 y #20. - 003 Apple Sign-In de producción en el demo y contrato correcto para Swift - 004 Cablea GitHub, Microsoft, Twitter, Facebook y teléfono en el demo (+ su spec) - 005 Revoca el token de Apple antes de borrar la cuenta - 006 Cierra también la sesión de GoogleSignIn al salir, en iOS - 007 Pasa los scopes de AppleSignInConfig al handler de iOS - 008 Fija el bundle id de iOS y alinea el magic link - 009 Sesión de teléfono completa y testeable en las dos plataformas - 010 Documenta lo que falta para construir el demo y deprecar código muerto Las ocho PRs intermedias apuntaban cada una a la rama de la anterior, y el CI solo disparaba en PRs contra develop/main, así que ninguna había pasado un check. Eso lo arregló #23. Esta pila se validó entera antes de entrar: ambos jobs en verde.
Contributor
|
Integrada en |
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
2 participants
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.
Sale de #14.
Qué
Los cinco providers que quedaban tenían seam en Kotlin y nadie del lado de Swift: el botón
existía y no hacía nada.
FirebaseOAuthCoordinator.swift— GitHub, Microsoft, Twitter y Facebook por el flujo webgenérico de Firebase (
OAuthProvider+getCredentialWith(nil)).PhoneAuthCoordinator.swift— envío de SMS y verificación del OTP.Tres detalles que no son opcionales
OAuthProvider. El SDK no lo retiene; sin el diccionarioinFlightel objetomuere a mitad del flujo y el callback no llega nunca.
AppDelegate,entra por la escena. De ahí el
.onOpenURLdelWindowGroup.setAPNSToken+canHandleNotificationson lo que permite laverificación silenciosa; sin ellos el usuario se come el rodeo por reCAPTCHA.
Los scopes replican los defaults de
LoginLibraryConfig, para que Swift y Kotlin no discrepen.Qué falta
Smoke de los cinco en Mac. El de teléfono necesita además la capability de Push Notifications y
una clave APNs en la consola de Firebase.
Verificado en Windows:
:custom-login:ktlintCheck+:custom-login:testDebugUnitTest(254 tests, 0 fallos). El Swift de esta rama no se ha compilado nunca: pendiente de Mac.🤖 Generated with Claude Code
https://claude.ai/code/session_01E41idMYhfgBSz2EeuNUn5Q