0

We are running a project which contains some maps.

We have this under the node:

root.maps //object

It is a list of maps, in case some are private and some are public. Which is under the node:

root.maps.$mapId.config.isPrivate //boolean
root.maps.$mapId.config.uid //string

Now we have a problem. We listen on the maps node for changes, but we want only to return the public nodes, and the private nodes of the user.

So we added rules but it does not seem to work. The maps are either all displayed or none. When we try to set a restriction on a map itself it does not work.

Now after some searching on the internet we read that in order to manage the security rules well the private and public maps should be moved to private or public nodes.

So like this

root.maps.private.$mapId.uid
root.maps.public.$mapId.uid

Which I can't believe is true. In order to change this boolean value, we have to move the complete node from the public to the private node.

Is this really how this database should work? It does not sound logical at all to me.

Is there any other way on how to filter this data based on rules (maps should not be known to the client, client side filtering is not an option)

And if the really strange case of moving complete nodes based on changing boolean values is really true.

What is the idea behind it? This can't be true right?

AL.
  • 36,815
  • 10
  • 142
  • 281
BarryOSeven
  • 11
  • 2
  • 2
    Without seeing your rules and the code that fails it will be hard to be certain. But it sounds like you're trying to filter the items in a list, which is not possible with Firebase Database security rules. See [the documentation on "rules are not filters"](https://firebase.google.com/docs/database/security/securing-data#rules_are_not_filters), this [original answer](http://stackoverflow.com/a/14298525/209103) or one of the many [answers since then](http://stackoverflow.com/search?q=%5Bfirebase%5D+rules+are+not+filters). – Frank van Puffelen Jan 23 '17 at 13:28
  • There is not much to display other than these abstract concepts. The links you provided are the answers I was refering too. They are saying we need a public and a private branch and put id's in it or remove it from it if it changes. I keep thinking this is a weird way to use databases, might be my nostalgia but the flow firebase has just sucks. You first make the database, you be sure that everything works and in the end it screws you over because the rules lack every bit of logic from an ancient perspective. Thanks anyway, ill skip it for now. – BarryOSeven Jan 23 '17 at 13:40
  • 1
    Filtering firebase is anyways not very performant. I recommend using it in combination with elasticsearch.. it works like a charm – Himanshu Chaudhary Jan 23 '17 at 19:01
  • As @FrankvanPuffelen mentioned, rules are not filters and while it's tempting to try to use them as such, its not a good solution. Filtering your results is determined by your Firebase structure - some structures lend themselves better to being filtered than others. You question states *we want only to return the public nodes, and the private nodes of the user.*. Can you clarify that requirement as if you are returning both, what are you wanting to filter? – Jay Jan 23 '17 at 19:16
  • In the beginning of the project we created the abstract object "Map". Maps could been read by everybody right then, they we stored under: root.maps. Now there was a requirement change, some of them should be made private. So we added a isPrivate boolean to the object itself. But in order to secure this well, the database needs to do the filtering because if the clients does it, all information will be at the client which should not happen. So there is a division. Some of them are public and some of them are private so some of them should not show up at the client. – BarryOSeven Jan 24 '17 at 10:43
  • So the security implementation is giving us serious troubles right now because in order to secure this well many code needs to be rewritten and changed. We will overcome ;) but I think it's something which should not happen. Security is something one likes to do in the end, with this model you should start off with security in mind because in the end it will require one to overtrow the model completely – BarryOSeven Jan 24 '17 at 10:47
  • The issue is really the implementation of the Firebase structure, not so much the security rules. For example, when you say *So we added a isPrivate boolean to the object itself*, it's probably not the best way to make that data private as the client (code-wise) would need access to that node to determine if it's readable or not. It could be secured with rules but that may be an all or none issue. A way to better do this is to set up a node of 'authorized uid's' and have the rules check to see if a uid is in that list before allowing access to the node with the data in it. – Jay Jan 24 '17 at 18:35
  • That would be a great idea, thank you – BarryOSeven Jan 25 '17 at 09:58

0 Answers0