Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stronger guarantees on library types #248

Open
divarvel opened this issue Nov 26, 2024 · 0 comments
Open

Stronger guarantees on library types #248

divarvel opened this issue Nov 26, 2024 · 0 comments

Comments

@divarvel
Copy link
Collaborator

Currently, the library allows representing a few objects (blocks, datalog fragments) that are not correct, according to the spec. This pushes a rather defensive programming model where a lot of actions can return errors and in some cases redundant checks.

Another issue is the redundancy between the biscuit_auth and biscuit_parser Builder types, which require duplicate validation logic.

An example is the validate_variables check:

  • the parser checks for free variables in rules heads and expressions when constructing a value by parsing a string
  • the builder checks only for free variables in rules heads
  • the datalog module checks for free variables when importing rules from a token (but not when adding them to an authorizer)

One solution would be to be explicit about guarantees each type must support, and to enforce them via smart constructors. Raw constructors would be private, so each mode would be responsible for its own consistency.
Additionally, merging the biscuit_parser and biscuit_auth::builder types would remove redundancy and ensure the checks would be consistent for datalog parsed from a string or built through helpers
Same for the datalog modules, they should enforce the same checks when parsing a token or a snapshot (since the protobuf encoding is quite permissive).

This would make error reporting way simpler in the datalog engine itself, by removing a lot of issues in advance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant