Hacker News Reader

Comment by breatheoften | Hacker News Reader

What's the short summary of how the authorization system works for this?

One of the things I find quite nice about firebase is the quite powerful separation between the logic of data retrieval / update and the enforcement of access policy -- if you understand it you can build the prototype on a happy path with barely any authorization enforcement and then add it later and have quite complete confidence that you aren't leaking data between users or allowing them to change something they shouldn't be able to. Although you do need to keep the way this system works in mind as you build and I have found that developers often don't really grasp the shape of these mechanisms at first

From what I can tell -- the instant system is different in that the permission logic is evaluated on the results of queries -- vs firebase which enforces whether the query is safe to run prior to it even being executed ...

View on HN

> What's the short summary of how the authorization system works for this?

We built a permission system on top of Google's CEL [1]. Every object returned in a query is filtered by a 'view' rule. Similarly, every modification of an object goes through a 'create/update/delete' rule.

The docs: https://www.instantdb.com/docs/permissions

The experience is similar to Firebase in three ways:

1. Both languages are based on CEL 2. There's a distinct separation between data retrieval and access policy 3. You can start on a happy path when developing, and lock down later.

AFAIK, Firebase Realtime can be more efficient, as it can tell if a permission check has passed statically. I am not sure if Firestore works this way. We wanted to be more dynamic, to support more nuanced rules down the road (stuff like 'check this http endpoint if an object has permissions'). We took inspiration Facebook's 'EntPrivacy' rules in this respect.

> Every object returned in a query is filtered by a 'view' rule. Similarly, every modification of an object goes through a 'create/update/delete' rule.

Is that efficient for queries that return many rows but each user only has access to a few?

Is there a specific reason to not use something like postgresql RLS that would do the filtering within the database where indexes can help?

Yes, reading the essay, that seems like the only "red flag" to me, the rest sound like a dream db.

Not being able to leverage permission rules to optimize queries (predicate pushdown) seems like too big a compromise to me. It would be too easy to hit pathological cases, and the workaround would probably be something akin to replicating the permission logic in every query. Is there any plans to improve this?

Yes, in the near future we plan to convert CEL expressions to where clauses, which we attach to queries. This would push permissions to the query level, like postgres RLS.

Great, and congrats on the launch!

While it seems inflexible at first this system is surprisingly capable and provides great DX, one of the best things about working with firestore.

> Firebase Realtime can be more efficient, as it can tell if a permission check has passed statically. I am not sure if Firestore works this way.

Firestore's rules are also able to prove before the query runs if the query will only return data that the user has access to according to the rules. That's a pretty important property that "rules aren't filters" because it prevents bad actors from DDOSing your system. My former colleague wrote about this: https://medium.com/firebase-developers/what-does-it-mean-tha...

Reply on news.ycombinator.com