biscuit-auth/biscuit
1
1
Fork 0
mirror of https://github.com/biscuit-auth/biscuit.git synced 2024-10-06 02:27:33 +03:00
Code Issues Packages Projects Releases Wiki Activity

Fix a few minor typos

Browse Source
This commit is contained in:
John Wood 2021-10-31 10:28:42 -07:00 committed by GitHub
parent 7bd158a3ed
commit 6169fbde0d
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
SUMMARY.md
View File

@ -141,7 +141,7 @@ It has the following base types (for elements inside of a fact):
- boolean (true or false)
- set: a deduplicated list of values, that can be of any type except variables or sets
Rules can contain expressions that evaluate variable defined in the other
Rules can contain expressions that evaluate variables defined in the other
predicates. An expression must always evaluate to a boolean. If it returns
false, the rule evaluation fails. The following rule will generate a fact only
if there's a `file` fact and its value starts with `/folder/`:
@ -194,7 +194,7 @@ or by the verifier, **they cannot be added by attenuating the token**.
The validation in Biscuit relies on a list of allow or deny policies, that are
evaluated after all of the checks have succeeded. Like checks; they are queries
that must find a matching set of fact to succeed. If they do not match, we try
that must find a matching set of facts to succeed. If they do not match, we try
the next one. If they succeed, an allow policy will make the request validation
succeed, while a deny policy will make it fail. If no policy matched, the
validation will fail.
@ -219,7 +219,7 @@ deny if true
The verifier will generate a list of facts indicating revocation identifiers for
the token. They uniquely identify the token and each of its parent tokens through
a serie of SHA256 hashes. That way, if a token is revoked, we will be able to
a series of SHA256 hashes. That way, if a token is revoked, we will be able to
refuse all the tokens derived from it.
To check revocation status, we can either:
@ -274,7 +274,7 @@ table that already contains values like `#authority` or `#operation`). It can
contain facts, rules and checks. A block contains:
- `symbols`: a block can introduce new symbols: these symbols are available in the current block, _and the following blocks_. **It is not possible to re-declare an existing symbol**.
- `context`: free form text used either for documentation purpose, or to give a hind about which facts should be retrieved from DB
- `context`: free form text used either for documentation purpose, or to give a hint about which facts should be retrieved from DB
- `facts`: each block can define new facts (but only `authority` can define facts mentioning `#authority`)
- `rules` each block can define new rules (but only `authority` can define rules deriving facts mentioning `#authority`)
- `checks` each block can define new checks (queries that need to match in order to make the biscuit valid)
@ -293,7 +293,7 @@ current_time(#ambient, 2020-11-17T12:00:00+00:00);
The verifier would also be able to load authorization data from its database,
like ownership information: `owner(#authority, "user_1234", "bucket_1234")`,
`owner(#authority, "user_1234", "bucket_5678")` `owner(#authority, "user_ABCD", "bucket_ABCD")`.
In practice,this data could be filtered by limiting it to facts related to
In practice, this data could be filtered by limiting it to facts related to
the current ressource, or extracting the user id from the token with a query.
The verifier can also load its own rules, like creating one specifying rights