Guard context aims to provide a method to deny access (guard) based on data outside of the request context.
Currently with guards, it is only possible to access input data and token_data. Input meaning the client request body, and token data is the auth data within the biscuit token.
The ability to compare these data points with data within the service data_sources does not currently exist. This will be required as it will be an often scenario to check other data within the API to verify access.
Step 1
User defines a context list when creating a guard. This is a list of toml tables that will be used to target specific data to inject into the context of the guard to later be used.
[[entities.guards]]
name = "Permissions Error"
[[entities.guards.data_context]]
entity = "todo_access"
query = '''
{
"get_todo_accesss": {
"query": {
"user_id": token_data("user_id"),
"OR": map_input(input("query", "id")),
"edit": true
}
}
}
'''
then_msg = "You may not access this todo."
Step 2
The string query is parsed into a document and queried automatically. The result is a vector or tuple of todo_access objects. You may now access this tuple within if_expr of the guard.
The example below guards by checking each todo_access. If any of these entities do not have a created_by field that matches the user's uuid, then the request is blocked.
Guard context aims to provide a method to deny access (guard) based on data outside of the request context.
Currently with guards, it is only possible to access
input
data andtoken_data
. Input meaning the client request body, and token data is the auth data within the biscuit token.The ability to compare these data points with data within the service
data_sources
does not currently exist. This will be required as it will be an often scenario to check other data within the API to verify access.Step 1
User defines a
context
list when creating a guard. This is a list of toml tables that will be used to target specific data to inject into the context of the guard to later be used.Step 2
The string query is parsed into a document and queried automatically. The result is a vector or tuple of
todo_access
objects. You may now access this tuple withinif_expr
of the guard.The example below guards by checking each
todo_access
. If any of these entities do not have acreated_by
field that matches the user's uuid, then the request is blocked.