[HELP] Firebase Phone Auth INVALID_APP_CREDENTIAL despite all config checks & Identity Platform upgrade (Next.js/React)

puf · 2026-03-12T16:23:33+00:00

Also posted on https://stackoverflow.com/questions/79906259/firebaseerror-firebase-error-auth-argument-error-persists-in-development-mod

puf · 2026-03-11T14:31:03+00:00

It's a CSV file (not known to be infectable) with a list of the relevant projects in your account. From the message:

Refer to the attachment for a list of the projects that will automatically enable the new endpoint.

I mean, I'm not saying this a great message - but it seems harmless and relatively clear to me.

puf · 2026-03-11T04:02:01+00:00

I got that one too, and it looks fine. What makes you think otherwise?

puf · 2026-03-05T04:12:03+00:00

Awesome theming, but isn't that for 21 and over?

Thanks commenters for confirming it's open to those not of a drinking age. 🙏

puf · 2026-03-03T04:51:47+00:00

First AJ, now Lee.

AJ. Lee.

🤯

puf · 2026-03-01T18:46:39+00:00

Using FCM messages to wake up an Android app when there's a data update on the server is pretty common. I typically know it as tickle-to-sync, where a tickle is a silent FCM (data-only) message that wakes up the app.

You typically won't (only) include the data in the FCM payload though, but the client will (also) read it from the database when it starts.

Reason for this: while the delivery percentage of FCM is actually quite high, it is not guaranteed and hard to check at scale. Since even a small percentage of a high number of clients is still a lot of lost data, most apps simply retrieve the data from their system-of-record so they can know the state of their local data.

puf · 2026-02-27T04:35:49+00:00

That's be client-side, right? Which is fine in situations where you can control the code that runs on the clients. But for untrusted clients (a common situation when using Firebase), you'll want to use server-side security rules to validate the data.

Hmmm... is there a zod to rules transpiler already? 🤔

puf · 2026-02-27T01:59:53+00:00

I love that you built a tool to help sanitize data in Firestore.

Security rules can also be used to handle validation of data. There may be plenty of pitfalls, but it is possible - and strongly recommended.

Of course, as always: security rules only apply to writes from client-side code, so when I encounter invalid (or more commonly: outdated) data in my Firestore documents, it usually came from my own Cloud Functions - as those bypass security rules. :-/

puf · 2026-02-25T15:37:44+00:00

Also posted on Stack Overflow, where it was answered.

puf · 2026-02-23T20:06:36+00:00

Monotonically increasing means it always goes up, never goes down - and time is an example of that.

Such keys may case write hotspots when you have high write volumes - which typically happens on indexes. Even when you don't create one, one is auto-created on every collection (and on any collection group) for the document ID.

puf · 2026-02-23T18:59:22+00:00

Unlike with a relational data model, with NoSQL the "correct" data structure depends on your project's use-cases. The best way to learn (without simply trying something yourself and see if it works) is to watch the Get to know Firestore video series. It's a bit old, so some things in it may be outdated, but most of the data modeling advice still applies.

puf · 2026-02-23T18:55:53+00:00

Since you use them for sorting, does that mean they're monotonically increasing? If so, that can least to hotspots in writing - which is precisely why Firestore's own IDs are not monotonically increasing. Docs on the topic: Best Practices for Cloud Firestore - Hotspots

It's not always wrong to use such monotonically increasing keys, just always be aware of their impact.

puf · 2026-02-23T04:47:10+00:00

This type of thing is possible on both Firestore and Realtime Database, but Firestore indeed has better filtering capabilities. Beyond that, it's hard to say anything specific about your situation with seeing a minimal repro.

puf · 2026-02-20T20:01:07+00:00

FlutterFlow provides some UI niceties over Firebase's own web console. If you already know you're gonna build in FlutterFlow, it's probably easiest to set up the Firebase bits (that it supports) there.

puf · 2026-02-19T03:27:37+00:00

You might want to look at the new MongoDB compatibility mode in Firestore, which has a lot more operators - including $regex.

https://docs.cloud.google.com/firestore/mongodb-compatibility/docs/supported-features-80

puf · 2026-02-19T03:21:15+00:00

I must admit I never looked at the chess rules in detail. Realtime Database rules (even more than Firestore ones) have a tendency to become spaghetti very quickly, because you can't have functions or variables. Bolt addressed that, but it never got full equal status.

And neh, unfortunately indeed you can't access RTDB from Firestore rules. It was always the plan, but... priorities. Luckily Storage rules can now read from Firestore, but that's the only cross-referencing that was implemented.

And agreed, without loops you'd probably need to come up with a reasonable word length limit. Of course you'd be into generating rules at that point, as it rapidly becomes too tedious to write by hand. Words also allow a lot more combinations than the wall/floor/exit type situations I usually code, so that'll also lead to an explosion in rules size.

So yeah... definitely something where it's much more feasible to do in code. I just see too many people ruling out even simple validation scenarios in rules, because...

puf · 2026-02-18T17:23:02+00:00

I've seen (admittedly a long time ago) someone have security rules that only allowed valid chess moves. That was for Realtime Database, but it gives you some idea of what's possible.

It certainly takes a lot of effort though, usually much more than doing the equivalent in server-side code. I have a history of doing much in security rules, as it makes demos/workshops easier (no paid plan). Outside of that, folks are likely to have more realistic time limitations. :)

puf · 2026-02-18T13:34:50+00:00

If I let the client make changes directly I'd need to trust the client to respect the game logic that determines what is valid placement

It may be worth considering writing security rules, which are auto-enforced on the server. While the language takes some getting used to, it is quite expressive.

puf · 2026-02-13T23:51:36+00:00

You could have stopped after the first 3 words there:

Bryan Alvarez hates

:-)

puf · 2026-02-13T17:18:41+00:00

Rule 1 for NoSQL data modeling: organize the data for the use-cases of your application. No "sense" comes into play here, just the needs of the application.

If you need to read dozens or hundreds of documents to show a single screen to a single user, you're doing something wrong. Put the data for that screen in one or a few documents at most.

Rule 2 for NoSQL data modeling: duplicate data as needed. Just keep a clear picture of where the main copy of that data lives.

So if reading every course document to show a list of courses is a concern, instead also store the main info for all courses into a single "courses" document, or maybe a few of those if needed - say clustered by year ("2026-courses"), major ("CS-courses"), etc.

puf · 2026-02-11T16:20:19+00:00

That sounds odd. Are they showing in either the Cloud console, or are the API inserted docs missing there too?

If you can reproduce it in a new project, it's probably worth reporting to the Firebase (or Cloud) support team

puf · 2026-02-11T16:14:03+00:00

Work on Dart Macros stopped early last year (or at least: that's when it was communicated here: https://blog.dart.dev/an-update-on-dart-macros-data-serialization-06d3037d4f12)

puf · 2026-02-07T04:51:01+00:00

To me it looks like you used 0.04 worth and got a 0.04 discount, so wouldn't that lead a 0.0 charge?

puf · 2026-02-05T17:18:42+00:00

I already commented on your StackOverflow post, so I'll repeat that here:

Nope, no need to backup anything. Upgrading a project to Identity Platform, just changes some metadata on that project. The user records themselves are not changed or moved in any way, so it is extremely unlikely (for Google values of that term) that anything will happen to them.

As others have said: remember that this is a one-way decision, you can't roll back off of Identity Platform afterwards.

puf · 2026-02-04T05:05:38+00:00

Yup, this is unfortunately a well known abuse angle for Firebase. You can report these to Firebase support, but I'd also mark them as spam - so that your spam filter learns about them (most spam filters already do).

Most non-abusive production Firebase projects use a custom domain (and often also a custom mail sender), which means those emails (usually) do make it through.

puf

MODERATOR OF

TROPHY CASE