-
Notifications
You must be signed in to change notification settings - Fork 2.3k
Description
What feature would you like to see?
Cache password policy in validatePassword() to prevent QUOTA_EXCEEDED errors
Problem
The current validatePassword() implementation fetches the password policy from Firebase's Identity Toolkit endpoint on every single call. This causes serious issues in real-world usage:
When a user types their password character by character (e.g., "P-a-s-s-w-o-r-d-1-2-3-$"), that's 12 API calls just for one password entry. If users backspace and retype, it adds up quickly. Firebase has rate limits on this endpoint, so you eventually hit:
QUOTA_EXCEEDED: Exceeded quota for getting password policy
Why debouncing isn't the solution
Debouncing reduces the frequency of calls, but the real issue is that the password policy is static configuration set in Firebase Console — it never changes during a user session. Even one call per password field interaction is wasteful when you could fetch it once and reuse it.
Proposed solution
Cache the password policy after the first fetch:
First call: Fetch from Firebase API and store in memory
All subsequent calls: Use the cached policy (zero API calls)
The cache should be keyed per Firebase app (auth.app.name) to support apps that use multiple Firebase projects with different password requirements.
Expected behaviour
The password policy should be fetched once per app instance and reused for all subsequent validatePassword() calls, eliminating redundant API requests and preventing quota errors.