ChatGPT & Codex
Zwei Dinge machen den Login in einer gewrappten Web-App kaputt: Google verweigert OAuth in eingebetteten WebViews, und Apple lehnt Apps ab, die Google ohne eine datenschutzfreundliche Alternative anbieten. WebViewGold löst das Erste nativ und erkennt Sign in with Apple auf iOS automatisch; Codex passt die Web-Seite daran an. Dieser Guide nutzt Firebase Auth in einer App auf Express, dem Stack, bei dem die Redirect-Details am meisten zählen.
Ab $109 einmalig pro Plattform, oder unser Team erledigt alles ab $698.
Das Ziel sind drei Login-Optionen, die in den iOS- und Android-Apps genau so funktionieren wie im Web: E-Mail, Google und Sign in with Apple. Alle enden in derselben Firebase-Session in der WebView, und die ist auch dann noch da, wenn die App geschlossen und wieder geöffnet wurde.
Der Test des Reviewers ist kurz. Er tippt auf Google; antwortet Google mit "Error 403: disallowed_useragent", ist die App kaputt (Richtlinie 2.1). Dann sucht er neben Google nach einer Apple-Option. Fehlt sie, verlangt Richtlinie 4.8 eine Login-Option, die die Daten auf Name und E-Mail beschränkt und es erlaubt, die eigene Adresse zu verbergen, was in der Praxis Sign in with Apple bedeutet. Apps, die nur eigene E-Mail- oder Magic-Link-Konten nutzen, sind ausgenommen, und das ist ein legitimer Ausweg (Richtlinie 4.8 im Detail).
Hintergründe zum Google-Fehler findest du im Fix für disallowed_useragent, und alle Login-Optionen sind im Hub zu Google-Login und Sign in with Apple gesammelt.
Google blockiert OAuth in eingebetteten WebViews. Lädt eine URL aus google_login_helper_triggers (Config.swift), öffnet WebViewGold den Login in einem eigenen Fenster mit einem User Agent, den Google akzeptiert, und kehrt danach in deine App zurück; Android hat dieselbe Liste als GOOGLE_LOGIN_HELPER_TRIGGERS in Config.java, dazu Listen für Facebook. Sign in with Apple (appleid.apple.com) wird auf iOS automatisch übernommen. Siehe die Social-Login-Docs.
Safari und andere WebKit-Views blockieren Drittanbieter-Speicher. Das bricht den Redirect-Login von Firebase, solange authDomain noch auf PROJECT.firebaseapp.com zeigt. Die Best Practices von Firebase für Redirects nennen mehrere Lösungen; für eine App auf Express ist die saubere ein Reverse Proxy für /__/auth/ auf deiner Domain und authDomain auf genau diese Domain gesetzt.
Eine Services ID mit deiner Domain und der Return-URL https://app.example.com/__/auth/handler (deine Domain, wegen des Proxys), ein Sign-in-with-Apple-Key und deine Team ID, alles im Apple-Provider von Firebase eingetragen.
Google Play hat keine Regel zu Sign in with Apple. Zeig den Button auf Android nur, wenn deine Nutzer ihn erwarten, und teste diesen Redirect auf einem Gerät; die automatische Apple-Behandlung von WebViewGold ist für iOS dokumentiert.
Füge das unter dem Laufzeitkontext in deiner AGENTS.md ein. Es blockiert die drei Dinge, die Agenten gern tun, wenn der Login in einer WebView scheitert: den User Agent ändern, OAuth in einem neuen Fenster öffnen oder Google still und leise aus dem iOS-Build entfernen.
## 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.
Mein iOS WebView wurde endlich genehmigt. Danke!!
Führe ihn im Repository der Web-App mit codex --sandbox workspace-write --ask-for-approval on-request aus. Er ändert nur Code; alles, was du in den Konsolen von Apple und Firebase anklicken musst, landet für dich in einer Setup-Datei.
Lies AGENTS.md, besonders den Abschnitt Authentication. Unsere App nutzt Firebase Auth mit E-Mail/Passwort und Google. Apple hat den iOS-Build nach Richtlinie 4.8 abgelehnt, und der Google-Login scheitert in der App auf manchen Geräten mit disallowed_useragent. Behebe die Web-Seite; um die Konsolen von Apple Developer und Firebase und um die WebViewGold-Config kümmere ich mich.
1. Füge Sign in with Apple mit new OAuthProvider("apple.com") und den Scopes email und name hinzu, geleitet über src/lib/auth.ts. Der Button folgt Apples Design-Richtlinien (schwarz oder weiß, Apple-Logo, "Mit Apple anmelden") und ist genauso groß und prominent wie der Google-Button.
2. Verwende in der nativen App (isNativeApp()) signInWithRedirect und verarbeite getRedirectResult beim App-Start, inklusive Fehlern, mit einer sichtbaren Meldung statt eines stillen Fehlschlags. Behalte den Popup-Ablauf für Desktop-Browser. Leg die Wahl der Methode in eine einzige Konstante.
3. Mach unsere eigene Domain zur authDomain: Füge einen Express-Reverse-Proxy hinzu, der /__/auth/ an https://PROJECT_ID.firebaseapp.com weiterreicht (ein transparenter Proxy, kein Redirect; Pfade, Query-Strings und Cookies bleiben erhalten). Lies PROJECT_ID und die Auth-Domain aus Umgebungsvariablen.
4. Schreibe beim ersten Apple-Login displayName und email nach users/{uid}, falls sie leer sind.
5. Behandle auth/account-exists-with-different-credential mit einem Verknüpfungsablauf: Erkläre, welche Methode das Konto nutzt, melde mit dieser Methode an und rufe dann linkWithCredential auf.
6. Schreibe SETUP-AUTH.md mit allem, was ich konfigurieren muss: die Apple Services ID mit der Domain app.example.com und der Return-URL https://app.example.com/__/auth/handler, Key und Team ID für Firebase, die autorisierten Domains in Firebase und die WebViewGold-Einstellungen, die ich prüfen soll (google_login_helper_triggers in Config.swift, GOOGLE_LOGIN_HELPER_TRIGGERS in Config.java, deletecache aus).
7. Tests: Unit-Tests für den Verknüpfungsablauf, die Fehlerbehandlung beim Redirect und die Proxy-Route mit gemocktem Upstream. Ruf weder Google noch Apple auf.
Melde die geänderten Dateien und eine Gerätetest-Matrix für iOS und Android.Das sind die dokumentierten Standardwerte. Erweitere die Listen nur, wenn dein Login über andere Google- oder Facebook-Hosts läuft (starte den Login in einem Desktop-Browser und beobachte die Redirects). Auf Android kommen dieselben Präfixe in GOOGLE_LOGIN_HELPER_TRIGGERS und FACEBOOK_LOGIN_HELPER_TRIGGERS in Config.java.
// 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.Aktiviere Sign in with Apple für die App ID, lege eine Services ID an, registriere app.example.com und die Return-URL https://app.example.com/__/auth/handler, erstelle einen Sign-in-with-Apple-Key und notiere Key ID und Team ID.
Aktiviere den Apple-Provider (Services ID, Team ID, Key ID, privater Schlüssel) und Google. Füge app.example.com zu den autorisierten Domains hinzu.
Füge den Prompt ein, führe dann /review in der CLI aus und lies git diff. Prüfe zuerst den Proxy: Er muss die Anfragen durchreichen statt per Redirect umzuleiten, und er darf keine anderen Routen anfassen.
Öffne https://app.example.com/__/auth/handler im Browser. Er sollte von deiner Domain ausgeliefert werden, statt einen 404 zu liefern oder zu firebaseapp.com umzuleiten.
Bestätige die Trigger-Listen, lass deletecache auf iOS und CLEAR_CACHE_ON_STARTUP auf Android ausgeschaltet, und wenn du einen eigenen User Agent setzt, hänge ihn an den Standard-String an. Auf Android kann HOME_URL_LOGOUT auf deine Logout-URL zeigen, um Login-Cookies zu löschen.
Arbeite die Matrix unten auf TestFlight und einem internen Test-Track ab. Liste in den Review-Notizen die Login-Optionen auf und gib dem Reviewer einen E-Mail-Demo-Account (der Codex-Release-Workflow deckt den Rest der Einreichung ab).
authDomain bleibt auf firebaseapp.com. Der Redirect läuft durch, aber die App landet oft wieder auf dem Login-Screen, ohne Nutzer.googlelogin:// als Standard. Es übergibt den Login auf iOS an den Systembrowser und auf Android an einen Chrome Custom Tab, die Session lebt also außerhalb deiner WebView, außer dein Redirect holt sie zurück. Heb es dir für Sonderfälle auf (Android-Docs zum URL-Handling).Auf iOS nicht: Der Ablauf über appleid.apple.com wird automatisch erkannt und übernommen. Apple konfigurierst du in deinem Apple-Developer-Konto und in Firebase, und den Button fügst du deiner Web-App hinzu.
Nein. Google Play hat keine solche Regel. Viele Apps zeigen den Button aus Konsistenzgründen auf beiden Plattformen; wenn du das tust, teste den Ablauf vor dem Release auf einem Android-Gerät.
Fang mit Redirect auf deiner eigenen authDomain an, das empfiehlt Firebase für Mobilgeräte. Halte die Wahl in einer einzigen Konstante, damit du auf Popup wechseln kannst, falls ein Gerätetest ein Problem zeigt, und teste nach jeder Änderung beide Plattformen erneut.
Nein. OAuth braucht echte Provider-Konten, und die Codex-Sandbox hat standardmäßig keinen Netzwerkzugriff. Codex kann die Verknüpfungslogik, die Fehlermeldungen und die Proxy-Route mit Mocks testen; die echten Logins gehören in deine Gerätematrix.
Die WebViewGold-Seite ist identisch. In Supabase aktivierst du den Apple-Provider mit der Services ID und einem Client Secret, das aus deinem Key erzeugt wird (Apple begrenzt es auf sechs Monate, plane also die Rotation ein), und die Callback-URL ist der Auth-Callback deines Supabase-Projekts. Einen authDomain-Proxy musst du nicht bauen.
Gleiches Ergebnis, unterschiedlich viel Arbeit auf deiner Seite. Alle drei kommen mit Genehmigungsgarantie und 24/7 Support von echten Menschen.
$109 pro Plattform, einmalig
Die WebViewGold-Lizenz: ein fertiges Xcode- oder Android-Studio-Projekt. URL einfügen, Name und Icon setzen, Features einschalten, bauen und einreichen. Kostenlose Updates für immer.
Pakete auf der Hauptseite ansehen$349 pro Lizenz, einmaliges Add-on
Kein Mac, kein Xcode, kein Android Studio: Du konfigurierst im Browser, wir bauen beide Apps in der Cloud und übergeben sie an App Store Connect und die Play Console.
So funktioniert der Cloud Builder Kostenlose Demo ausprobieren$698 pro Plattform $798
Schick uns deine URL und dein Icon. Unser Team konfiguriert, baut und liefert deine App innerhalb von 72 Stunden, White-Label, inklusive Quellprojekten. Beide Plattformen für $1,158.
Full-Service-Details Powered by
Winter-Sale-Preise gültig bis 31. Dezember 2026.
App Store & Google Play Genehmigungsgarantie – oder Geld zurück innerhalb von 14 Tagen
Lieber abgeben? Full Service: Wir konfigurieren, bauen und liefern innerhalb von 72 Stunden, ab $698 pro Plattform. Fragen? Chatte mit uns – 24/7.
Erstattungen erfolgen zu den in unseren FAQ genannten Bedingungen: eine nicht inhaltsbedingte Ablehnung durch Apple und/oder Google, geltend gemacht innerhalb von 14 Tagen nach dem Kauf.