firebase-js-sdk icon indicating copy to clipboard operation
firebase-js-sdk copied to clipboard

App Check fails after returning to an inactive background tab

Open hsubox76 opened this issue 1 year ago • 10 comments

Operating System

?

Browser Version

Chrome

Firebase SDK Version

10.6.0

Firebase SDK Product:

AppCheck

Describe your project's tooling

Next.js (v14) and TypeScript

Describe the problem

Copied from closed issue comment: https://github.com/firebase/firebase-js-sdk/issues/6708#issuecomment-1823462578

I am experiencing a similar issue with Firebase AppCheck. When a tab with my website remains inactive in the background, returning to it often results in the 403 error.

I suspect the root cause might be linked to reCAPTCHA Enterprise's inability to gather sufficient user interaction data in inactive tabs, leading to failed human verification checks (false positives).

A potential solution could be allowing the option to disable or limit attestation request throttling in the SDK. This way, if an attestation fails, a new attempt could be made promptly, potentially resolving the issue. This could mitigate issues arising from false positives.

For context, I recently integrated Firebase AppCheck into my staging environment, a production-like setup (using a live Firebase project on a deployed website) restricted to internal testing. The occurrence of this issue in a live environment would be highly detrimental to user experience.

Is there any update from the Firebase team regarding a solution to this problem?

Steps and code to reproduce issue

Copied from closed issue comment: https://github.com/firebase/firebase-js-sdk/issues/6708#issuecomment-1824793987

I've successfully replicated the problem across different devices and networks (different IP addresses). Here's a description of the steps I followed to reproduce the error:

Initial setup: Open a browser and navigate to a website integrated with Firebase App Check. Ensure that App Check functions correctly during initial usage. Background tab: Without closing the first tab, open a new tab and visit a different website. Browser inactivity: Open another browser window, keeping the first one with the App Check site in the background. Waiting period: Leave the App Check site inactive for approximately 1 hour. Error observation: Return to the App Check tab. A 403 error is likely visible in the console. If not, extend the inactive period and check again. Additional scenarios where the error occurs:

Sleep mode: Leaving the website open in a browser on a notebook that goes into sleep mode without shutting down. Upon resuming, the 403 error is present. Context for my testing environment:

The website is built using Next.js (v14) and TypeScript. Firebase JS SDK version: 10.6.0. Attestation provider: I'm transitioning from solely using reCAPTCHA to incorporating App Check with reCAPTCHA Enterprise. This shift aims to manage the high costs associated with reCAPTCHA. Token TTL: Set to 1 hour. Deployment: Tests are conducted on a live website hosted on Vercel, simulating a production environment with an active Firebase project. The site is also configured as a Progressive Web Application (PWA). Browser used: Google Chrome. Forcefully refreshing the browser (SHIFT + F5 in Chrome) typically resolves the 403 error. However, a regular refresh (F5) often does not.

hsubox76 avatar Apr 23 '24 18:04 hsubox76

Hi guys, any update on this issue? I'm experiencing this with Firebase v10.12.5

HSCOGT avatar Sep 05 '24 12:09 HSCOGT

I'm experiencing this with "firebase": "^10.13.2" latest version

AmilKey avatar Sep 25 '24 18:09 AmilKey

any updates?

AmilKey avatar Oct 23 '24 10:10 AmilKey

@hsubox76 Any updates? As of now App Check is doing more harm than good and we're forced to disable it on production. We were using it for a Web App.

mandalornl avatar Nov 21 '24 15:11 mandalornl

We're also using it for a web app (with Next.js).

We're catching all global errors using React Error Boundary, determining whether the error is a "permissions denied" coming from Firestore and then reloading the browser (1 attempt, if this still fails, the user is presented with an error screen and a manual reload button).

This, of course, isn't an ideal situation. The user might lose work which wasn't saved yet, etc.

@hsubox76, have you got any updates on this?

StijnMaenhautCZ avatar Nov 25 '24 12:11 StijnMaenhautCZ

This also happens for me, using svelte with firebase ^11.3.1.

any workarounds for this?

doshpin avatar May 13 '25 09:05 doshpin

Hey - any updates on this one? We've also hit this in production intermittently several times over the last few months whilst running the latest firebase js sdks.

  • Looks like there has been a fare amount of noise on across the original and currently open issue so any guidance would be appreciated!

Matt-Jennings-GitHub avatar Jul 01 '25 16:07 Matt-Jennings-GitHub

This is still happening, but the error seems to have changed from 403 → 401 (perhaps due to switching from reCPATCHA v3 to reCPATCHA Enterprise).

Image
POST https://content-firebaseappcheck.googleapis.com/v1/projects/<projectId>/apps/1:...:web:...:exchangeRecaptchaEnterpriseToken?key=... 401 (Unauthorized)
@firebase/app-check: AppCheck: 401 error. Attempts allowed again after 00m:01s (appCheck/initial-throttle).

anisabboud avatar Sep 01 '25 09:09 anisabboud

I was able to fix the issue in one of our projects by manually calling getToken with forceRefresh = true everytime the window becomes visible again.

import { initializeApp } from 'firebase/app';
import { 
  initializeAppCheck,
  ReCaptchaEnterpriseProvider,
  getToken,
} from 'firebase/app-check';

const app = initializeApp(/* your firebase config */ {});
const appCheck = initializeAppCheck(app, {
  provider: new ReCaptchaEnterpriseProvider(/* your enterprise key */ ''),
  isTokenAutoRefreshEnabled: true,
});

document.addEventListener('visibilitychange', async () => {
  if (document.visibilityState !== 'visible') {
    return;
  }
 
  try {
    await getToken(appCheck, true);
  } catch (error) {
   console.error(error);
  }
}

mandalornl avatar Nov 06 '25 15:11 mandalornl

@hsubox76 @dlarocque shouldn't this be considered a bug? this is happening for us every day

LanderBeeuwsaert avatar Nov 06 '25 17:11 LanderBeeuwsaert