* [WEB-8095] fix: scope page-version reads to the URL project (GHSA-g49r/ghcr)
ProjectPagePermission verified the caller was a member of the URL
project_id but then resolved the page by workspace + page_id only, and
PageVersionEndpoint filtered versions the same way. A member of one
project could read the page versions of a public page belonging to a
different project in the same workspace via that project's URL
(GHSA-g49r-p85q-qq2w / GHSA-ghcr-frqr-6pqr).
- Scope the page lookup in ProjectPagePermission to projects__id via the
ProjectPage M2M (both app/ and utils/ copies); deny when the page does
not belong to the URL project.
- Scope PageVersionEndpoint list/detail querysets to
page__projects__id=project_id (defense in depth); distinct() on the
list guards against active + soft-deleted ProjectPage duplicates.
- Add contract regression tests (fail-before verified).
Co-authored-by: Plane AI <noreply@plane.so>
* [WEB-8095] fix: require active ProjectPage link when scoping pages to a project
Address CodeRabbit + Copilot review on #9380: projects__id=project_id
matched even soft-deleted ProjectPage links, so a page removed from the
project (link revoked) would still pass, and the version detail get()
could raise MultipleObjectsReturned on active + soft-deleted rows.
Put both conditions on the same project_pages relation in one filter so
they match a single ProjectPage row that is active:
project_pages__project_id=project_id + project_pages__deleted_at__isnull
=True. The partial-unique constraint (project, page WHERE deleted_at IS
NULL) then guarantees at most one row, so get() stays unambiguous and the
list needs no distinct(). Add a revoked-link regression test.
Co-authored-by: Plane AI <noreply@plane.so>
* [WEB-8095] fix: distinct() on page-version detail lookup as a MultipleObjectsReturned guard
Address CodeRabbit review on #9380. The active-link filter already keeps
the page__project_pages join to a single row via the partial-unique
constraint, but add distinct() to the detail get() as defense in depth so
the join can never surface MultipleObjectsReturned (a 500) even if that
invariant were ever violated.
Co-authored-by: Plane AI <noreply@plane.so>
---------
Co-authored-by: Plane AI <noreply@plane.so>
The SAFE_METHODS branch of ProjectMemberPermission filtered ProjectMember by
workspace only (no project_id), so any workspace user who was a member of *some*
project could pass the check for a project they were not in. Consumers then
returned project-scoped data:
- v1 ProjectMemberListCreateAPIEndpoint.get -> full project roster
(GHSA-w2vf-m9x9-mvmc)
- app DeployBoardViewSet.list -> project publish configuration (identical
app-copy sibling)
Add project_id=view.project_id to the SAFE_METHODS filter in both copies
(utils + app), mirroring the non-safe branch and ProjectEntityPermission. A
non-member now receives 403.
Contract regression tests cover both endpoints: a workspace user who is a
member of a different project is denied (403) on a foreign project, while an
active member of the target project is allowed. Fail-before verified (both
denied cases leak 200 without the fix).
Co-authored-by: Plane AI <noreply@plane.so>
GHSA-rmmf-rj2q-3rrg: save_user_data() was unconditionally setting
is_active=True on every login, silently reactivating any admin-deactivated
account. Fix: add an early guard in complete_login_or_signup() that raises
USER_ACCOUNT_DEACTIVATED (5019) before any session or save logic if the
existing user's is_active=False. Remove the is_active=True assignment and
the associated user_activation_email call from save_user_data(). Also
remove the now-unused user_activation_email and base_host imports.
GHSA-wjgv-cq7w-258v: WorkspaceOwnerPermission in both app/permissions/
and utils/permissions/ was filtering WorkspaceMember without is_active=True,
allowing a deactivated workspace owner/admin to retain API access. Add
is_active=True to both copies to match every other permission class.
Co-authored-by: Plane AI <noreply@plane.so>
