github-starred/acebase-server

Fork 0

mirror of https://github.com/appy-one/acebase-server.git synced 2026-05-25 06:02:16 -06:00

[GH-ISSUE #92] Auth rules don't cascade on error #25

New issue

Closed

opened 2026-05-23 08:38:50 -06:00 by gitea-mirror · 5 comments

gitea-mirror commented

2026-05-23 08:38:50 -06:00

Owner

Originally created by @fahhem on GitHub (Aug 1, 2023).
Original GitHub issue: https://github.com/appy-one/acebase-server/issues/92

Originally assigned to: @appy-one on GitHub.

Hello! I'm trying to migrate an existing Firebase app and it seems auth rules don't cascade when a shallow rule errors (such as when auth is null and the rule mentions auth.token).

This seems to be the case because in rules.ts, in isOperationAllowed, if the rule throws an exception then there's no chance to cascade down. If I replace the return { ... code: 'exception'... }; line with a continue; then I get the expected behavior.

Use case:

I have a mix of authenticated and unauthenticated/anonymous users, and I would like anonymous users to be able to read a few specific paths. An example is minClientBuild. However, I would also like to restrict the ability to read/write the root path (you can move these fields under client/ and limit the ability to read/write /client/ but make /client/minClientBuild anonymous readable):

Here's my rules.json:

{
  "rules": {
    "minClientBuild": {
      ".read": "true",
      ".validate": "newData.isNumber()",
      "$other": {
        ".validate": false
      }
    },
    ".read": "((auth.token.expires == null || auth.token.expires > now) && auth.token.provider == null ? auth.uid : null) == 'server'",
    ".write": "((auth.token.expires == null || auth.token.expires > now) && auth.token.provider == null ? auth.uid : null) == 'server'",
    "$other": {
      ".validate": false
    }
  }
}

In Firebase, this works, as the deeper and more-permissive rule (".read": "true"} trumps all the shallower rules. However, in acebase-server, if I write that to the rules.json, and add logging, I see that the top-level .read rule is being run and fails since auth is null, and it never gets around to trying /minClientBuild/.read out.

According to: https://firebase.google.com/docs/rules/insecure-rules#improperly_inherited_rules

Originally created by @fahhem on GitHub (Aug 1, 2023). Original GitHub issue: https://github.com/appy-one/acebase-server/issues/92 Originally assigned to: @appy-one on GitHub. Hello! I'm trying to migrate an existing Firebase app and it seems auth rules don't cascade when a shallow rule errors (such as when `auth` is `null` and the rule mentions `auth.token`). This seems to be the case because in [rules.ts](https://github.com/appy-one/acebase-server/blob/master/src/rules.ts#L247), in `isOperationAllowed`, if the rule throws an exception then there's no chance to cascade down. If I replace the `return { ... code: 'exception'... };` line with a `continue;` then I get the expected behavior. Use case: I have a mix of authenticated and unauthenticated/anonymous users, and I would like anonymous users to be able to read a few specific paths. An example is `minClientBuild`. However, I would also like to restrict the ability to read/write the root path (you can move these fields under `client/` and limit the ability to read/write `/client/` but make `/client/minClientBuild` anonymous readable): Here's my rules.json: ``` { "rules": { "minClientBuild": { ".read": "true", ".validate": "newData.isNumber()", "$other": { ".validate": false } }, ".read": "((auth.token.expires == null || auth.token.expires > now) && auth.token.provider == null ? auth.uid : null) == 'server'", ".write": "((auth.token.expires == null || auth.token.expires > now) && auth.token.provider == null ? auth.uid : null) == 'server'", "$other": { ".validate": false } } } ``` In Firebase, this works, as the deeper and more-permissive rule (`".read": "true"}` trumps all the shallower rules. However, in acebase-server, if I write that to the `rules.json`, and add logging, I see that the top-level `.read` rule is being run and fails since `auth` is `null`, and it never gets around to trying `/minClientBuild/.read` out. According to: https://firebase.google.com/docs/rules/insecure-rules#improperly_inherited_rules

gitea-mirror closed this issue

2026-05-23 08:38:54 -06:00

gitea-mirror commented

2026-05-23 08:38:55 -06:00

Author

Owner

@appy-one commented on GitHub (Sep 20, 2023):

@fahhem In AceBase, rule functions should be written using the correct Javascript syntax. Rules causing an exception because they have errors, should not allow access - this is a deliberate decision. I notice I wrote that the rules in AceBase are identical to those in Firebase in the documentation, but I will change that sentence because it is not true. See https://github.com/appy-one/acebase-server#setup-authorization-rules for more info!

@appy-one commented on GitHub (Sep 20, 2023): @fahhem In AceBase, rule functions should be written using the correct Javascript syntax. Rules causing an exception because they have errors, should not allow access - this is a deliberate decision. I notice I wrote that the rules in AceBase are identical to those in Firebase in the documentation, but I will change that sentence because it is not true. See https://github.com/appy-one/acebase-server#setup-authorization-rules for more info!

gitea-mirror commented

2026-05-23 08:38:56 -06:00

Author

Owner

@fahhem commented on GitHub (Sep 20, 2023):

That's unfortunate! I'm trying to migrate an existing product to AceBase, and the closer the compatibility, the better. We're hoping to migrate over fully and basically switch our payments to Google to funding acebase instead, but if migration requires too many changes we'll have to stop

@fahhem commented on GitHub (Sep 20, 2023): That's unfortunate! I'm trying to migrate an existing product to AceBase, and the closer the compatibility, the better. We're hoping to migrate over fully and basically switch our payments to Google to funding acebase instead, but if migration requires too many changes we'll have to stop

gitea-mirror commented

2026-05-23 08:38:57 -06:00

Author

Owner

@appy-one commented on GitHub (Sep 25, 2023):

@fahhem I'm not sure that is unfortunate!

The initial plan was to be 100% compatible with Firebase's rules but while implementing I found that they were very unfriendly to code, and extremely hard to read for others. Because AceBase is entirely JS based, it made sense to let the rules be executed by V8 instead of manually parsing and executing.

The result is that you can now write your rules in JS (Or TypeScript), include them in your project's source code so you can debug, step through, console.log, execute misc. (async) code such as external API calls, and add comments. Bonus: you can even unit test your rules!

I'm sure that if you migrate and convert your rules to JS/TS, you will never look back again!

@appy-one commented on GitHub (Sep 25, 2023): @fahhem I'm not sure that is unfortunate! The initial plan was to be 100% compatible with Firebase's rules but while implementing I found that they were very unfriendly to code, and extremely hard to read for others. Because AceBase is entirely JS based, it made sense to let the rules be executed by V8 instead of manually parsing and executing. The result is that you can now write your rules in JS (Or TypeScript), include them in your project's source code so you can debug, step through, console.log, execute misc. (async) code such as external API calls, and add comments. Bonus: you can even unit test your rules! I'm sure that if you migrate and convert your rules to JS/TS, you will never look back again!

gitea-mirror commented

2026-05-23 08:38:58 -06:00

Author

Owner

@fahhem commented on GitHub (Oct 5, 2023):

The downside of this is that a project that works in Firebase can't migrate over other than completely. We would like to migrate certain instances over to Acebase first, then make sure any bugs/perf issues/differences are hammered out, then migrate over other instances. Would you consider a firebase_compat flag that would alter things like this? Once we're fully migrated, I'd happily work on switching off the firebase_compat flag in our codebase and report back.

@fahhem commented on GitHub (Oct 5, 2023): The downside of this is that a project that works in Firebase can't migrate over other than completely. We would like to migrate certain instances over to Acebase first, then make sure any bugs/perf issues/differences are hammered out, then migrate over other instances. Would you consider a firebase_compat flag that would alter things like this? Once we're fully migrated, I'd happily work on switching off the firebase_compat flag in our codebase and report back.

gitea-mirror commented

2026-05-23 08:38:59 -06:00

Author

Owner

@appy-one commented on GitHub (Dec 24, 2023):

Sorry for the wait, but I have to say no. I made a deliberate choice not to support Firebase's rule syntax because they are such a mess. If you want to migrate your rules to AceBase, you'll have to rewrite them to javascript.

@appy-one commented on GitHub (Dec 24, 2023): Sorry for the wait, but I have to say no. I made a deliberate choice not to support Firebase's rule syntax because they are such a mess. If you want to migrate your rules to AceBase, you'll have to rewrite them to javascript.