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?
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.
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.