Repository navigation
Conversation
openedx-webhooks
added
the
open-source-contribution
|
Thanks for the pull request, @efortish! 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. |
| request.user, | ||
| permissions.CAN_VIEW_THIS_CONTENT_LIBRARY, | ||
| ) | ||
| if not user_has_course_permission_from_query_param( |
There was a problem hiding this comment.
Is this a decorator or a utility function? I ask because it is implemented in the decorator modules so I'd expect it could be used as a decorator. Although I see we've been using the pattern of defining non-decorator helpers in that module.
There was a problem hiding this comment.
It's a plain helper, not a decorator. Kept it in this module because that's where the other course-permission helpers already live (user_has_course_permission, get_course_key). Happy to split decorators from plain utilities into their own file if you'd rather.
|
|
||
|
|
||
| @skip_unless_cms | ||
| @override_settings(CORS_ORIGIN_WHITELIST=[]) # For some reason, this setting isn't defined in our test environment? |
There was a problem hiding this comment.
I don't think this is the correct approach. Can you please attach the error that's raised without this setting? Thanks!
There was a problem hiding this comment.
You're right, copying the workaround was the wrong call. Root cause: embed_block_view reads settings.CORS_ORIGIN_WHITELIST directly with no fallback, and cms/envs/test.py never defined it (lms/envs/test.py does). Fixed the actual setting in cms/envs/test.py and dropped the override_settings from both test classes in this file.
|
I was testing the frontend part and i just want to flag one thing that I just noticed and that is the assets from that particular library still returning 
|
| if not user_has_course_permission_from_query_param( | ||
| request, authz_permissions.COURSES_VIEW_LIBRARY_UPDATES.identifier | ||
| ): | ||
| api.require_permission_for_library_key( | ||
| container_key.lib_key, | ||
| request.user, | ||
| permissions.CAN_VIEW_THIS_CONTENT_LIBRARY, | ||
| ) |
There was a problem hiding this comment.
The problem with this specific approach is that it grants access based solely on the user having the courses.view_library_updates permission in the course specified by the course_id query parameter, but it never verifies whether that course is actually linked to the requested library/container/block, which could lead to unintended access.
There was a problem hiding this comment.
You're right, this checked the permission but never the relationship. Fixed: the param now has to be the downstream's own usage key, I resolve its UpstreamLink and compare it against the resource being requested before granting anything. Added a regression test for this exact case (a downstream in an accessible course that's linked to something else).
There was a problem hiding this comment.
Thanks @efortish! I tested it locally, and the change looks good to me. However, one test case is failing on my end.
When I link a section/subsection/unit, Review Changes works fine, but when I link a component directly from a library, it only lets me review the new version, not the old one.
To reproduce:
- Go to a unit > Add a new component > Library Content > Add a component that is already in the library.
- Make a change to the component from the library.
- Click the sync button on the component inside the course.
Once this is resolved, could we verify that all possible use cases are working properly and list them in the PR?
|
Good catch. That one's a different beast though: the asset URL gets baked into the rendered HTML by the runtime itself (openedx_content_runtime.py), not requested by our frontend, so it needs its own fix (threading course_id through the render pipeline, plus its own UpstreamLink check on the asset endpoint). Filed it separately so it doesn't block this PR: openedx/openedx-authz#473 |
The library container and xblock embed endpoints used by the "review pending changes" modal only checked direct library permissions, so a Course Auditor (or any role holding courses.view_library_updates) got a 403 even though they should be able to review changes from their course. Accept an optional course_id query param on these three endpoints and grant access via courses.view_library_updates when it points to a course the user can review from, falling back to the existing library-level check otherwise. Same pattern already used for the sync endpoint in openedx#39009 and openedx#39055. Related to openedx/openedx-authz#441
mypy needs check_permission annotated as CheckPerm | None explicitly, since the first assignment alone made it infer plain CheckPerm. Move the embed view's authz bypass test out of test_runtime.py (a plain TestCase, missing CORS_ORIGIN_WHITELIST in the CMS test environment) into test_embed_block.py, next to the other embed view tests, using the same override_settings(CORS_ORIGIN_WHITELIST=[]) workaround already in place there for the same reason.
The course_id bypass only checked that the user held courses.view_library_updates in the given course, never that the course actually used the requested library resource. That meant holding the permission in any course was enough to read any library container or block in the system. Require the query param to be a real downstream usage key, resolve its UpstreamLink, and only grant access when that link points at the resource being requested. Same approach already used by upstream_sync_block.py/upstream_sync_container.py for the sync endpoint. Also: - add regression tests for the mismatched-downstream case and for existing library-permission callers who never pass course_id - fix cms/envs/test.py to actually define CORS_ORIGIN_WHITELIST instead of overriding it per test class, embed_block_view reads it directly with no fallback Addresses review from @mariajgrimaldi and @BryanttV.
user_has_course_permission_for_upstream imported UpstreamLink from cms.lib.xblock.upstream_sync, which import-linter's layers contract places above content_libraries, content_staging and xblock. Those apps import authz.decorators, so the import violated the contract even though it was function-local, and broke CI's Lint Python Imports job for all three. Read the downstream block's upstream field directly instead of going through UpstreamLink, and parse it with LibraryUsageLocatorV2 or LibraryContainerLocator from opaque_keys, which isn't subject to the layers contract. Updated the tests to match: they now use real library keys and mock modulestore().get_item() to return an object with a plain upstream attribute, instead of mocking UpstreamLink.
Under ModuleStoreTestCase, ATOMIC_REQUESTS wraps each request in a savepoint nested inside the test's own outer transaction. When a view returns a DRF PermissionDenied, DRF marks that savepoint for rollback, and response middleware that runs a query afterward (lang_pref's process_response, checking the user's language preference) hits TransactionManagementError because the savepoint hasn't been rolled back yet. Wrap the requests that intentionally get a 403 in self.allow_transaction_exception(), the same pattern already used in test_clipboard.py for the same kind of test.
Function-level imports hid the dependency until the function ran and could produce import-order surprises later. Moving opaque_keys locators and xmodule.modulestore to the top is safe here: opaque_keys is already imported at the top of this module, xmodule is available in both LMS and CMS, other core apps already import modulestore at module level, and lint-imports reports the same dependency graph either way since grimp counts function-level imports too. Update test_decorators.py to patch the new module-level name (openedx.core.djangoapps.authz.decorators.modulestore) and move the local ItemNotFoundError import in test_downstream_not_found_denies to the top of the test module.
2ea06f6 to
f38325c
Compare
The param was never actually a course id, it's always been the downstream block's usage key (the decorator derives the course from it after verifying the upstream link), so the name was misleading to API consumers. Matches the frontend-app-authoring PR's own rename of the prop from courseId to downstreamBlockId for the same reason. No call site passes param_name explicitly, so this only changes the function's default and the tests that exercise it directly.
Matches the backend rename in openedx/openedx-platform#39107: the param was never actually a course id, it's always been the downstream block's usage key, so course_id was a misleading name for API consumers on both ends.
|
Renamed the |
This branch has not been deployed
6 participants
Description
The library container endpoints and the xblock embed endpoint used by the "review pending changes" modal (opened from a course unit when a library-sourced component has updates available) only checked direct library permissions. That means a Course Auditor, or anyone else holding
courses.view_library_updatesat the course level, gets a 403 trying to review changes even though they can view everything else about that course.This adds an optional
course_idquery param to the three affected endpoints:GET /api/libraries/v2/containers/<container_id>/GET /api/libraries/v2/containers/<container_id>/children/GET /xblocks/v2/<usage_key>/embed/<view_name>/When
course_idis present and the requesting user holdscourses.view_library_updatesin that course, access is granted without requiring direct library permissions. Without it, or if the check fails, the existing library-level permission check runs exactly as before, so nothing changes for callers that don't pass it.This is the same approach already used for the sync endpoint in #39009 and #39055.
The companion frontend change (threading the course id through to these three calls) is in openedx/frontend-app-authoring#3251.
Related to openedx/openedx-authz#441
Testing
user_has_course_permission_from_query_paramhelper.course_id, and 200 oncecourse_idpoints at their course.Deadline
None