Skip to content

fix(location): authorize endpoint compat detail routes via product/finding - #16377

Merged
Maffooch merged 1 commit into
devfrom
cmm/friendly-edison-m9e3qq
Oct 17, 2026
Merged

Maffooch merged 1 commit into
devfrom
cmm/friendly-edison-m9e3qq

Conversation

@Maffooch

Copy link
Copy Markdown
Contributor

Description

Fixes an HTTP 500 on the V3 endpoint-compatibility detail routes (GET /api/v2/endpoints/<id>/ and GET /api/v2/endpoint_status/<id>/, active when V3_FEATURE_LOCATIONS is enabled).

These routes are served by the compatibility viewsets in dojo/location/api/endpoint_compat.py, whose rows are LocationProductReference / LocationFindingReference join rows. The shared UserHasLocationRefPermission object-permission class passed the raw join row straight to the authorization layer. user_has_permission resolves products, findings and locations, but not these join rows, so the object-permission check raised NoAuthorizationImplementedError → 500 for any authenticated, authorized, non-superuser reaching a detail route.

The fault was masked in two ways, which is why it surfaced only in production as a recurring 500:

  • a superuser short-circuits the object-permission check and never reaches the unhandled branch;
  • an unauthorized user is filtered out by the viewset queryset and gets a 404 before the check runs.

So only a plain member of the row's product — the common case — hit it.

Fix

Resolve the join row to its product (LocationProductReference) or finding (LocationFindingReference) before calling check_object_permission, mirroring the existing native Location(Product|Finding)ReferencePermission classes. This hands the authorization layer an object it already knows how to authorize, so the same change fixes both the open-source and Pro authorization implementations with no change needed on the Pro side. No migration and no model change.

Test results

Added unittests/test_v3_endpoint_compat_api_authz.py, which drives both detail routes as an authorized non-superuser product member:

  • before the fix both routes return 500 (NoAuthorizationImplementedError);
  • after the fix both return 200.

Verified locally against Postgres on dev. The new tests plus the existing endpoint/location authorization suites (test_v3_endpoint_route_authz, test_apiv2_endpoint_deprecation_contract, test_apiv2_endpoint, test_endpoint_status_cross_product_authz, test_location_finding_reference_authz, test_v3_location_reference_authz) all pass. Ruff clean.

Documentation

No documentation change — this restores the documented behavior of existing routes; no new feature or setting.

Checklist

  • Rebased against the latest dev.
  • Submitted against the dev branch.
  • Ruff compliant.
  • Python 3.13 compliant.
  • No model changes / no migration.
  • Added unit tests.

Generated by Claude Code

…nding

The V3 /api/v2/endpoints/<id>/ and /api/v2/endpoint_status/<id>/ routes are
served by the compatibility viewsets over LocationProductReference /
LocationFindingReference join rows. Their shared UserHasLocationRefPermission
handed the raw join row to the authorization layer, which resolves products,
findings and locations but not these join rows, so the object-permission check
raised NoAuthorizationImplementedError (HTTP 500) for every authorized
non-superuser reaching a detail route. A superuser short-circuits the check and
an unauthorized user is filtered out by the viewset queryset, which is why the
fault stayed hidden until a plain product member opened a detail route.

Resolve the row to its product (LocationProductReference) or finding
(LocationFindingReference) before the check, mirroring the native
Location(Product|Finding)ReferencePermission classes so both the OSS and Pro
authorization layers receive an object they already handle. Add a regression
test covering both detail routes for an authorized non-superuser.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UNVqniCYTXeyUZJoLF7BT2
@Maffooch
Maffooch requested a review from blakeaowens as a code owner October 16, 2026 12:31
@Maffooch Maffooch added this to the 3.4.200 milestone Oct 16, 2026 — with Claude
@Maffooch
Maffooch added this pull request to the merge queue Oct 17, 2026
Merged via the queue into dev with commit 8768b53 Oct 17, 2026
48 checks passed
@Maffooch
Maffooch deleted the cmm/friendly-edison-m9e3qq branch October 17, 2026 16:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants