Connexion Google et Sign in with Apple dans une app WebView : le workflow Codex pour Firebase Auth
Deux choses cassent la connexion dans une app web encapsulée : Google refuse l'OAuth dans les WebViews intégrées, et Apple refuse les apps qui proposent Google sans équivalent respectueux de la vie privée. WebViewGold règle le premier point en natif et détecte automatiquement Sign in with Apple sur iOS ; Codex adapte le côté web en conséquence. Ce guide utilise Firebase Auth sur une app hébergée avec Express, la stack où les détails de redirection comptent le plus.
Dès $109 en paiement unique par plateforme, ou notre équipe s'occupe de tout dès $698.
Garantie d'approbation – ou remboursement sous 14 jours
Aucun codage requis
Paiement unique, mises à jour gratuites
Support humain 24/7
Conçu en Allemagne depuis 2014 · ISO 27001
9:41
Votre app
Votre appDésormais dans votre poche
App Store · Google Play Approuvée
L'objectif, et le test de dix secondes de l'examinateur
L'objectif : trois options de connexion qui fonctionnent dans les apps iOS et Android exactement comme sur le web (e-mail, Google et Sign in with Apple), qui aboutissent toutes à la même session Firebase dans la WebView et qui sont toujours là après avoir fermé et rouvert l'app.
Le test de l'examinateur est rapide. Il touche Google ; si Google répond « Error 403: disallowed_useragent », l'app est cassée (guideline 2.1). Il cherche une option Apple à côté de Google ; si elle manque, la guideline 4.8 exige une option de connexion qui limite les données au nom et à l'e-mail et permet de masquer son adresse, ce qui revient en pratique à Sign in with Apple. Les apps qui n'utilisent que leurs propres comptes par e-mail ou par lien magique en sont exemptées, ce qui constitue une échappatoire légitime (la guideline 4.8 en détail).
Google bloque l'OAuth dans les WebViews intégrées. Quand une URL de google_login_helper_triggers (Config.swift) se charge, WebViewGold ouvre la connexion dans une fenêtre dédiée avec un user agent que Google accepte, puis revient à votre app ; Android dispose de la même liste sous le nom GOOGLE_LOGIN_HELPER_TRIGGERS dans Config.java, ainsi que de listes pour Facebook. Sign in with Apple (appleid.apple.com) est géré automatiquement sur iOS. Voir la documentation de la connexion sociale.
Votre app web : la redirection sur votre propre domaine
Safari et les autres vues WebKit bloquent le stockage tiers, ce qui casse la connexion Firebase par redirection tant que authDomain pointe encore vers PROJECT.firebaseapp.com. Les bonnes pratiques de Firebase pour la redirection proposent plusieurs solutions ; pour une app sur Express, la plus propre est un reverse proxy pour /__/auth/ sur votre domaine, avec authDomain défini sur ce domaine.
Apple Developer : Services ID et clé
Un Services ID avec votre domaine et l'URL de retour https://app.example.com/__/auth/handler (votre domaine, à cause du proxy), une clé Sign in with Apple et votre Team ID, le tout saisi dans le fournisseur Apple de Firebase.
Android : Apple est facultatif
Google Play n'impose aucune règle sur Sign in with Apple. N'affichez le bouton sur Android que si vos utilisateurs s'y attendent, et testez cette redirection sur un appareil ; la gestion automatique d'Apple par WebViewGold est documentée pour iOS.
La section d'authentification pour AGENTS.md
Ajoutez ceci sous le contexte d'exécution de votre AGENTS.md. Cela bloque les trois réflexes des agents quand la connexion échoue dans une WebView : changer le user agent, ouvrir l'OAuth dans une nouvelle fenêtre ou retirer discrètement Google du build iOS.
markdown
## Authentication (Firebase Auth inside WebViewGold)
- Providers: email/password, Google, Apple. Google and Apple buttons live in one
component (src/components/SocialButtons.tsx) with equal size and prominence.
- Every sign-in call goes through src/lib/auth.ts. Inside the native app
(isNativeApp()) use signInWithRedirect, which Firebase recommends on mobile;
keep the method in one constant so we can switch to popup after device tests.
Desktop browsers may use signInWithPopup.
- authDomain is our own domain (app.example.com). Express proxies /__/auth/* to
PROJECT_ID.firebaseapp.com as a transparent reverse proxy. Never point
authDomain back to firebaseapp.com.
- Google inside the app works through WebViewGold's Social Login Helper
(google_login_helper_triggers / GOOGLE_LOGIN_HELPER_TRIGGERS). Do not change the
user agent, do not open OAuth URLs with window.open, do not use googlelogin://
unless explicitly asked.
- Sign in with Apple (appleid.apple.com) is handled by WebViewGold on iOS.
- Apple shares the name only on the first sign-in: write displayName to users/{uid}
immediately. Expect @privaterelay.appleid.com addresses.
- auth/account-exists-with-different-credential: ask the user to sign in with the
existing method, then linkWithCredential. Never create a second account silently.
Exécutez-le dans le dépôt de l'app web avec codex --sandbox workspace-write --ask-for-approval on-request. Il ne modifie que le code ; tout ce que vous devez configurer dans les consoles Apple et Firebase atterrit dans un fichier de configuration à votre intention.
À coller dans Codex (CLI ou extension IDE)
Lisez AGENTS.md, en particulier la section Authentication. Notre app utilise Firebase Auth avec e-mail/mot de passe et Google. Apple a refusé le build iOS au titre de la guideline 4.8, et la connexion Google échoue dans l'app sur certains appareils avec disallowed_useragent. Corrigez le côté web ; je m'occupe des consoles Apple Developer et Firebase ainsi que de la configuration WebViewGold.
1. Ajoutez Sign in with Apple avec new OAuthProvider("apple.com") et les scopes email et name, en passant par src/lib/auth.ts. Le bouton respecte les règles de design d'Apple (noir ou blanc, logo Apple, « Sign in with Apple ») et a la même taille et la même visibilité que le bouton Google.
2. Dans l'app native (isNativeApp()), utilisez signInWithRedirect et traitez getRedirectResult au démarrage de l'app, y compris les erreurs, avec un message visible au lieu d'un échec silencieux. Conservez le flux par popup pour les navigateurs de bureau. Placez le choix de la méthode dans une seule constante.
3. Faites de notre propre domaine l'authDomain : ajoutez un reverse proxy Express qui transmet /__/auth/ à https://PROJECT_ID.firebaseapp.com (un proxy transparent, pas une redirection ; conservez les chemins, les query strings et les cookies). Lisez PROJECT_ID et le domaine d'authentification dans des variables d'environnement.
4. À la première connexion avec Apple, écrivez displayName et email dans users/{uid} s'ils sont vides.
5. Gérez auth/account-exists-with-different-credential avec un flux d'association : expliquez quelle méthode le compte utilise, connectez l'utilisateur avec celle-ci, puis appelez linkWithCredential.
6. Rédigez SETUP-AUTH.md avec ce que je dois configurer : le Services ID Apple avec le domaine app.example.com et l'URL de retour https://app.example.com/__/auth/handler, la clé et le Team ID pour Firebase, les domaines autorisés dans Firebase et les réglages WebViewGold à vérifier (google_login_helper_triggers dans Config.swift, GOOGLE_LOGIN_HELPER_TRIGGERS dans Config.java, deletecache désactivé).
7. Tests : des tests unitaires pour le flux d'association, la gestion des erreurs de redirection et la route du proxy avec un upstream mocké. N'appelez ni Google ni Apple.
Indiquez les fichiers modifiés et une matrice de tests sur appareil pour iOS et Android.
Le côté WebViewGold
Voici les valeurs par défaut documentées. N'étendez les listes que si votre connexion passe par d'autres hôtes Google ou Facebook (lancez la connexion dans un navigateur de bureau et observez les redirections). Sur Android, les mêmes préfixes vont dans GOOGLE_LOGIN_HELPER_TRIGGERS et FACEBOOK_LOGIN_HELPER_TRIGGERS dans Config.java.
swift
// Config.swift: Social Login Helper triggers (documented defaults)
var google_login_helper_triggers: [String] = ["https://accounts.google.com", "https://accounts.youtube.com"]
var facebook_login_helper_triggers: [String] = ["https://m.facebook.com", "https://www.facebook.com"]
// Sign in with Apple (appleid.apple.com) needs no trigger: WebViewGold handles it on iOS.
// Keep sessions across launches: leave deletecache and deletecacheonexit off,
// or users are logged out every time they open the app.
// Custom user agent (useragent_iphone / useragent_ipad): append your marker to the
// default string instead of replacing it.
L'ordre des tâches
Compte Apple Developer
Activez Sign in with Apple sur l'App ID, créez un Services ID, enregistrez app.example.com et l'URL de retour https://app.example.com/__/auth/handler, créez une clé Sign in with Apple, et notez le Key ID et le Team ID.
Console Firebase
Activez le fournisseur Apple (Services ID, Team ID, Key ID, clé privée) et Google. Ajoutez app.example.com aux domaines autorisés.
Lancez la tâche Codex et relisez-la
Collez le prompt, puis lancez /review dans la CLI et lisez le git diff. Vérifiez d'abord le proxy : il doit transmettre et non rediriger, et il ne doit toucher à aucune autre route.
Déployez et vérifiez le handler
Ouvrez https://app.example.com/__/auth/handler dans un navigateur. La page doit être servie depuis votre domaine, au lieu de renvoyer une 404 ou de rebondir vers firebaseapp.com.
Configuration native
Vérifiez les listes de triggers, laissez deletecache désactivé sur iOS et CLEAR_CACHE_ON_STARTUP désactivé sur Android, et si vous définissez un user agent personnalisé, ajoutez votre marqueur à la chaîne par défaut. Sur Android, HOME_URL_LOGOUT peut pointer vers votre URL de déconnexion pour effacer les cookies de connexion.
Matrice de tests sur appareil, puis soumission
Déroulez la matrice ci-dessous sur TestFlight et sur une piste de test interne. Dans les notes pour l'examen, listez les options de connexion et fournissez à l'examinateur un compte de démo par e-mail (le workflow de publication avec Codex couvre le reste de la soumission).
Matrice de tests sur appareil
iOS, nouvel utilisateur Apple : le nom est enregistré, une adresse de relais privé est acceptée, l'utilisateur arrive connecté.
iOS, utilisateur Apple existant : même compte, pas de doublon.
iOS et Android, Google : pas de disallowed_useragent, le flux revient à l'app avec l'utilisateur connecté.
L'e-mail et le mot de passe fonctionnent toujours, et le compte de démo de l'examinateur fonctionne du premier coup.
Un compte existant avec un autre fournisseur déclenche le flux d'association, pas un second compte.
Fermez et rouvrez l'app : l'utilisateur est toujours connecté.
Déconnectez-vous, puis reconnectez-vous avec Google : le sélecteur de compte apparaît, au lieu d'une connexion silencieuse au compte précédent.
Pièges
authDomain laissé sur firebaseapp.com. La redirection aboutit, mais l'app revient souvent à l'écran de connexion sans utilisateur.
Une URL de retour dans le Services ID qui ne correspond pas exactement : http au lieu de https, une barre oblique finale, ou l'hôte firebaseapp.com alors que vous êtes passé à votre propre domaine.
Un bouton Apple plus petit que le bouton Google ou caché en dessous. Les règles de design d'Apple exigent une visibilité égale, et les examinateurs comparent.
Des adresses de relais privé qui ne reçoivent jamais vos e-mails. Enregistrez votre domaine d'envoi sous Sign in with Apple for Email Communication dans votre compte Apple Developer.
Codex qui propose de remplacer le user agent de l'app par une chaîne Chrome de bureau. Cela casse les mises en page mobiles et n'est pas nécessaire ; le Social Login Helper est la voie prise en charge.
googlelogin:// par défaut. Il confie la connexion au navigateur système sur iOS et à un Chrome Custom Tab sur Android : la session vit donc en dehors de votre WebView, sauf si votre redirection la ramène. Réservez-le aux cas particuliers (documentation Android sur la gestion des URL).
Questions fréquentes
WebViewGold doit-il être configuré pour Sign in with Apple ?
Pas sur iOS : le flux appleid.apple.com est détecté et géré automatiquement. Vous configurez Apple dans votre compte Apple Developer et dans Firebase, et vous ajoutez le bouton à votre app web.
Ai-je besoin de Sign in with Apple sur Android ?
Non. Google Play n'impose pas une telle règle. Beaucoup d'apps l'affichent sur les deux plateformes par souci de cohérence ; si vous le faites, testez le flux sur un appareil Android avant la publication.
Popup ou redirection dans l'app ?
Commencez par la redirection sur votre propre authDomain, que Firebase recommande pour le mobile. Gardez le choix dans une seule constante pour pouvoir passer au popup si un test sur appareil révèle un problème, et retestez les deux plateformes après chaque modification.
Codex peut-il tester lui-même le flux OAuth ?
Non. L'OAuth nécessite de vrais comptes chez les fournisseurs, et le sandbox de Codex n'a pas d'accès réseau par défaut. Codex peut tester la logique d'association, les messages d'erreur et la route du proxy avec des mocks ; les vraies connexions ont leur place dans votre matrice de tests sur appareil.
Qu'est-ce qui change si j'utilise Supabase au lieu de Firebase ?
Le côté WebViewGold est identique. Dans Supabase, vous activez le fournisseur Apple avec le Services ID et un client secret généré à partir de votre clé (Apple en limite la validité à six mois : prévoyez la rotation), et l'URL de callback est le callback d'authentification de votre projet Supabase. Il n'y a pas de proxy authDomain à construire.
Trois façons de mettre votre app dans les stores
Même résultat, charge de travail différente de votre côté. Les trois formules incluent la garantie d'approbation et le support humain 24/7.
Faites-le vous-même
$109 par plateforme, paiement unique
La licence WebViewGold : un projet Xcode ou Android Studio prêt à l'emploi. Collez votre URL, définissez le nom et l'icône, activez les fonctionnalités, compilez et soumettez. Mises à jour gratuites à vie.
Ni Mac, ni Xcode, ni Android Studio : configurez dans le navigateur, nous compilons les deux apps dans le cloud et les transmettons à App Store Connect et à la Play Console.
Envoyez-nous votre URL et votre icône. Notre équipe configure, compile et livre votre app sous 72 heures, en marque blanche, projets sources inclus. Les deux plateformes pour $1,158.
Les remboursements sont accordés aux conditions indiquées dans notre FAQ : un refus non lié au contenu par Apple et/ou Google, demandé dans les 14 jours suivant l'achat.
