Files
pingu-concerts/docs/wiki/Firebase-Setup-Prompt.md

65 lines
3.8 KiB
Markdown

# ChatGPT-Prompt: Firebase-E2E-Wiederholung für MetalCircle
Den folgenden Prompt in einen neuen Chat kopieren. Keine Secret-Dateien mitgeben.
```text
Hilf mir, den bereits eingerichteten serverseitigen Firebase-Zugang für MetalCircle
im lokalen Entwicklungs-/Testbetrieb zu prüfen oder den lokalen FCM-E2E-Test zu
wiederholen. Verwende aktuelle offizielle Firebase-/Google-Cloud-Dokumentation,
falls IAM-Fehler untersucht werden müssen.
Ausgangslage:
- Privates Projekt MetalCircle, Repository historisch kai/pingu-concerts.
- Android: Capacitor 6, Package ID dauerhaft de.pinguholic.concerts.
- Firebase-Projekt-ID: `metalcircle-30d9b`.
- Android-google-services.json ist vorhanden. Tokenregistrierung und manuelle
Firebase-Testnachrichten/Kampagnen funktionieren bereits.
- Backend: FastAPI, PostgreSQL, Docker Compose, firebase-admin Python 7.1.0.
- Pushs für Freundschaftsanfragen, Direktnachrichten und Einladungen sind implementiert.
Kategorien und DE/EN werden pro Empfänger beachtet; Nachrichteninhalt bleibt privat.
- Lokaler Versand wurde mit einem echten Android-Gerät über FCM HTTP v1 erfolgreich
getestet. Falls der HTTP-403 `PERMISSION_DENIED` erneut auftritt, wurde für den
dedizierten Test-Service-Account diese Rolle als erforderlich bestätigt:
`roles/firebasecloudmessaging.admin` (Firebase Cloud Messaging API Admin).
- Der lokale Service Account ist
`metalcircle-push-local@metalcircle-30d9b.iam.gserviceaccount.com`.
- Die Service-Account-Datei wird lokal schreibgeschützt als
`/run/secrets/firebase-service-account.json` eingebunden.
Bitte begleite mich bei:
1. Den bestehenden Projekt-, Service-Account- und read-only-Mount-Status anhand
ungefährlicher Metadaten prüfen; keine neue Rolle oder Schlüsseldatei anlegen.
2. Nur bei einem erneuten Versandfehler die FCM HTTP-v1-Aktivierung und die
Zuweisung von `roles/firebasecloudmessaging.admin` für genau diesen lokalen
Service Account im Projekt `metalcircle-30d9b` prüfen.
3. Lokale `.env`-Konfiguration nur auf gesetzte Werte prüfen, nie Inhalte ausgeben:
PUSH_ENABLED=true
FIREBASE_PROJECT_ID=<echte Projekt-ID>
FIREBASE_SERVICE_ACCOUNT_FILE=<absoluter Pfad zur Secret-Datei>
4. Lokaler Start mit `compose.yml` plus `compose.push.yml`. Dieses Override mountet die Datei
read-only unter /run/secrets/firebase-service-account.json und setzt im Backend
GOOGLE_APPLICATION_CREDENTIALS auf diesen Pfad.
Lokal HTTP: COOKIE_SECURE=false docker compose -f compose.yml -f compose.push.yml up -d --build web
Auf einem HTTPS-Testserver bleibt COOKIE_SECURE=true.
5. Falls erforderlich, gezielten lokalen E2E-Test mit Testkonten ausführen:
Freundschaftsanfrage, Nachricht, Veranstaltungseinladung und echter Android-
Empfang. Bei erneutem HTTP 403 zuerst die bereinigte Fehlerantwort, Zielprojekt,
aktive Service-Account-Identität und Projektrollen prüfen; bei Erfolg keine
unnötigen Tests, Builds oder Cloud-Änderungen ausführen.
Grenzen:
- Niemals Schlüssel, Tokens, vollständige .env oder JSON-Inhalte im Chat anfordern.
- google-services.json ist Client-Konfiguration, kein Backend-Service-Account.
- Keine Legacy-Server-Keys und keine Admin-Credentials in der Android-App.
- kai = persönlicher Gitea-Account; codex-bot = Git; metalcircle-bot = Issue-API.
Keinen dieser Zugänge für Firebase verwenden.
- PinguCore ist lokal. Cloud-Staging betreue ich separat. Kein automatischer
Cloud-/Produktionszugriff oder Produktionsdeployment.
- Test und Produktion bekommen getrennte Credentials.
- Verbietet eine Organisationsrichtlinie JSON-Schlüssel, umgehe sie nicht.
Erkläre die vorgesehenen Alternativen und welche Code-Anpassung nötig wäre.
Frage zuerst nur nach der Ziel-Testumgebung und gehe dann schrittweise vor.
Prüfe Ergebnisse anhand ungefährlicher Statusangaben, niemals Secret-Inhalte.
```