Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[🐛] Android: App Check provider factory is only installed from JS, so Firestore/Storage requests go out unattested

Aperta
  • Qualcosa non va?
#9,227 7 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
42/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
java, react-native
Ambito
mobile, security

Direzione di ricerca

Inizia con ReactNativeFirebaseAppCheckModule.java e NativeRNFBTurboAppCheck.java nei punti di ingresso configureProvider e activate, quindi traccia l’inizializzazione Android intorno a FirebaseInitProvider. Riproduci le richieste a Firestore e Storage soggette alle regole descritte nell’issue e verifica che il provider sia registrato prima dell’inizializzazione di FirebaseApp. Il lavoro è completato quando tali richieste contengono un token App Check valido e il comportamento esistente di Functions rimane intatto.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

blocked: customer-response platform: android plugin: app-check Stale type: bug

Issue

On Android, installAppCheckProviderFactory(...) is only reachable from JavaScript. Firebase requires it to be registered before FirebaseApp is configured, and on Android FirebaseApp is auto-initialized by FirebaseInitProvider (a ContentProvider) before any JS runs. The result: Firestore and Storage requests are sent without an App Check token, and any rule using request.app != null rejects them. Cloud Functions is unaffected.

This is not the iOS debug-provider issue fixed by #9166. That PR states the requirement precisely, though:

Firebase requires the provider factory to be registered before FirebaseApp.configure(), which runs before JS.

On Android there is currently no way for an app to satisfy that, because the only install path is a bridge method.

Where

Both call sites are JS-invoked, and the structure is unchanged on main:

  • v23.8.6 — ReactNativeFirebaseAppCheckModule.java:134 (configureProvider), :168 (activate)
  • main — NativeRNFBTurboAppCheck.java:148 (configureProvider), :180 (activate)

There is no ContentProvider, Initializer, Application hook, or static block that installs the factory at process start.

Why Functions works but Firestore/Storage don't

Functions requests an App Check token per invocation, at call time, so a factory installed later is still picked up. Firestore and Storage capture App Check provider state when the client/stream is first created — which happens before JS has installed the factory.

Reproduction

  1. Android app, App Check debug provider, debug token registered in the Firebase Console.
  2. await initializeAppCheck({ provider, isTokenAutoRefreshEnabled: true }) early in app start — before any Firestore or Storage call.
  3. Set a Firestore rule requiring request.app != null, and a Storage rule likewise.
  4. Read a document and upload a file.

Observed:

firestore: [firestore/permission-denied] The caller does not have permission to execute the specified operation.
storage:   [storage/unauthorized] User is not authorized to perform the desired action.

A callable Cloud Function in the same session, in the same app, succeeds with {"auth":"VALID","app":"VALID"}.

The token is genuinely available — it just isn't sent

This is the part that rules out a configuration mistake:

  • RNFBAppCheck: configureProvider - [DEFAULT]/debug/null
  • RNFBAppCheck: Provider::getToken - delegating to native provider
  • The App Check token cache (shared_prefs/com.google.firebase.appcheck.store.*.xml) is rewritten during the failing run, which only happens after a successful token exchange with the backend.
  • App data was never cleared, so the debug secret is the one already allowlisted in the Console.

So a valid token was minted and cached before the failing requests, and Functions demonstrably transmits it. Firestore and Storage do not.

Control

Same APK, same session, same token. The only variable changed is the rule's gate:

Rules Firestore read Storage upload
hasAppCheck() → request.app != null hangs, never returns [storage/unauthorized]
same file, gate body replaced with return true succeeds succeeds

Every other condition in the Storage rule (uid-matches-path, size cap, content type, filename pattern, ban check) is satisfied by the exact request the gate rejected.

Also worth fixing: the Firestore failure is silent

A rules rejection on a Firestore transaction does not reject the promise — the SDK retries indefinitely. With no error surfaced, the call simply never settles. On a cold start this presents as an app hanging on its loading state with nothing at all in logcat, which makes it very hard to attribute. A snapshot listener with an error callback does report permission-denied correctly; it's the transaction path that's silent.

Environment

@react-native-firebase/app          23.8.6
@react-native-firebase/app-check    23.8.6
@react-native-firebase/firestore    23.8.6
@react-native-firebase/storage      23.8.6
@react-native-firebase/functions    23.8.6
react-native                        0.76.9
expo                                52.0.0
newArchEnabled                      false
Android                             API 34 emulator (Play Store image)

Source citations above are against main, so this does not appear to be fixed in 26.x.

Suggested direction

Expose a native-side registration path that runs before FirebaseApp initialization — e.g. an Initializer/ContentProvider ordered ahead of FirebaseInitProvider, or a documented Application.onCreate() hook — so the factory can be installed with the provider choice supplied by build config rather than by JS. Alternatively, document that Android cannot support rule-level App Check for Firestore/Storage today, since the current docs imply otherwise.

Lingua principale
TypeScript
Stelle
12.3k
Fork
2.3k
Merge medio
3g 6h
PR unite (30g)
39

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di invertase/react-native-firebase

Tutte le issue di invertase/react-native-firebase

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.