You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Suppose I have the following business rule to enforce:
Allow only users whose User entity contains the property admin with a true value to write any Employee entity instance (everyone else gets read-only access).
(Ignore for a moment that this could be implemented with a JWT claim. Sometimes JWT claims are not a feasible solution, or something more dynamic is required since JWTs get reused and don’t refresh immediately.)
Or this:
Disallow the creation of an Employee entity instance if its manager property does not refer to another existing Employee instance.
Or this:
Allow no more than n Contact entity instances per user (where a running count is held in a different per-user entity, and n is held in another entity associated with the user’s payment tier)
These examples are enforcing data integrity and permission using existing entity data as a guide. The developer should be able to read any entity instance in the entire project for use in evaluating the policy.
What I am suggesting here is equivalent to Firestore security rules providing syntax to get an existing document. They only allow single document access by ID (no queries) and only up to 10 max per evaluation. These are reasonable limits with performance and scalability in mind.
There could be a special API for this exposed through ReqContext (rather than the existing TS entity API) that makes the read operation synchronous (so that the policy function need not be async).
The text was updated successfully, but these errors were encountered:
Suppose I have the following business rule to enforce:
(Ignore for a moment that this could be implemented with a JWT claim. Sometimes JWT claims are not a feasible solution, or something more dynamic is required since JWTs get reused and don’t refresh immediately.)
Or this:
Or this:
These examples are enforcing data integrity and permission using existing entity data as a guide. The developer should be able to read any entity instance in the entire project for use in evaluating the policy.
What I am suggesting here is equivalent to Firestore security rules providing syntax to get an existing document. They only allow single document access by ID (no queries) and only up to 10 max per evaluation. These are reasonable limits with performance and scalability in mind.
There could be a special API for this exposed through ReqContext (rather than the existing TS entity API) that makes the read operation synchronous (so that the policy function need not be async).
The text was updated successfully, but these errors were encountered: