firebase / firebase/firebase-js-sdk
FR: Improve development experience by passing Security Rules 'debug' output to the client(s)
- Dominant language
- TypeScript
- Stars
- 5.1k
- Forks
- 1k
- Avg merge
- 2d 21h
- Merged PRs (30d)
- 37
Description
### [REQUIRED] Describe your environment
* Operating System version: macOS 11.2.3
* Browser version: Chrome 89
* Firebase SDK version: 9.0.0-beta1 (not relevant for the FR)
* Firebase Product: firestore
### [REQUIRED] Describe the problem
Debugging Security Rules is a bit tedious, and I came up with a suggestion to better integrate the `debug` instruction in them with the web front end.
My current case:

The lines in the rules is:
```
allow read: if debug(request.auth.uid) != null
//allow read: if isSignedIn()
//allow read: if isMember() && (!isRemoved() || isAuthor())
```
The `debug` instruction is there to let me check what the value of `request.auth.uid` is, when the rule rejects the access. The problem is that that output goes way deep, into the emulator log files.
Suggestion:
If one has `debug` in the Security Rules, add its output to the API response telling the client that the rule failed (currently "Null value error. for 'list' @ L26").
This likely makes the FR solely on the emulator side and *no changes* would be needed in any of the clients, if the change is created there.
Let me know whether you like the idea, and if you can move it to the right people internally.
#### Steps to reproduce:
Write a security rule that mysteriously fails. Try to figure out why, from the browser.
### Why this would be a bad idea?
Error messages should never reveal too much about the underlying implementation. In this case, `debug` is a debugging feature so any change in such exposure would only happen in the debugging environment, no changes to production responses.
Contributor guide
Assessment
This issue has not been assessed yet.