fix: Opening link for Packager or SBOMs related to Licenses in new window ignores the filter#922
Merged
stanislavsemeniuk merged 2 commits intoguacsec:mainfrom Feb 16, 2026
Conversation
…ponent and now onSigninCallback also remembers search params from URL
Contributor
Reviewer's guide (collapsed on small PRs)Reviewer's GuidePreserves and restores URL search parameters across OIDC sign-in redirects so that filters and query-based state are not lost when opening the app or specific routes in a new tab, by including the search string in url_state and navigating back using a structured location object. Sequence diagram for OIDC sign-in redirect with preserved search paramssequenceDiagram
actor User
participant Browser
participant OidcProvider
participant AuthService
participant IdentityProvider
participant AppRoutes
User->>Browser: Open /path?filter=abc in new tab
Browser->>OidcProvider: Initialize application
OidcProvider->>AuthService: Check isAuthenticated
AuthService-->>OidcProvider: isAuthenticated = false
OidcProvider->>AuthService: signinRedirect(url_state = window.location.pathname + window.location.search)
AuthService->>IdentityProvider: Redirect to login with state containing fullPath
User->>IdentityProvider: Authenticate
IdentityProvider->>Browser: Redirect back with state including "/path?filter=abc"
Browser->>OidcProvider: Initialize with callback URL
OidcProvider->>Browser: Read window.location.search
OidcProvider->>Browser: new URLSearchParams(window.location.search)
OidcProvider->>Browser: Extract fullPath from state
OidcProvider->>Browser: Split fullPath into pathname and search
OidcProvider->>AppRoutes: navigate({ pathname, search }, { replace: true })
AppRoutes-->>Browser: Render /path?filter=abc with filters preserved
Browser-->>User: Show page with correct filters applied
Flow diagram for OidcProvider URL state handlingflowchart TD
A[Start OidcProvider] --> B{isAuthenticated?}
B -- yes --> C[Render children normally]
B -- no --> D{isLoading or error?}
D -- yes --> C
D -- no --> E[Call auth.signinRedirect]
E --> F[Set url_state = window.location.pathname + window.location.search]
F --> G[Browser redirects to IdentityProvider]
subgraph CallbackHandling
H[OIDC callback received] --> I[onSigninCallback invoked]
I --> J[Create URLSearchParams from window.location.search]
J --> K[Read state param and split on ';']
K --> L[Extract fullPath from state or use '/']
L --> M{fullPath contains '?'}
M -- yes --> N[Split fullPath into pathname and search]
M -- no --> O[Set pathname = fullPath, search = empty]
N --> P[Normalize search to '?query' or empty]
O --> P
P --> Q[AppRoutes.navigate with pathname & search, replace true]
Q --> R[Render target route with preserved search params]
end
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Hey - I've left some high level feedback:
- When reconstructing
fullPath, consider using theURLAPI ornew URL(relative, base)to parse pathname/search/hash instead of manually splitting on?, which is brittle if query-like content ever appears in other parts of the path. - Since
stateis now used to reconstruct a full path, it would be safer to validate that the parsedpathnameis a same-origin relative path (e.g., starts with/and isn’t an absolute URL) before passing it toAppRoutes.navigateto avoid any potential open-redirect style issues. - The current change preserves
window.location.searchbut still drops any hash fragment; if deep-linking relies on URL hashes, you may want to includewindow.location.hashinurl_stateand restore it ononSigninCallbacksimilarly to the search params.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- When reconstructing `fullPath`, consider using the `URL` API or `new URL(relative, base)` to parse pathname/search/hash instead of manually splitting on `?`, which is brittle if query-like content ever appears in other parts of the path.
- Since `state` is now used to reconstruct a full path, it would be safer to validate that the parsed `pathname` is a same-origin relative path (e.g., starts with `/` and isn’t an absolute URL) before passing it to `AppRoutes.navigate` to avoid any potential open-redirect style issues.
- The current change preserves `window.location.search` but still drops any hash fragment; if deep-linking relies on URL hashes, you may want to include `window.location.hash` in `url_state` and restore it on `onSigninCallback` similarly to the search params.Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #922 +/- ##
==========================================
- Coverage 64.98% 64.02% -0.97%
==========================================
Files 195 195
Lines 3339 3341 +2
Branches 751 753 +2
==========================================
- Hits 2170 2139 -31
- Misses 872 914 +42
+ Partials 297 288 -9 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
carlosthe19916
approved these changes
Feb 16, 2026
Collaborator
carlosthe19916
left a comment
carlosthe19916
left a comment
There was a problem hiding this comment.
LGTM! Thanks @stanislavsemeniuk
carlosthe19916
changed the title
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.
This pr is trying to resolve this issue: https://issues.redhat.com/browse/TC-3294
The main problem was that whenever we open any url of tpa application in a new tab, in moment of initialization of an app inside OidcProvider any search params were ignored and cleared. Even when you tried to open something simple like
http://localhost:3000?test=123it ended up looking like thishttp://localhost:3000/.So i added search params inside navigation inside OidcProvider.
I am not sure it this was made by accident and it is a bug or it is something that was made like this for reason but i couldn't find any possible pitfalls.
Summary by Sourcery
Bug Fixes: