🐛 [rtdb, firestore, storage] permission denied errors are unhelpful

[cbenhagen]

Whenever we get a permission denied error (due to Rules), they are unhelpful. The expectation is to see the path and operation that failed, and optionally the JSON payload that was sent

How it works today

RTDB:

[VERBOSE-2:dart_vm_initializer.cc(41)] Unhandled Exception: [firebase_database/permission-denied] 
Client doesn't have permission to access the desired data.

Firestore

[VERBOSE-2:dart_vm_initializer.cc(41)] Unhandled Exception: [cloud_firestore/permission-denied] 
The caller does not have permission to execute the specified operation.

Cloud Storage

FLTFirebaseStorage: An unknown error occurred while calling method Reference#getDownloadURL

Ideal outcome

RTDB:

[VERBOSE-2:dart_vm_initializer.cc(41)] Unhandled Exception: [firebase_database/permission-denied] 
Client doesn't have permission to read /foo/bar/baz.

Firestore

[VERBOSE-2:dart_vm_initializer.cc(41)] Unhandled Exception: [cloud_firestore/permission-denied] 
The caller does not have permission to write /foo/bar/baz with payload {"hello": "world"}

Cloud Storage

FLTFirebaseStorage: An unknown error occurred while calling method Reference#getDownloadURL 
for "gs://foo.appspot.com/foo/bar/baz.jpg"

Resources

Firestore codepaths seem to have enough context to give better error messages without a big lift

This is a copy of issue #11677 which was most likely closed due to a user landing on the issue through a web search and then later commenting that it was fixed when his unrelated permission issue was solved.

/cc @lukepighetti

[MichaelVerdon]

Hi there, we won't be implementing this as verbose logs already display the information which you are requesting to be there.
I was able to see what path was denied for example by using flutter run --verbose. If you want to test it individually on Android or iOS you can use native side code to enable verbose logging.

[cbenhagen]

@MichaelVerdon thanks you very much for working on this issue! I see you have already created a PR for it which looks promising. May I please ask you to reconsider the decision of not moving forward with the implementation?

I just tested this on macOS and even with --verbose and the information is not available. Could it be that you have -FIRDebugEnabled in your Xcode project? That's the only way I know to get more information about the error. But it would still not be possible to properly log the error to a file or crashlytics. Also you can't easily determine where in your code the error was encountered.

Do you mind sharing some insights on what issues you encountered with your PR?

[cbenhagen]

@MichaelVerdon / @SelaseKay can you please re-open this issue?

[russellwheatley]

We try to mimic the upstream native SDKs as closely as we can. They do not report what you're asking but log it in debug logs. If you wish to report via Crashlytics it would be a case of calling the recordError API error handler (e.g. try/catch) and you can also pass along whatever information you wish such as the query/path.

[cbenhagen]

I just found an issue in the JS SDK where the team explained that providing more context (like which rule failed or document details) could leak sensitive rule structure or project specifics—something they want to avoid and that they prefer to invest more time in other tooling to help debug rules. I guess that's a fair point.