docs: define authorization schema discovery - #423
Conversation
|
Thanks for the pull request, @mariajgrimaldi! This repository is currently maintained by Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review. 🔘 Get product approvalIf you haven't already, check this list to see if your contribution needs to go through the product review process.
🔘 Provide contextTo help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:
🔘 Get a green buildIf one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green. DetailsWhere can I find more information?If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources: When can I expect my changes to be merged?Our goal is to get community contributions seen and reviewed as efficiently as possible. However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:
💡 As a result it may take up to several weeks or months to complete a review and merge your PR. |
rodmgwgu
left a comment
There was a problem hiding this comment.
Looking good, just a couple of points to discuss.
|
|
||
| * An application can ship authorization definitions with its code. | ||
| * Tutor and other deployment systems use the same mechanism to discover and load the definitions. | ||
| * Source information remains consistent across container. |
There was a problem hiding this comment.
nit: "containers" instead of "container"
| #. Removed applications | ||
| ======================= | ||
|
|
||
| When an application is disabled or removed, the next deployment removes the static definitions that came only from that application. If users are assigned to one of its roles, deployment stops and reports those assignments so that an operator can remove them or move the users to another role. Shared definitions remain available when another application still provides them. |
There was a problem hiding this comment.
One thing I think we need to define:
What happens if, for example, we add "app-b" and "app-c" to a site, where app-c extends app-b roles. But then at a later time, app-b get's removed. What happens with this dependency?
My first thought is that this should also stop the deployment and error out a missing dependency.
There was a problem hiding this comment.
Thanks for raising this!
Yes! I also think we should offer these alternatives: 1. error by default 2. allow for removal only if configured (as we defined for role_extensions in a previous ADR)
BryanttV
left a comment
There was a problem hiding this comment.
Thanks! I just want to clarify a few things
|
|
||
| An application contributes one or more authz schema resources through a Python entry point defined by ``openedx-authz``. Discovery resolves those resources with ``importlib.resources`` and returns all contributions in a defined order, since Python package discovery order may vary. | ||
|
|
||
| For example, a ``course_authoring`` package can register ``course_authoring.authz:get_schema_resources`` and return ``authz/course_roles.authz.yaml`` and ``authz/course_permissions.authz.yaml``. |
There was a problem hiding this comment.
This example makes me wonder. Is a single file proposed that contains both roles/role extensions and permissions/permission categories? Or would they be two separate files? Or would both options be valid?
There was a problem hiding this comment.
I don't think it should matter, the authz library should load all the registered resources and apply the extensions. I could change this so the example points to a single file and we can work retroactively in the reference folder to include real examples of how this would look.
There was a problem hiding this comment.
I changed it! I'll also add a short code example to illustrate
| #. Python entry point and package resources | ||
| =========================================== | ||
|
|
||
| An application contributes one or more authz schema resources through a Python entry point defined by ``openedx-authz``. Discovery resolves those resources with ``importlib.resources`` and returns all contributions in a defined order, since Python package discovery order may vary. |
There was a problem hiding this comment.
Should we define the entry point name right away? I'm thinking of authz.schema or something similar 🤔
There was a problem hiding this comment.
That would make sense! I'll add the decision to this section
|
|
||
| An application contributes one or more authz schema resources through a Python entry point defined by ``openedx-authz``. Discovery resolves those resources with ``importlib.resources`` and returns all contributions in a defined order, since Python package discovery order may vary. | ||
|
|
||
| For example, a ``course_authoring`` package can register ``course_authoring.authz:get_schema_resources`` and return ``authz/course_roles.authz.yaml`` and ``authz/course_permissions.authz.yaml``. |
There was a problem hiding this comment.
What should happen if, for example, the get_schema_resources function throws an exception? Does the discovery stop, or is it reported as an isolated failure of that app and it continues with the rest?
There was a problem hiding this comment.
Thank you for raising this! Since we're doing this during runtime, I think for correctness and auditability of the schema maybe we should fail and maybe allow for a different behavior?
b75eb99 to
5d42335
Compare
5d42335 to
5483288
Compare
5483288 to
11b6b03
Compare
11b6b03 to
8454483
Compare
8454483 to
0d57b94
Compare
Description
Applications need a standard way to ship authz schema files with their code, and deployment must find the same definitions in Tutor, native deployments, and local development. Hardcoded filesystem paths would make discovery depend on a particular installation layout.
This ADR uses a Python entry point and package resources to discover schemas during deployment. It also records portable source information for each contribution and defines how the deployment command handles schemas from applications that have been removed.
Merge checklist:
Check off if complete or not applicable: