5 ms·

There is something i don‘t understand about Firestore: If you use the web client your javascript code is directly communicating with the firestore database, you

by tpetry 8y ago

There is something i don‘t understand about Firestore: If you use the web client your javascript code is directly communicating with the firestore database, you have no control about some user specific limits. How do you prevent some rogue actor from effectively doing billions of reads or writes. With server side logic you can implement rate limits but not with a fire store web client. The only thing you can do is to limit your monthly budget? So one bad guy can burn all your money for a month without you having any possibility of limiting it?

dantiberian 8y ago
I assume that there would be some rate limiting and anti-abuse measures here, like most Google products have. It’s a good question though.
- badestrand 8y ago
  How would an automatic system even prevent unwanted deletion of database entries or that users access others' data? Maybe I am lacking imagination but without server-side validation the practical use cases seem very limited.
  - paxy 8y ago
    Think of it as an API layer and database baked into one.
  - jmvoodoo 8y ago
    Cloud firestore supports placing rules on the database to prevent access by users that aren't authorized. You can independently control get, write, update, list, etc. The way the rules work can sometimes be irritating, in particular for list queries, but they do work. In terms of rate limiting the only one I'm aware of is writes to a single record are rate limited. This impacts normal development when making counters that need to be updated, which leads to an odd "sharded counter" model.
  - gnode 8y ago
    It has this: https://firebase.google.com/docs/firestore/security/rules-structure https://firebase.google.com/docs/firestore/security/rules-st...
    - badestrand 8y ago
      Ah, interesting, so you basically put the server side validation code into the database. And nice, it can even handle authentication.
  - dillondoyle 8y ago
    When I last looked at Firebase, it seems like they bake auth into database so in this case a user is limited on what data they can read, like a select where uuid === uuid https://firebase.google.com/docs/database/security/user-security https://firebase.google.com/docs/database/security/user-secu.... And I assume non-authenticated read requests don't have access to everything...
gnode 8y ago
This is a good question. I think a more general feature it's lacking is auditing (as far as I've been able to find), from which you could judge whether a user was abusive and revoke permissions. There's profiling tools, which you may be able to hack together something for auditing if you were so inclined: https://firebase.google.com/docs/database/usage/profile https://firebase.google.com/docs/database/usage/profile
manigandham 8y ago
In these kind of systems, your app users also become database users and effectively each visitor gets their own token to access the database. You then add rules to limit users so they can only read/write their own data. This works fine for many simpler scenarios and avoids the need for a backend completely, with the potential risk for overuse. If you need more control and protection then you should have a backend layer to get the data server-side.
- maldeh 8y ago
  By "In these kind of systems, your app users also become database users", do you mean by RBAC or some other session-based control on the backend, or does Firestore perform some intelligent user entity resolution I'm missing? As far as I can tell, any naked frontend-only client serving content without its own access management sounds quite open to a single bad actor spawning a large number of sessions on the same host, and on a small number of distributed hosts, to eat up all available resources. I'm not inclined to ever trust a number of users behaving nicely at n>100 personally. Given that Firestore appears to advocate "serverless" client-driven applications, unless there's some foolproof DDoS mitigations I'm finding it a hard sell, especially on the whole "if you need more control and protection, do X" argument - you rarely need that until somebody straight-up exploits you, and when you do, you're not going to be particularly sympathetic towards Google's marketing speak.
  - thecatspaw 8y ago
    You can require login for read/write access
olliepop 8y ago
I struggled with this. We implemented Firestore (successfully) in a production mobile game for the real-time chat and configuration aspects. The SDK WebSocket implementation for real-time updates was a huge factor here. At the time we were using the Firestore beta, Security Rules were also very poorly documented with no tooling apart from the editor (beta product - I know, I know). Ultimately we found several vulnerabilities in our own implementation of Firestore that were difficult or practically impossible to resolve on our end. The workaround was to communicate with Firestore only by using the admin SDK. I still completely vouch for Firestore and Firebase as a product.
dfischer 8y ago
You have control over user specific limits. You can use Firestore Security rules, and if that doesn't do it you can create a service that runs server-side code to do what you want and then have the client hit that service.
- amelius 8y ago
  > You can use Firestore Security rules I think the main problem is that they bolted security (access control) on top of their existing system, rather than make it an integral part of the design.
  - itcmcgrath 8y ago
    We built it specifically for Cloud Firestore and as an integral part of the system from the beginning. We always like to hear where we can do better to help prioritize the next set of improvements, and would love to know what gives you the impression of being bolted on.
    - iambateman 8y ago
      I’m building an app at the moment with Firestore and 99% of it is amazing or better. It’s a really fantastic tool and y’all are enabling people like me who are less adept to make good stuff. So thanks! Two minor notes (one on security rules): (1) in the tutorials I’ve seen, the security rules have received little attention and the documentation I’ve read is a bit confusing about the spectrum of possibilities for security rules. Tbh, I’ve punted security rules altogether until I’m closer to “beta ready” as opposed to writing them along the way. I suspect this is bad practice but haven’t found a better way. Much of this is my fault lol. (2) “presence” systems still require the use of Real-Time DB. +1 feature request to support user connect/disconnect events in Firestore.
      - puf 8y ago
        firebaser here Completely agreed that we should do a better job in documenting the security rules. They're very powerful, but a huge paradigm shift for most developers, one that is too easily ignored (at your own and your user's peril). We've already released a bunch of improvements on the documentation, and continue to work on adding new documentation, video tutorials, and console improvements. Please keep telling us where we can/should improve security rules further though. And yes, also agreed on needing a solution for presence system, either in Firestore itself, or separate from it.
abraham 8y ago
Limiting writes would be fairly easy. You could have an onWrite Function trigger[0] that writes activity to a rate limit Firestore document. When new write requests come in, the Firestore rules can read that rate limit docuemnt and decide if the particular write should be allowed or not. Limiting reads is interesting. I think generally the idea is data is cheap enough that most people don't have to worry about it. If you do you could gate access through an API in a Function. [0] https://firebase.google.com/docs/functions/firestore-events https://firebase.google.com/docs/functions/firestore-events [1] https://firebase.google.com/docs/firestore/security/rules-conditions#access_other_documents https://firebase.google.com/docs/firestore/security/rules-co...

by tpetry 8y ago

dantiberian 8y ago

I assume that there would be some rate limiting and anti-abuse measures here, like most Google products have. It’s a good question though.

badestrand 8y ago
How would an automatic system even prevent unwanted deletion of database entries or that users access others' data? Maybe I am lacking imagination but without server-side validation the practical use cases seem very limited.
- paxy 8y ago
  Think of it as an API layer and database baked into one.
- jmvoodoo 8y ago
  Cloud firestore supports placing rules on the database to prevent access by users that aren't authorized. You can independently control get, write, update, list, etc. The way the rules work can sometimes be irritating, in particular for list queries, but they do work. In terms of rate limiting the only one I'm aware of is writes to a single record are rate limited. This impacts normal development when making counters that need to be updated, which leads to an odd "sharded counter" model.
- gnode 8y ago
  It has this: https://firebase.google.com/docs/firestore/security/rules-structure https://firebase.google.com/docs/firestore/security/rules-st...
  - badestrand 8y ago
    Ah, interesting, so you basically put the server side validation code into the database. And nice, it can even handle authentication.
- dillondoyle 8y ago
  When I last looked at Firebase, it seems like they bake auth into database so in this case a user is limited on what data they can read, like a select where uuid === uuid https://firebase.google.com/docs/database/security/user-security https://firebase.google.com/docs/database/security/user-secu.... And I assume non-authenticated read requests don't have access to everything...

gnode 8y ago

This is a good question. I think a more general feature it's lacking is auditing (as far as I've been able to find), from which you could judge whether a user was abusive and revoke permissions. There's profiling tools, which you may be able to hack together something for auditing if you were so inclined: https://firebase.google.com/docs/database/usage/profile https://firebase.google.com/docs/database/usage/profile

