There's no possible way to limit shallow requests

[zuruko]

Hi, I'm building and admin interface for firebase realtime DB. 

As an admin interface, I do not have any prior knowledge of what the structure of the data will be. So some nodes would have extremely large subtrees that can not be practically loaded into a response in a reasonable amount of time / memory. 

Right now Firebase's REST API allow me to limit either the length or the depth of the query but not both at the same time. When I use the limit* queries and restrict the number of children that gets returned, it will still try to return the entire depth of the subtree and I can't guarantee that any of the children will not have massive subtrees. If I use the shallow param, I can't guarantee that any of the node will not have millions of keys and still blow up my request. 

In fact, this is an issue in firebase's own admin console. I do not dare to expand one my subtrees with even just thousands of children. It'll take forever to load and becomes pretty useless. 

Is there a way to paginate / limit the number of keys return in a "shallow" request? 

Thanks!

[Tyler Rockwood]

Hello,

There is no current way to use any other query parameters with shallow GET requests at this time.

-Tyler

[zuruko]

Is there anything on the roadmap for this? It would be really helpful and make a lot of sense to be able to treat a shallow query the same as a regular query.

Also, as I'm trying to build an admin interface. I would like to use the firebase web client in serviceAccount mode. But when I initialize firebase app using serviceAccount credentials, it errors out saying that it's only supported in a Node.js environment

```

1. code:"app/sa-not-supported"
2. message:"Firebase: Initializing the Firebase SDK with a service account is only allowed in a Node.js environment. On client devices, you should instead initialize the SDK with an api key and auth domain (app/sa-not-supported)."

```

However, I do see other people are able to build admin interfaces using the web client (albeit in electron). How are they getting around this? Is this purely due to the fact that it's allowed to run in Electron environment as well?

https://github.com/codefoxes/firebase-admin/blob/master/js/connection.js#L53

Thanks

[Jacob Wenger]

I can't quite answer your first question about the REST API, but I can comment on your second question about using a service account from the client. To be completely honest, it just has not been a high priority for us and it is hard to avoid people mis-using it. It is a fairly niche use case and there are very rare cases where you ever want to actually send a service account to your browser. Obviously, there are some, and I'm not saying yours is not one of them, but we have to think about the collective sum of our users and their use cases. Many, many more people which will abuse a feature like this than will use it properly. I can't tell you the number of times I've been helping a developer debug an issue only to discover they included a secret or service account private key on their public website.

You do have some strong workarounds for this problem though. You can build an Electron app (as you mentioned), which is not restricted by this. Or you can proxy requests through a custom server running the Admin Node.js SDK. Lastly, you can just set up your security rules to allow expanded access to your Database or Storage data for administrators (which you can track, for example, in a /admins/$uid node or via an admin claim in a custom token).

Your request for a client-side version that allows service accounts is heard loud and clear, but I wouldn't expect to see it in the near future. I am definitely internalizing your feedback though, so thanks for your comments about it.

Cheers,

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-talk+unsubscribe@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/c795b96c-f0ea-4b15-8c66-b11c22845d4a%40googlegroups.com.

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

[Tyler Rockwood]

As for the REST API expanding Shallow GET requests, there is nothing on the roadmap at the time, sorry.

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.

[zuruko]

Thanks a lot! Yup I think proxying is probably the best solution here.

On Friday, March 17, 2017 at 12:34:04 PM UTC-7, Jacob Wenger wrote:

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.

[Michael Romero]

This is an old post, but I was resurrecting some old code and ran into this exact error.  The solution was to remove the 'credential', field from my firebase dictionary entry so that I was only specifying my firebase 'apiKey', 'authDomain', 'databaseURL', and 'storageBucket'. I was previously also specifying my 'projectId' and 'credential' (the credential was what was using the service account) - removing these allowed everything to go.