Claude Code + connexion
Deux choses cassent les connexions dans les web apps encapsulées : Google bloque sa page de connexion dans les WebViews intégrées, et Apple refuse les apps qui proposent la connexion Google sans option équivalente respectueuse de la vie privée. WebViewGold règle le premier problème avec son Social Login Helper et gère automatiquement les pages Sign in with Apple sur iOS ; Claude Code s'occupe du côté web. Voici la configuration qui passe la validation et garde les utilisateurs connectés.
Dès $109 en paiement unique par plateforme, ou notre équipe s'occupe de tout dès $698.
Google. Google refuse OAuth dans les WebViews intégrées et affiche « Error 403: disallowed_useragent ». Le reviewer touche Continuer avec Google, voit l'erreur, et vous recevez un refus pour la guideline 2.1 à cause d'une connexion cassée. Le Social Login Helper de WebViewGold corrige cela : vous listez les préfixes d'URL qui apparaissent pendant votre flux de connexion (google_login_helper_triggers dans Config.swift, GOOGLE_LOGIN_HELPER_TRIGGERS dans Config.java) et, quand l'un d'eux se charge, l'app ouvre la connexion dans une fenêtre dédiée avec un user agent que Google accepte, puis revient à votre web app. Le même mécanisme existe pour Facebook. Détails : documentation du Social Login Helper et le correctif disallowed_useragent.
Apple. La guideline 4.8 précise qu'une app qui utilise une connexion tierce ou sociale pour le compte principal doit aussi proposer un service de connexion équivalent qui limite la collecte de données au nom et à l'adresse e-mail, permet aux utilisateurs de garder leur e-mail privé et ne les suit pas à des fins publicitaires sans leur consentement. Sign in with Apple remplit ces trois conditions, et c'est ce que les reviewers attendent. Sur iOS, WebViewGold détecte appleid.apple.com et gère ce flux automatiquement, sans aucune configuration. Si votre app ne propose que l'e-mail et le mot de passe, la 4.8 ne s'applique pas.
Android. La règle d'Apple ne s'applique pas à Google Play, et la documentation WebViewGold ne décrit aucun traitement particulier des pages Apple sur Android. Testez le flux web dans votre build Android ; s'il n'aboutit pas, masquer le bouton Apple sur cette plateforme est acceptable.
| Domaine | Claude Code | Vous |
|---|---|---|
| Web app | Fournisseur Apple, boutons équivalents, route de callback, gestion du nom à la première connexion, fournisseurs enregistrés sur le profil, règle dans CLAUDE.md | Relire le plan et le diff, déployer |
| Apple Developer portal et dashboard d'authentification | Rédige SETUP-APPLE-LOGIN.md avec chaque champ | Services ID, clé, URL de retour, réglages du fournisseur, relais e-mail, renouvellement du secret tous les six mois |
| WebViewGold | Liste les préfixes d'URL par lesquels passe le flux de connexion ; ne modifie les valeurs de Config que si les projets sont dans le dépôt | Confirmer les listes de déclencheurs, compiler |
| Tests | Vérifie le flux web dans un navigateur desktop | Tests sur appareil via TestFlight et le test interne, Masquer mon adresse e-mail, le compte du reviewer |
| Besoin | iOS (Config.swift) | Android (Config.java) |
|---|---|---|
| Connexion Google dans l'app | google_login_helper_triggers, par exemple accounts.google.com et accounts.youtube.com | GOOGLE_LOGIN_HELPER_TRIGGERS |
| Connexion Facebook | facebook_login_helper_triggers | FACEBOOK_LOGIN_HELPER_TRIGGERS |
| Sign in with Apple | Détecté automatiquement (appleid.apple.com) | Non documenté ; testez le flux web |
| Confier une URL de connexion au système | googlelogin:// + URL encodée l'ouvre en externe (la session vit alors dans Safari, pas dans l'app) | googlelogin:// + URL encodée ouvre un Chrome Custom Tab (documentation sur la gestion des URL) |
| Détecter l'app dans votre code | useragent_iphone, useragent_ipad plus le jeton WebViewGoldApp | USER_AGENT plus le jeton WebViewGoldApp |
| Conserver les sessions | Laissez deletecache sur false | Laissez CLEAR_CACHE_ON_STARTUP sur false ; MANUAL_COOKIE_SYNC si les cookies arrivent en retard ; HOME_URL_LOGOUT pour une URL de déconnexion |
Excellent travail! Je n'ai jamais codé quoi que ce soit, mais j'ai réussi à travailler avec cela. Facile et rapide! Avec une grande aide des créateurs!
L'essentiel du temps passe dans l'Apple Developer portal ; le code, lui, va vite.
Activez Sign in with Apple sur votre App ID. Pour le flux web, créez un Services ID (son identifiant devient le client ID OAuth), ajoutez votre domaine et l'URL de retour de votre fournisseur d'authentification (pour Supabase : https://YOUR-PROJECT.supabase.co/auth/v1/callback), puis créez une clé Sign in with Apple (.p8). Notez le Team ID et le Key ID.
Activez le fournisseur Apple avec le Services ID et la clé. Le client secret d'Apple est un JWT signé valable six mois au maximum : notez un rappel de renouvellement dans votre agenda. Ajoutez votre domaine de production aux URL de redirection autorisées ; retirez les entrées de preview et localhost du projet de production.
Les utilisateurs peuvent choisir Masquer mon adresse e-mail. Pour que les réinitialisations de mot de passe et les reçus arrivent aux adresses privaterelay.appleid.com, enregistrez votre domaine ou votre adresse d'envoi sous Sign in with Apple for Email Communication dans l'Apple Developer portal.
Il ajoute le bouton, la gestion du callback et une checklist de configuration, et liste les préfixes d'URL par lesquels passe votre flux de connexion, pour que vous puissiez vérifier les listes de déclencheurs.
Placez les préfixes Google dans google_login_helper_triggers et GOOGLE_LOGIN_HELPER_TRIGGERS. Si votre fournisseur d'authentification utilise un domaine personnalisé qui redirige vers Google, ce sont toujours les domaines Google qu'il faut lister.
TestFlight et test interne, avec la checklist ci-dessous. Pour un coup de main côté natif, l'équipe Full Service configure et compile les apps pour vous.
Si vous avez connecté votre fournisseur d'authentification ou votre base de données via un serveur MCP, Claude Code peut lire lui-même les réglages actuels du fournisseur ; sinon, il les inscrit pour vous dans la checklist.
Notre web app tourne dans les navigateurs et dans des apps natives iOS et Android construites avec WebViewGold (le user agent contient WebViewGoldApp). Nous proposons la connexion Google : la guideline Apple 4.8 exige donc une connexion équivalente respectueuse de la vie privée dans l'app iOS ; nous allons ajouter Sign in with Apple. Le wrapper natif gère déjà le côté WebView : les pages de connexion Google sont ouvertes par le Social Login Helper de WebViewGold (préfixes d'URL déclencheurs dans Config.swift et Config.java), et sur iOS, appleid.apple.com est détecté et géré automatiquement. N'ajoutez ni code natif ni schéma d'URL pour la connexion. Commencez par un plan, puis implémentez après mon approbation : 1. Détectez notre bibliothèque d'authentification (Supabase Auth, Firebase Auth, Auth.js ou Clerk) et ajoutez son fournisseur Apple pour le flux web avec notre URL de callback de production. Aucune redirection vers une preview ou localhost. 2. Écrans de connexion et d'inscription : Sign in with Apple et Continuer avec Google comme options équivalentes, avec la même taille et la même position. Stylisez le bouton Apple selon les directives d'Apple (noir ou blanc, avec le libellé Sign in with Apple, ou Se connecter avec Apple si l'interface est en français). La connexion par e-mail et mot de passe reste, car le compte de démo pour l'App Review l'utilise. 3. Apple ne transmet le nom de l'utilisateur qu'à la première autorisation. Si notre bibliothèque d'authentification ne l'enregistre pas, demandez un nom d'affichage pendant l'onboarding lorsqu'il manque. 4. Les utilisateurs peuvent choisir Masquer mon adresse e-mail. Vérifiez que les e-mails transactionnels fonctionnent pour les adresses privaterelay.appleid.com. 5. Enregistrez sur le profil les fournisseurs avec lesquels un utilisateur s'est connecté, pour que la suppression de compte puisse révoquer plus tard les jetons Apple. Si la bibliothèque d'authentification expose le refresh token Apple à la connexion, stockez-le côté serveur, chiffré. 6. Listez chaque préfixe d'URL par lequel passent les flux Google et Apple, sur notre domaine et sur les domaines des fournisseurs (utilisez le serveur MCP Playwright s'il est connecté, sinon la documentation de la bibliothèque d'authentification), pour que je puisse les comparer avec google_login_helper_triggers et GOOGLE_LOGIN_HELPER_TRIGGERS. 7. Rédigez SETUP-APPLE-LOGIN.md : les étapes Apple Developer (App ID avec Sign in with Apple, Services ID avec domaine et URL de retour, clé), les champs de notre dashboard d'authentification, la liste des URL de redirection autorisées, l'enregistrement du relais e-mail et une note précisant que le client secret Apple expire au bout de six mois au maximum. 8. Ajoutez une règle à CLAUDE.md : Sign in with Apple reste aussi visible que toutes les autres connexions tierces et ne doit pas être supprimé lors des refactorings. Indiquez les fichiers modifiés et les questions en suspens.
Un exemple Supabase dans un composant client Next.js. L'essentiel : le traitement équivalent des deux fournisseurs et une seule redirection de production ; l'agent l'adapte à votre bibliothèque d'authentification.
// components/social-login.tsx
"use client";
import { createClient } from "@/lib/supabase/client";
// Callback de production uniquement ; doit figurer dans la liste des URL de redirection autorisées de Supabase
const REDIRECT_TO = "https://app.example.com/auth/callback";
export function SocialLogin() {
const supabase = createClient();
const signIn = (provider: "apple" | "google") =>
supabase.auth.signInWithOAuth({ provider, options: { redirectTo: REDIRECT_TO } });
return (
<div className="flex flex-col gap-3">
{/* Même hauteur, largeur et position pour les deux : la guideline 4.8 veut dire équivalent, pas caché */}
<button
type="button"
onClick={() => signIn("apple")}
className="h-12 w-full rounded-lg bg-black text-white font-medium"
>
Sign in with Apple
</button>
<button
type="button"
onClick={() => signIn("google")}
className="h-12 w-full rounded-lg border border-gray-300 bg-white text-gray-900 font-medium"
>
Continue with Google
</button>
</div>
);
}
// app/auth/callback/route.ts échange le code contre une session (supabase.auth.exchangeCodeForSession)
// et redirige vers la page d'où venait l'utilisateur. Dans l'app, la fenêtre de connexion WebViewGold
// revient à cette URL : la session arrive donc dans l'app, pas dans Safari ni dans Chrome.deletecache et les réglages des cookies avant de toucher à votre code.Non. La guideline 4.8 s'applique quand une connexion tierce ou sociale sert à créer ou à authentifier le compte principal. L'e-mail et le mot de passe seuls ne la déclenchent pas.
La formulation d'Apple autorise tout service de connexion qui offre les garanties de confidentialité énumérées. En pratique, Sign in with Apple est l'option que les reviewers reconnaissent immédiatement, et la plus simple à défendre.
Google détecte les WebViews intégrées et les bloque avec disallowed_useragent. Le Social Login Helper ouvre ces pages dans un contexte que Google accepte, puis revient à votre app.
C'est facultatif. L'afficher partout reste cohérent pour les utilisateurs qui changent d'appareil ; masquez-le sur Android uniquement si le flux web n'aboutit pas dans votre build de test.
Non. Il rédige la checklist et le code, et peut modifier les valeurs de Config.swift et Config.java si les projets sont dans le dépôt. Les réglages du portail, les clés et la signature restent entre vos mains.
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.
$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.
Voir les offres sur la page principale$349 par licence, extension en paiement unique
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.
Comment fonctionne le Cloud Builder Essayer la démo gratuite$698 par plateforme $798
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.
Détails du Full Service Propulsé par
Prix Soldes d'hiver valables jusqu'au 31 décembre 2026.
Garantie d'approbation App Store & Google Play – ou remboursement sous 14 jours
Vous préférez déléguer ? Full Service : nous configurons, compilons et livrons sous 72 heures, dès $698 par plateforme. Des questions ? Chattez avec nous 24/7.
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.