manigandham 8y ago

In these kind of systems, your app users also become database users and effectively each visitor gets their own token to access the database. You then add rules to limit users so they can only read/write their own data. This works fine for many simpler scenarios and avoids the need for a backend completely, with the potential risk for overuse. If you need more control and protection then you should have a backend layer to get the data server-side.

maldeh 8y ago
By "In these kind of systems, your app users also become database users", do you mean by RBAC or some other session-based control on the backend, or does Firestore perform some intelligent user entity resolution I'm missing? As far as I can tell, any naked frontend-only client serving content without its own access management sounds quite open to a single bad actor spawning a large number of sessions on the same host, and on a small number of distributed hosts, to eat up all available resources. I'm not inclined to ever trust a number of users behaving nicely at n>100 personally. Given that Firestore appears to advocate "serverless" client-driven applications, unless there's some foolproof DDoS mitigations I'm finding it a hard sell, especially on the whole "if you need more control and protection, do X" argument - you rarely need that until somebody straight-up exploits you, and when you do, you're not going to be particularly sympathetic towards Google's marketing speak.
- thecatspaw 8y ago
  You can require login for read/write access

olliepop 8y ago

I struggled with this. We implemented Firestore (successfully) in a production mobile game for the real-time chat and configuration aspects. The SDK WebSocket implementation for real-time updates was a huge factor here. At the time we were using the Firestore beta, Security Rules were also very poorly documented with no tooling apart from the editor (beta product - I know, I know). Ultimately we found several vulnerabilities in our own implementation of Firestore that were difficult or practically impossible to resolve on our end. The workaround was to communicate with Firestore only by using the admin SDK. I still completely vouch for Firestore and Firebase as a product.

dfischer 8y ago

You have control over user specific limits. You can use Firestore Security rules, and if that doesn't do it you can create a service that runs server-side code to do what you want and then have the client hit that service.

amelius 8y ago
> You can use Firestore Security rules I think the main problem is that they bolted security (access control) on top of their existing system, rather than make it an integral part of the design.
- itcmcgrath 8y ago
  We built it specifically for Cloud Firestore and as an integral part of the system from the beginning. We always like to hear where we can do better to help prioritize the next set of improvements, and would love to know what gives you the impression of being bolted on.
  - iambateman 8y ago
    I’m building an app at the moment with Firestore and 99% of it is amazing or better. It’s a really fantastic tool and y’all are enabling people like me who are less adept to make good stuff. So thanks! Two minor notes (one on security rules): (1) in the tutorials I’ve seen, the security rules have received little attention and the documentation I’ve read is a bit confusing about the spectrum of possibilities for security rules. Tbh, I’ve punted security rules altogether until I’m closer to “beta ready” as opposed to writing them along the way. I suspect this is bad practice but haven’t found a better way. Much of this is my fault lol. (2) “presence” systems still require the use of Real-Time DB. +1 feature request to support user connect/disconnect events in Firestore.
    - puf 8y ago
      firebaser here Completely agreed that we should do a better job in documenting the security rules. They're very powerful, but a huge paradigm shift for most developers, one that is too easily ignored (at your own and your user's peril). We've already released a bunch of improvements on the documentation, and continue to work on adding new documentation, video tutorials, and console improvements. Please keep telling us where we can/should improve security rules further though. And yes, also agreed on needing a solution for presence system, either in Firestore itself, or separate from it.

abraham 8y ago

Limiting writes would be fairly easy. You could have an onWrite Function trigger[0] that writes activity to a rate limit Firestore document. When new write requests come in, the Firestore rules can read that rate limit docuemnt and decide if the particular write should be allowed or not. Limiting reads is interesting. I think generally the idea is data is cheap enough that most people don't have to worry about it. If you do you could gate access through an API in a Function. [0] https://firebase.google.com/docs/functions/firestore-events https://firebase.google.com/docs/functions/firestore-events [1] https://firebase.google.com/docs/firestore/security/rules-conditions#access_other_documents https://firebase.google.com/docs/firestore/security/rules-co...