[GH-ISSUE #104] Authorization rules semantics #30

New issue

Open

opened 2026-05-23 08:39:00 -06:00 by gitea-mirror · 0 comments

gitea-mirror commented

2026-05-23 08:39:00 -06:00

Owner

Originally created by @pkaminski on GitHub (Mar 9, 2024).
Original GitHub issue: https://github.com/appy-one/acebase-server/issues/104

I'm trying to port an application from Firebase to AceBase and I'm having trouble migrating the authorization (security) rules:

In Firebase, the newData variable references the prospective state of the entire database should the write operation being checked go through. While it points to the current property by default, it's possible to use child() and parent() to access any value in the database whether it was part of the write or not. It looks like AceBase uses data for this instead but it only holds the values updated as part of the operation, so if we expect differently structured operations at a given location then we must manually check whether a new value is in fact being written and fall back to old data if not in our .validate rules.
In Firebase, the root and data variables allow synchronous access to the current state of the entire database; any values obtained through them are guaranteed to represent a single state of the database during the execution of all rules leading up to either applying or rejecting the operation. The equivalent in AceBase appears to be the async value() function, but it's not clear whether the database could be mutated by concurrent requests while waiting for value() to return, either within a rule or between rules for a single operation.

If my understanding above is correct, then:

Would it be possible for AceBase to support the Firebase semantics for data / newData, even if not using that exact syntax?
If not, does AceBase at least guarantee that any paths accessed with value() won't be mutated until the operation is either applied or rejected?

Thanks.

(cc @fahhem)

Originally created by @pkaminski on GitHub (Mar 9, 2024). Original GitHub issue: https://github.com/appy-one/acebase-server/issues/104 I'm trying to port an application from Firebase to AceBase and I'm having trouble migrating the authorization (security) rules: - In Firebase, the `newData` variable references the prospective state of the entire database should the write operation being checked go through. While it points to the current property by default, it's possible to use `child()` and `parent()` to access any value in the database whether it was part of the write or not. It looks like AceBase uses `data` for this instead but it only holds the values updated as part of the operation, so if we expect differently structured operations at a given location then we must manually check whether a new value is in fact being written and fall back to old data if not in our `.validate` rules. - In Firebase, the `root` and `data` variables allow synchronous access to the current state of the entire database; any values obtained through them are guaranteed to represent a single state of the database during the execution of all rules leading up to either applying or rejecting the operation. The equivalent in AceBase appears to be the async `value()` function, but it's not clear whether the database could be mutated by concurrent requests while waiting for `value()` to return, either within a rule or between rules for a single operation. If my understanding above is correct, then: 1. Would it be possible for AceBase to support the Firebase semantics for `data` / `newData`, even if not using that exact syntax? 2. If not, does AceBase at least guarantee that any paths accessed with `value()` won't be mutated until the operation is either applied or rejected? Thanks. (cc @fahhem)