Release: Merge back 3.0.1 into dev from: master-into-dev/3.0.1-3.1.0-dev#15037
Merged
Conversation
…1.0-dev Release: Merge back 3.0.0 into bugfix from: master-into-bugfix/3.0.0-3.1.0-dev
* update SAML documentation * change hash code language * update universal parser docs * add default perms info * update uparser docs
Removes [esbuild](https://github.com/evanw/esbuild). It's no longer used after updating ancestor dependency [vite](https://github.com/vitejs/vite/tree/HEAD/packages/vite). These dependencies need to be updated together. Removes `esbuild` Updates `vite` from 7.3.2 to 8.0.16 - [Release notes](https://github.com/vitejs/vite/releases) - [Changelog](https://github.com/vitejs/vite/blob/main/packages/vite/CHANGELOG.md) - [Commits](https://github.com/vitejs/vite/commits/v8.0.16/packages/vite) --- updated-dependencies: - dependency-name: esbuild dependency-version: dependency-type: indirect - dependency-name: vite dependency-version: 8.0.16 dependency-type: direct:development ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
…15023) * fix(findings): resolve single-location filter against Location model Filtering the findings list by a single location via ?endpoints=<id> returned HTTP 404. ListFindings.add_breadcrumbs looked the id up against the legacy Endpoint model with get_object_or_404, but the Endpoint->Location migration leaves dojo_endpoint empty, so every such link (generated by the Endpoints page in dojo/templates/dojo/url/list.html) raised Http404 and 404'd the entire findings list. Resolve the id against Location instead, mirroring dojo.url.ui.views.process_endpoint_view. The findings filter already maps the endpoints parameter to locations__location, so only the breadcrumb lookup was stale. Adds a regression test covering the 200 response, the "Vulnerable Endpoints" breadcrumb label, and the preserved 404 for a missing location. Authored by T. Walker - DefectDojo * harden(findings): scope single-location breadcrumb lookup to authorized locations Addresses the DryRun Security review on this PR. The breadcrumb resolved a user-supplied location id via get_object_or_404 without permission scoping, which could disclose the existence/URL of a location the user cannot access (read-only, breadcrumb-only info disclosure). Resolve the id through get_authorized_locations("view") so the lookup 404s for both missing and unauthorized ids. The findings data itself was already scoped via get_authorized_findings("view"); this closes the breadcrumb gap and aligns the lookup with the project's location authorization model. Adds a regression test asserting an unauthorized user receives 404. Authored by T. Walker - DefectDojo * fix(findings): gate single-location breadcrumb lookup on V3_FEATURE_LOCATIONS The breadcrumb lookup in ListFindings.add_breadcrumbs resolved the single `?endpoints=<id>` filter value against Location unconditionally. But the findings `endpoints` filter itself is V3-gated (dojo/filters.py): under V3 it resolves against Location, otherwise against the legacy Endpoint model. With locations disabled (a supported rollback, DD_V3_FEATURE_LOCATIONS=False) the Location table is empty, and the legacy Endpoints page still links to open_findings/verified_findings with `?endpoints=<endpoint_id>`, so every valid legacy endpoint id 404'd the findings list — trading the original V3 404 for a legacy-mode one. Resolve the id against the same model the filter used, keeping the authorization scoping in both branches (get_authorized_locations under V3, get_authorized_endpoints otherwise) so the breadcrumb still cannot disclose an object the user may not view. Add a legacy (skip_unless_v2) counterpart test class mirroring the V3 cases: single-endpoint filter returns 200, sets the "Vulnerable Endpoints" breadcrumb, and 404s for missing/unauthorized endpoint ids. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Cody Maffucci <46459665+Maffooch@users.noreply.github.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
… point new-UI banner at 3.3.0 (#15024) * fix: prevent 500 on org/product delete with deprecated endpoints under V3_FEATURE_LOCATIONS Deleting a Product_Type/Product that still has legacy Endpoint rows returned a 500 when V3_FEATURE_LOCATIONS is enabled: Django's delete machinery hydrates the cascade-related Endpoint rows via Model.from_db(), but Endpoint.__init__ raises NotImplementedError under V3 unless _allow_v3_init is set. Wrap the affected delete paths in the existing Endpoint.allow_endpoint_init() context manager (the convention already used by delete_product): - UI delete_product_type: the sync delete and the NestedObjects preview collect - API ProductViewSet.destroy / ProductTypeViewSet.destroy (sync branch) - the shared DeletePreviewModelMixin.delete_preview (covers all viewsets) Add unittests/test_delete_with_endpoints_v3.py covering UI + API delete and delete-preview for Product_Type, Product, Engagement, Test, and Finding under V3_FEATURE_LOCATIONS=True with an Endpoint/Endpoint_Status in the tree. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix: update docstrings for clarity in TestDeleteWithEndpointsV3 * fix: point new-UI adoption banner at 3.3.0 release The banner referenced the 2.62.0 release, which no longer exists after the renumbering from the 2.x line to 3.x. Per the repo's release milestones, the September 8th minor release is now 3.3.0, so update the version string to match. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Release: Merge release into master from: release/3.0.1
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
4 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.
Release triggered by
Maffooch