-
Notifications
You must be signed in to change notification settings - Fork 67
Admin API to dynamically set policy data #4115
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
Conversation
Deploying matrix-authentication-service-docs with
|
| Latest commit: |
6a37fdf
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://9de2a56f.matrix-authentication-service-docs.pages.dev |
| Branch Preview URL: | https://quenting-dynamic-policy-data.matrix-authentication-service-docs.pages.dev |
15a4828 to
c8a33f0
Compare
|
A build for this PR at commit 6eca7b1 has been created through the Z-Build-Workflow label by sandhose. Docker image is available at:
Pre-built binaries are available through the workflow run artifacts. |
|
A build for this PR at commit 1a87716 has been created through the Z-Build-Workflow label by sandhose. Docker image is available at:
Pre-built binaries are available through the workflow run artifacts. |
reivilibre
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seems good, though not sure about the overkillness of the schema?
Fixes #3993
This adds a way to dynamically set the policy data through an admin API call.
This data is then stored in the database, and merged with the policy data from the configuration file.
Note that it merges both objects, concatenates arrays, overridding any values with the ones from the dynamic data.
We keep an history in the database of the policy data, so that when looking at the logs, we can look which 'version' of the policy data was used during policy evaluation.
When setting the policy data through the API, it validates it and will refuse anything that it can't load in the WASM module. It will immediately load it in the current instance; other instances load it regularly (every minute) from the database, so there is maximum a 1 minute lag between the admin API being called and it being effective on all workers.