Cascading security rule and $ variables.

[Flash Bump]

Hi again,

In this sample:

1. {
2. "rules": {
3. "rooms": {
4. // this rule applies to any child of /rooms/, the key for each room id
5. // is stored inside $room_id variable for reference
6. "$room_id": {
7. "topic": {
8. // the room's topic can be changed if the room id has "public" in it
9. ".write": "$room_id.contains('public')"
10. }
11. }
12. }
13. }
14. }

Why would "topic" be writable, since the cascading rule states:

The child rules can only grant additional privileges but cannot revoke a read or write privilege.

As rooms declares no .read or .write, its child should be neither readable, nor writable.

What am I missing here?

Thanks.

F.

[Flash Bump]

Got it: privileges can only be added, not remove, while going down the tree.

For instance:

{

  "rules": {

     "foo": {

        ".read": false,

        "$foo_id": {

          ".read": true

        }

     }

  }

}

/foo cannot be read (="listed" if used as a container).

Any /foo/whateverChild can be read.

F.

[Jacob Wenger]

Hey F.

You got it. A good way to think about it is that .write and .read rules are ORed together all the way down the tree, so if one is true at any level in a node's hierarchy, the read or write will succeed. Meanwhile .validate rules are ANDed together, meaning they all need to be true for the write to succeed.

Jacob

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/6c4a1906-2a2c-4386-9a9e-3b7f775ce660%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Logan Joecks]

Hi Jacob,

This generally makes sense to me, except I'm not sure how to set up rules based on how my data's structured. Basically, I want to be more restrictive as I go down the tree. Anything directly on the top-level of a user object ($user_id) can be read at all times, except that I want to restrict the nested 'picks' structure based on the logic I have below.  I would essentially be revoking the access I already gave higher up the hierarchy.

"rules": {

     "users": {

       "$user_id": {

         ".read": ???,

         "picks": {

           ".read": "$user_id === auth.uid || now > 1456709400000"

         }

       }

     }

 }

Can this be accomplished?

Thanks,

Logan

[Frank van Puffelen]

Nope. As said in this exact topic: you can add privileges, you cannot remove privileges. This is one of the reasons why Firebase recommends against unnecessary nesting.

Typically this means that you should put the parts that you want different access control on, into a higher-level branch in the tree.

"rules": {

     "users": {

       "$user_id": {

         ".read": true,

       }

     },

     "picks": {

       "$user_id": {

           ".read": "$user_id === auth.uid || now > 1456709400000"

         }

       }

     }

 }

Now you can put separate access permissions on each of them. 

     Frank

[Piotr Kaminski]

Another pattern I sometimes use is to nest the public data inside the overall private structure.  This lets you run transactions over the whole thing, and gives a tiny performance boost to privileged clients since they only need to issue one on('value') request instead of two.

    -- P.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/1729d2d8-b6aa-47b6-9778-d1987d117b8d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

  Piotr Kaminski <pi...@ideanest.com>

  "That bun is dirty.  Don't eat that bun."

[Logan Joecks]

Thanks guys! I'll be implementing one of these solutions.