Biscuit v5 #217
Draft
Biscuit v5 #217
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
set the block version when using 3rd party blocks
* feat: add `reject if` This acts like the opposite of `check if`: if there is a match, then authorization fails. Using `reject if` raises the block version to 5 * fix: run rustfmt on datalog/mod.rs The file contained trailing slashes that made rustfmt crash --------- Co-authored-by: Geoffroy Couprie <[email protected]>
…220) Context: biscuit-auth/biscuit#130 This introduces the `HeterogeneousEqual` and `HeterogeneousNotEqual` operations, which will not return an error when their operands have different types, contrary to the existing `Equal` and `NotEqual` operations. **breaking change**: this does not change the execution of existing tokens, but changes the text representation of the language. `Equal` was `==` and is now `===`, `NotEqual` was `!=` and is now `!==`, `HeterogeneousEqual` is `==` and `HeterogeneousNotEqual` is `!=` --------- Co-authored-by: Geoffroy Couprie <[email protected]> Co-authored-by: Clément Delafargue <[email protected]>
CodSpeed Performance ReportMerging #217 will not alter performanceComparing Summary
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #217 +/- ##
==========================================
+ Coverage 67.27% 68.66% +1.39%
==========================================
Files 25 25
Lines 5274 5655 +381
==========================================
+ Hits 3548 3883 +335
- Misses 1726 1772 +46 ☔ View full report in Codecov by Sentry. |
This introduces the closure operations to the Biscuit language, first with the `.all()` and `.any()` operations to add conditions on the elements of a set. It is now possible to use expressions with the following format: ``` check if [1,2,3].all($p -> $p > 0); check if [1,2,3].any($p -> $p > 2); ``` Co-authored-by: Geoffroy Couprie <[email protected]>
While the incrementing integer for version numbers is fine for the protobuf encoding, it has been a headache when communicating with other people. A `major.minor` scheme seems better for understanding, and helps communicate the scope of changes a bit better. There was a bug in version checks that relied on `BISCUIT_MAX_VERSION` to check the version for specific features. This does not play well with version upgrades. So this commit fixes both issues: - use explicit 3.x version number for datalog features - use explicit version numbers for feature checks, instead of relying on the max version It also improves a bit on some error messages that were a bit cryptic, by clearly specifying the version in which specific features were implemented.
Major minor datalog versions
Datalog parameters are managed lazily: upon building a rule, referenced parameter are collected in a map. Setting them only updates the map, and the actual AST is only updated as needed (such as in Display impls, or when converting to datalog data structures). Expressions used to be linear, but closures introduced the possibility of recursive expressions, so the code inside closure bodies was ignored both when collecting parameters, and when applying them. This caused an issue because some parts of the code assume that unbound parameters are handled beforehand, and panic upon encountering them.
…losures fix: recursively collect and apply parameters in closures
In #231 the v3/4/5 naming was removed, in favor of v3.0/3.1/3.2/3.3. A few functions were forgotten in this renaming.
fix: left over renaming after #231
feat: add `.type()` unary method
This adds support for the array and map types, supporting more structured datalog terms, that we can generate from JSON data and explore through datalog expressions. The map type allows integers strings and parameters as key. This tries to enforce that all array elements are of the same type, but this is not very strict at the moment, it does not look at lower levels of composite types.
**breaking changes**:
- in the Datalog language, sets will now be delimited
by '{' and '}' instead of '[' and ]'. Arrays are now delimited by '['
and ']'
- parameter names now need to start with a letter
---------
Co-authored-by: Clement Delafargue <[email protected]>
* more explicit test assert * update run limits
add samples for typeof on array / map
The breaking change in syntax for sets made this sample use arrays instead of sets, raising the minimal version
fix biscuit 3.1 and 3.2 samples
It is not v5 blocks, it’s v6 blocks, and other v6 samples don’t mention the block version (samples will later be split by minimum datalog version)
…mple fix heterogeneous testcase and rebuild samples
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR holds the upcoming changes for the v5 format: