tju-yxq opened a new issue, #5245:
URL: https://github.com/apache/rocketmq-dashboard/issues/5245
## Problem
When a login session expires mid-work, the operator is dumped on the login
page and — after re-authenticating — lands on the home page, not on the page
they were working on. Every mid-task context is lost: the alert feed with its
filters, the message query they were rebuilding, the instance they had
selected. In a long incident session with a short `sessionTimeout`, this
happens repeatedly.
## Current behavior and reproduction
1. Sign in and navigate to a deep page, e.g. `/ops/alerts?level=error`.
2. Let the session expire (or have the server invalidate it).
3. The next API call returns 401; the axios interceptor
(`web/src/api/client.ts`, `handleSessionUnauthorized`) clears the session and
sets `window.location.href = '/login'` — the current URL is discarded.
4. Sign in again: `LoginPage.onFinish` always `navigate('/', { replace: true
})` (`web/src/pages/login/index.tsx`), so the operator restarts from home and
must rebuild the deep link by hand.
## Proposed behavior
- On a 401, the redirect to `/login` carries the page the operator was on as
an encoded `?redirect=` query parameter (path plus query string). An expired
session while already on `/login` redirects plainly, without a self-referencing
parameter.
- After a successful login, the page navigates to the sanitized `redirect`
target when one is present, and to home otherwise.
- The target is validated before use: only same-app absolute paths are
accepted — protocol-relative URLs (`//evil.example`), absolute external URLs
(`https://…`), paths without a leading slash, and backslash tricks are rejected
and fall back to home.
## Acceptance criteria
- [ ] A 401 while on `/ops/alerts?level=error` sends the browser to
`/login?redirect=%2Fops%2Falerts%3Flevel%3Derror`.
- [ ] A successful login with that `redirect` navigates back to
`/ops/alerts?level=error` (replace navigation, no back-button trap into the
login page).
- [ ] A successful login without a `redirect` parameter still navigates to
`/`.
- [ ] Protocol-relative, absolute-external, no-leading-slash and backslash
values fall back to `/`.
- [ ] Regression coverage pins the return-to-page path, the home fallback,
and each rejected redirect shape; the existing login tests (in-flight guard,
validation, default navigation) keep passing.
## Importance
Should-have. This is standard session-expiry ergonomics for an operations
console: the workaround is re-navigating and re-entering filters by hand after
every expiry, which during an incident (many browser tabs, each on a different
page) means several minutes of lost context per re-login. The risk surface is
small and well understood: a one-line change in the 401 handler plus a
sanitized read-back in the login flow.
## Duplicate check
Searched open and closed issues/PRs for `"return url"`, `"redirect back"`,
`"after login" redirect`, `"current page" login`, and `session expired
redirect`. The closest matches are #715 (closed: redirect to login after logout
— the direction of the redirect, not the return), #716/#717 (closed: preserve
sessions for public auth failures) and #664/#668 (closed: honor configurable
login protection in routing). None of them covers returning to the originating
page after re-authentication.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
