Skip to content

feat(auth): pasar los scopes de AppleSignInConfig al handler de iOS - #18

Closed
rndevelo wants to merge 1 commit into
feature/006-ios-social-signoutfrom
feature/007-apple-scopes-ios
Closed

feat(auth): pasar los scopes de AppleSignInConfig al handler de iOS#18
rndevelo wants to merge 1 commit into
feature/006-ios-social-signoutfrom
feature/007-apple-scopes-ios

Conversation

@rndevelo

Copy link
Copy Markdown
Collaborator

Sale de #17.

Qué

AppleSignInConfig.scopes se respetaba en Android y se ignoraba en iOS: el String? que el seam
tenía reservado para ellos viajaba siempre a null. Ahora se resuelve desde Koin y se reenvía.

Compatibilidad

Aditivo. Un host que hoy ignora el parámetro con _ sigue compilando y funcionando igual.

El fallback cuando no hay configuración es los dos scopes, nunca ninguno: pedir cero scopes
significa que Apple no manda el nombre, y el nombre solo llega una vez en la vida del usuario.

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

AppleSignInConfig.scopes es configuración pública y en Android se lee de verdad
para el flujo OAuth web. En iOS no la leía nadie: el handler recibía un String?
documentado como "reservado para futura config" y siempre valía null, así que los
scopes estaban a fuego en el host. Un campo que funciona en una plataforma y en la
otra no es peor que no tenerlo, porque quien lo cambie creerá que aplica a las dos.

Se llena el hueco que el seam ya tenía reservado, así que es aditivo: un host
integrado hoy lo ignora con "_" y sigue pidiendo lo mismo, que además es el valor
por defecto configurado. Viaja como cadena separada por comas y no como lista
porque una List<String> cruza a Swift como [Any] y obligaría al host a castear.

El fallback es "los dos scopes", nunca "ninguno": pedir cero scopes hace que Apple
no devuelva el nombre, y el nombre solo llega en la primerísima autorización de
cada usuario. Un error de configuración no puede costar eso.

signIn() gana el parámetro con default, así que ninguna llamada existente se
rompe. Sin tests nuevos, y el spec explica por qué: el camino entero vive en el
actual de iOS y en Swift, al otro lado de la frontera de commonTest.

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.
@hgarciaalberto

Copy link
Copy Markdown
Contributor

Integrada en develop vía #21, que agrupó la pila 003→010 en un único squash en vez de encadenar ocho merges con su rebase detrás. El código de esta PR está en develop; se cierra sin mergear porque el commit ya no existe con este SHA.

@hgarciaalberto
hgarciaalberto deleted the feature/007-apple-scopes-ios branch August 19, 2026 22:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants