0

TL;DR: Is there any security concern to let clients of the database know the uid of other clients? For example: Can an auth object be created with a known uid to query the database like another user?

I need superusers to define default values inside their respective node. Then, regular users (that belongs to a superuser "group") can define its own values, but if there's a key that's not defined by the user, the client of that user node can fallback to the superusers default values.

But to accomplish it, I need the users to know the uid of their respective superuser.

A sample database would be:

{
   "superusers": {
      "K32kd2dD8F9vf9...": {
         "key1": "value1",
         "key2": "value2",
         "key3": "value3"
      }
   },
   "users": {
      "T53ggft56Df52G...": {
         "key2": "myvalue2",
         "key3": "myvalue3",
         "superuser": "K32kd2dD8F9vf9..."
      }
   }
}

In this case, the user "T53ggft56Df52G..." defines its own values for "key2" and "key3", but not for "key1". So, any client that reads the "T53ggft56Df52G..." node can read the "superuser" value and fallback to "K32kd2dD8F9vf9..." and retrieve the default "key1" value.

Update

As for Jay's comment. I, actually, have planned superusers to create users. But since that's not possible anymore what comes to mind is to implement a membership request system to accomplish something similar.

To better explain my use case, here's a new JSON example that shows the actual data I need to handle:

{
   "restaurant_franchise": {
      "K32kd2dD8F9vf9...": {
         "info": ...,
         "menu": {
            "awesome burguer": { ... }, //recipe, cost, sizes...
            "amazing burguer": { ... },
            "incredible burguer": { ... }
         },
         "members": { "T53ggft56Df52G...": true },
         "membership_requests": { ... }
      }
   },
   "restaurant": { // the actual establishment
      "T53ggft56Df52G...": {
         "info": { ... },
         "menu": {
            "amazing burguer": { ... }, //this one has less sizes available
            "incredible burguer": { ... } //this other one costs more
         },
         "default_to": "K32kd2dD8F9vf9..."
      }
   }
}

Here, the client that reads the menu of "T53ggft56Df52G..." can obtain default values from missing keys. In this case, "awesome burguer" is missing from the restaurant because it changes nothing from the original values defined in "K32kd2dD8F9vf9...".

nyrd
  • 478
  • 3
  • 9
  • As a followup comment: I am not sure of your use case, but if your 'superusers' can create other users, it's going to be a problem. Firebase has eliminated (with 3.x) the ability for users to create other users without de-authenticating themselves. Just a heads up in case you were/are have that. – Jay Jun 11 '16 at 12:38
  • Knowing the user's uid does not allow you to impersonate that user. For example, my Stack Overflow ID is 209103, yours is 4778855, Jay's is 2851937. None of that is enough information to hijack an account. See [Is auth.uid a shared secret?](http://stackoverflow.com/questions/37221760/firebase-is-auth-uid-a-shared-secret/37222341#37222341) – Frank van Puffelen Jun 11 '16 at 15:07
  • Aside from that, I don't understand your use-case. Can you update the JSON to use easier to follow property names, add some code of an operation that the client has to be able to do and code of an operation that should not be possible. With those it'll be a lot clearer what you're trying and you'll have a better chance at getting help. – Frank van Puffelen Jun 11 '16 at 15:09

0 Answers0