[FC-0118] docs: add ADR for introducing a row-level security layer#38354
Open
Abdul-Muqadim-Arbisoft wants to merge 1 commit intoopenedx:docs/ADRs-axim_api_improvementsfrom
Conversation
Introduce an architectural decision record that standardizes how list endpoints separate three concerns: endpoint access (DRF permission classes), record visibility (RLS queryset scoping), and user-driven filtering (django-filter). This complements the existing bridgekeeper ADR (0003) by defining the view-layer pattern that any permission engine plugs into, rather than prescribing a specific engine. Includes code examples using CourseOverview, a reusable RLSQuerysetMixin, and a rollout plan targeting course listing, enrollment, and certificate endpoints first.
Abdul-Muqadim-Arbisoft
requested review from
Faraz32123,
feanil and
taimoor-ahmed-1
Contributor
bradenmacdonald
left a comment
bradenmacdonald
left a comment
There was a problem hiding this comment.
Should this be an update to OEP-66 instead of an ADR?
How does this integrate with Casbin?
When the user requests a single object from a GET endpoint, does this still use a filter that could involve complicated/slow logic to construct, or does it just query the permissions of that one single object? i.e. is getting a single object more like "list all the courses the user is allowed to see and then select one" or is it like "check if the user is allowed to see course X".
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds ADR proposing a reusable row-level security layer to standardize how Open edX list endpoints handle record visibility, replacing the current ad-hoc pattern of inline has_access checks mixed with endpoint guards and user-driven filtering.
Currently, ~150 has_access call sites and helpers like has_studio_read_access(), has_course_author_access(), and get_course_with_access() are applied inline across views in contentstore, enrollments, discussion, and course blocks APIs, tangling three distinct concerns into single blocks of view logic. This makes access behavior inconsistent across endpoints, difficult to audit, and hard to test in isolation. This ADR documents the decision to separate every list endpoint into three layers, endpoint access via DRF permission classes, record visibility via RLS-scoped querysets in get_queryset(), and user-driven filtering via django-filter, backed by a shared RLSQuerysetMixin and pluggable RLSPolicy interface. The rollout targets high-impact ORM-backed endpoints first (course listing, enrollment, certificates) with in-memory filtering fallback for modulestore-backed endpoints like Course Blocks. This ADR is complementary to the existing bridgekeeper ADR (0003) , it defines the architectural pattern that any permission engine plugs into, rather than prescribing a specific engine.
issue:#38282