[
https://issues.apache.org/jira/browse/AMBARI-26623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jialiang Cai updated AMBARI-26623:
----------------------------------
Description:
h2. Problem
The React frontend does not yet provide a reliable authentication and
application-shell boundary equivalent to the classic Ember UI. Authentication,
server-session recovery, protected routing, landing-page selection, session
lifecycle handling, persisted user settings, and global shell behavior are
either incomplete or split across unrelated components.
The current implementation selects the login page from a one-time
{{window.location.hash}} snapshot and mounts the router only after cluster
initialization. An unauthenticated request to a protected URL can therefore
remain on the loading screen. The {{/main}} and {{/installer}} trees do not
share an authentication guard, authorization failures can still establish a
client-side session, and usernames are URL-encoded by both the context and API
layers.
This issue covers the complete non-Metrics Auth/Shell module defined by the
classic UI baseline. Metrics pages are not part of the scope; an existing
Metrics route may only be referenced as a landing route.
h2. Scope
* Establish a single router-driven boundary between public login routes and the
authenticated application.
* Support local Basic authentication, Knox/external JWT redirection,
{{/login/local}}, redirect-loop protection, and server-authenticated session
recovery through the {{User}} response header.
* Load the user, privileges, and authorizations before declaring the session
authenticated. Treat any required authorization-loading failure as a failed
session.
* Load and display the login message of the day when enabled, while allowing
login to continue when the setting is absent, invalid, or unavailable.
* Select the initial destination for installed clusters, incomplete
installation, users with only View privileges, and Ambari administrators with
no cluster.
* Preserve and restore only normalized same-origin application paths. Reject
protocol-relative, absolute, and login targets.
* Consolidate logout, local-state cleanup, polling teardown, and server logoff
behavior.
* Add the authenticated-session keep-alive lifecycle.
* Load global shell state in the correct order and avoid initializing full
cluster operations for View-only users.
* Apply authentication and authorization checks independently to navigation
visibility and direct route access.
* Implement document-title updates, cached About information, and actionable
global loading/error states.
* Implement administrator and read-only inactivity timeouts, the 60-second
warning, continue/sign-out actions, activity monitoring, and wizard/upgrade
exclusions.
* Implement the Experimental page, persisted support flags, and Reset UI States
with its separate persisted-data permission.
* Complete User Settings for background-operation preference, timezone, and
current cluster/View privileges while preserving the classic UI's distinct
visibility, handler, and persistence permission checks.
* Block the Installer on a packaged web-client/server version mismatch when a
client version is available.
h2. Classic UI Baseline
The acceptance baseline is
{{docs/frontend-refactor/ember-baseline/01-auth-shell.md}}, feature IDs
{{AUTH-001}} through {{AUTH-008}} and {{SHELL-001}} through {{SHELL-009}}. The
React gap analysis is recorded in
{{docs/frontend-refactor/react-current/01-auth-shell-gap.md}}.
The authoritative network comparison must include all of the following classic
contracts rather than only matching API file names:
* {{POST /api/v1/auth}}
* {{GET /api/v1/users/{userName}}} with privileges
* {{GET /api/v1/users/{userName}/authorizations}}
* {{GET /api/v1/users/{userName}/privileges}}
* {{GET /api/v1/clusters}} for authentication, cluster state, and keep-alive
* {{GET /api/v1/settings/motd}}
* {{GET /api/v1/logout}}
* {{GET /api/v1/services/AMBARI/components/AMBARI_SERVER}} for properties and
version
* {{GET}} and {{POST /api/v1/persist[/key]}}
* Ambari Admin View browser navigation
h2. Acceptance Criteria
* Visiting {{/}}, {{/main/...}}, or {{/installer/...}} without an authenticated
server session routes to {{/login}} and safely preserves an eligible target.
* A valid local login sends UTF-8 Basic credentials and URL-encodes the
username exactly once at the URL boundary.
* User data, privileges, and authorizations must all load before protected
content is rendered.
* A server-authenticated user with empty local storage is restored from the
{{User}} response header.
* Authentication responses with {{jwtProviderUrl}} redirect to the provider
with the current URL as the return target, except on {{/login/local}}; repeated
redirects stop with a visible recovery path.
* An enabled message of the day requires acknowledgment before navigation.
Missing, malformed, disabled, or failed MOTD retrieval does not block login.
* Landing behavior is correct for installed clusters, incomplete installation,
no-cluster Ambari administrators, and View-only users.
* Restored targets are internal normalized hash paths and never
protocol-relative or absolute URLs.
* Logout stops session-owned work, clears local UI state, attempts server
logoff, and reaches login even when logoff fails.
* Keep-alive starts only for an authenticated application and stops on unmount
or logout.
* Navigation visibility and direct route entry each enforce their required
permissions.
* Inactivity handling selects the administrator or read-only timeout, warns 60
seconds before expiration, supports continue/sign out, monitors the window and
accessible iframes, and skips wizard and stack-upgrade routes.
* About uses the server version cached during initialization and displays
{{N/A}} when unavailable without a click-time request.
* User Settings loads and saves background-operation preference and timezone
and displays cluster/View privileges under the documented permission gates.
* Experimental support flags can be loaded, edited, saved, canceled, and reset
under the documented permission gates.
* A packaged client/server version mismatch blocks the Installer and displays
both versions.
* Unit tests cover authentication branches, authorization failure, URL
normalization, landing selection, permission gates, logout failure, inactivity
behavior, and persisted settings.
* Runtime validation covers local Basic auth, Knox JWT, server-session
recovery, each landing mode, administrator/read-only inactivity, MOTD variants,
logout failure, Admin View navigation, and a packaged version mismatch.
h2. Out of Scope
* Metrics dashboards, charts, widgets, and Metrics data APIs.
* AngularJS Ambari Admin Console implementation. This issue only covers
navigation into the existing Admin View.
* Feature work belonging to Hosts, Services, Alerts, Upgrades, Installer steps,
Kerberos, or HA beyond the shell entry and lifecycle behavior described above.
h2. Compatibility Decisions
The React implementation must not reproduce known unsafe or failure-prone
classic UI behavior:
* Protocol-relative preferred paths such as {{//host/path}} are rejected even
though the classic prefix check accepts them.
* User and privilege data are not sufficient to establish a session when the
authorization request fails.
* A plain business-operation {{403 Forbidden}} is not treated as proof that the
authenticated session expired.
* Client logout and lifecycle teardown do not wait for successful server logoff.
* Reset UI States does not erase recoverable local wizard data until the
server-side wizard owner reset succeeds.
These are intentional compatibility corrections, not missing parity.
h2. Verification Boundary
The module is not complete based on static code or unit tests alone. All
feature IDs remain {{NEEDS_RUNTIME_VALIDATION}} until the runtime matrix in
{{docs/frontend-refactor/react-current/01-auth-shell-gap.md}} is executed
against real Ambari Server, Knox, Admin View, packaged web-client versions, and
representative permission roles.
was:
## Problem
The React frontend does not yet provide a reliable authentication and
application-shell boundary equivalent to the classic Ember UI. Authentication,
server-session recovery, protected routing, landing-page selection, session
lifecycle handling, persisted user settings, and global shell behavior are
either incomplete or split across unrelated components.
The current implementation selects the login page from a one-time
`window.location.hash` snapshot and mounts the router only after cluster
initialization. An unauthenticated request to a protected URL can therefore
remain on the loading screen. The `/main` and `/installer` trees do not share
an authentication guard, authorization failures can still establish a
client-side session, and usernames are URL-encoded by both the context and API
layers.
This issue covers the complete non-Metrics Auth/Shell module defined by the
classic UI baseline. Metrics pages are not part of the scope; an existing
Metrics route may only be referenced as a landing route.
## Scope
* Establish a single router-driven boundary between public login routes and the
authenticated application.
* Support local Basic authentication, Knox/external JWT redirection,
`/login/local`, redirect-loop protection, and server-authenticated session
recovery through the `User` response header.
* Load the user, privileges, and authorizations before declaring the session
authenticated. Treat any required authorization-loading failure as a failed
session.
* Load and display the login message of the day when enabled, while allowing
login to continue when the setting is absent, invalid, or unavailable.
* Select the initial destination for installed clusters, incomplete
installation, users with only View privileges, and Ambari administrators with
no cluster.
* Preserve and restore only normalized same-origin application paths. Reject
protocol-relative, absolute, and login targets.
* Consolidate logout, local-state cleanup, polling teardown, and server logoff
behavior.
* Add the authenticated-session keep-alive lifecycle.
* Load global shell state in the correct order and avoid initializing full
cluster operations for View-only users.
* Apply authentication and authorization checks independently to navigation
visibility and direct route access.
* Implement document-title updates, cached About information, and actionable
global loading/error states.
* Implement administrator and read-only inactivity timeouts, the 60-second
warning, continue/sign-out actions, activity monitoring, and wizard/upgrade
exclusions.
* Implement the Experimental page, persisted support flags, and Reset UI States
with its separate persisted-data permission.
* Complete User Settings for background-operation preference, timezone, and
current cluster/View privileges while preserving the classic UI's distinct
visibility, handler, and persistence permission checks.
* Block the Installer on a packaged web-client/server version mismatch when a
client version is available.
## Classic UI Baseline
The acceptance baseline is
`docs/frontend-refactor/ember-baseline/01-auth-shell.md`, feature IDs
`AUTH-001` through `AUTH-008` and `SHELL-001` through `SHELL-009`. The React
gap analysis is recorded in
`docs/frontend-refactor/react-current/01-auth-shell-gap.md`.
The authoritative network comparison must include all of the following classic
contracts rather than only matching API file names:
* `POST /api/v1/auth`
* `GET /api/v1/users/{userName}` with privileges
* `GET /api/v1/users/{userName}/authorizations`
* `GET /api/v1/users/{userName}/privileges`
* `GET /api/v1/clusters` for authentication, cluster state, and keep-alive
* `GET /api/v1/settings/motd`
* `GET /api/v1/logout`
* `GET /api/v1/services/AMBARI/components/AMBARI_SERVER` for properties and
version
* `GET` and `POST /api/v1/persist[/key]`
* Ambari Admin View browser navigation
## Acceptance Criteria
* Visiting `/`, `/main/...`, or `/installer/...` without an authenticated
server session routes to `/login` and safely preserves an eligible target.
* A valid local login sends UTF-8 Basic credentials and URL-encodes the
username exactly once at the URL boundary.
* User data, privileges, and authorizations must all load before protected
content is rendered.
* A server-authenticated user with empty local storage is restored from the
`User` response header.
* Authentication responses with `jwtProviderUrl` redirect to the provider with
the current URL as the return target, except on `/login/local`; repeated
redirects stop with a visible recovery path.
* An enabled message of the day requires acknowledgment before navigation.
Missing, malformed, disabled, or failed MOTD retrieval does not block login.
* Landing behavior is correct for installed clusters, incomplete installation,
no-cluster Ambari administrators, and View-only users.
* Restored targets are internal normalized hash paths and never
protocol-relative or absolute URLs.
* Logout stops session-owned work, clears local UI state, attempts server
logoff, and reaches login even when logoff fails.
* Keep-alive starts only for an authenticated application and stops on unmount
or logout.
* Navigation visibility and direct route entry each enforce their required
permissions.
* Inactivity handling selects the administrator or read-only timeout, warns 60
seconds before expiration, supports continue/sign out, monitors the window and
accessible iframes, and skips wizard and stack-upgrade routes.
* About uses the server version cached during initialization and displays `N/A`
when unavailable without a click-time request.
* User Settings loads and saves background-operation preference and timezone
and displays cluster/View privileges under the documented permission gates.
* Experimental support flags can be loaded, edited, saved, canceled, and reset
under the documented permission gates.
* A packaged client/server version mismatch blocks the Installer and displays
both versions.
* Unit tests cover authentication branches, authorization failure, URL
normalization, landing selection, permission gates, logout failure, inactivity
behavior, and persisted settings.
* Runtime validation covers local Basic auth, Knox JWT, server-session
recovery, each landing mode, administrator/read-only inactivity, MOTD variants,
logout failure, Admin View navigation, and a packaged version mismatch.
## Out of Scope
* Metrics dashboards, charts, widgets, and Metrics data APIs.
* AngularJS Ambari Admin Console implementation. This issue only covers
navigation into the existing Admin View.
* Feature work belonging to Hosts, Services, Alerts, Upgrades, Installer steps,
Kerberos, or HA beyond the shell entry and lifecycle behavior described above.
## Compatibility Decisions
The React implementation must not reproduce known unsafe or failure-prone
classic UI behavior:
* Protocol-relative preferred paths such as `//host/path` are rejected even
though the classic prefix check accepts them.
* User and privilege data are not sufficient to establish a session when the
authorization request fails.
* A plain business-operation `403 Forbidden` is not treated as proof that the
authenticated session expired.
* Client logout and lifecycle teardown do not wait for successful server logoff.
* Reset UI States does not erase recoverable local wizard data until the
server-side wizard owner reset succeeds.
These are intentional compatibility corrections, not missing parity.
## Verification Boundary
The module is not complete based on static code or unit tests alone. All
feature IDs remain `NEEDS_RUNTIME_VALIDATION` until the runtime matrix in
`docs/frontend-refactor/react-current/01-auth-shell-gap.md` is executed against
real Ambari Server, Knox, Admin View, packaged web-client versions, and
representative permission roles.
> Complete React authentication and application shell parity
> ----------------------------------------------------------
>
> Key: AMBARI-26623
> URL: https://issues.apache.org/jira/browse/AMBARI-26623
> Project: Ambari
> Issue Type: Bug
> Reporter: Jialiang Cai
> Priority: Major
> Time Spent: 1h
> Remaining Estimate: 0h
>
> h2. Problem
> The React frontend does not yet provide a reliable authentication and
> application-shell boundary equivalent to the classic Ember UI.
> Authentication, server-session recovery, protected routing, landing-page
> selection, session lifecycle handling, persisted user settings, and global
> shell behavior are either incomplete or split across unrelated components.
> The current implementation selects the login page from a one-time
> {{window.location.hash}} snapshot and mounts the router only after cluster
> initialization. An unauthenticated request to a protected URL can therefore
> remain on the loading screen. The {{/main}} and {{/installer}} trees do not
> share an authentication guard, authorization failures can still establish a
> client-side session, and usernames are URL-encoded by both the context and
> API layers.
> This issue covers the complete non-Metrics Auth/Shell module defined by the
> classic UI baseline. Metrics pages are not part of the scope; an existing
> Metrics route may only be referenced as a landing route.
> h2. Scope
> * Establish a single router-driven boundary between public login routes and
> the authenticated application.
> * Support local Basic authentication, Knox/external JWT redirection,
> {{/login/local}}, redirect-loop protection, and server-authenticated session
> recovery through the {{User}} response header.
> * Load the user, privileges, and authorizations before declaring the session
> authenticated. Treat any required authorization-loading failure as a failed
> session.
> * Load and display the login message of the day when enabled, while allowing
> login to continue when the setting is absent, invalid, or unavailable.
> * Select the initial destination for installed clusters, incomplete
> installation, users with only View privileges, and Ambari administrators with
> no cluster.
> * Preserve and restore only normalized same-origin application paths. Reject
> protocol-relative, absolute, and login targets.
> * Consolidate logout, local-state cleanup, polling teardown, and server
> logoff behavior.
> * Add the authenticated-session keep-alive lifecycle.
> * Load global shell state in the correct order and avoid initializing full
> cluster operations for View-only users.
> * Apply authentication and authorization checks independently to navigation
> visibility and direct route access.
> * Implement document-title updates, cached About information, and actionable
> global loading/error states.
> * Implement administrator and read-only inactivity timeouts, the 60-second
> warning, continue/sign-out actions, activity monitoring, and wizard/upgrade
> exclusions.
> * Implement the Experimental page, persisted support flags, and Reset UI
> States with its separate persisted-data permission.
> * Complete User Settings for background-operation preference, timezone, and
> current cluster/View privileges while preserving the classic UI's distinct
> visibility, handler, and persistence permission checks.
> * Block the Installer on a packaged web-client/server version mismatch when a
> client version is available.
> h2. Classic UI Baseline
> The acceptance baseline is
> {{docs/frontend-refactor/ember-baseline/01-auth-shell.md}}, feature IDs
> {{AUTH-001}} through {{AUTH-008}} and {{SHELL-001}} through {{SHELL-009}}.
> The React gap analysis is recorded in
> {{docs/frontend-refactor/react-current/01-auth-shell-gap.md}}.
> The authoritative network comparison must include all of the following
> classic contracts rather than only matching API file names:
> * {{POST /api/v1/auth}}
> * {{GET /api/v1/users/{userName}}} with privileges
> * {{GET /api/v1/users/{userName}/authorizations}}
> * {{GET /api/v1/users/{userName}/privileges}}
> * {{GET /api/v1/clusters}} for authentication, cluster state, and keep-alive
> * {{GET /api/v1/settings/motd}}
> * {{GET /api/v1/logout}}
> * {{GET /api/v1/services/AMBARI/components/AMBARI_SERVER}} for properties and
> version
> * {{GET}} and {{POST /api/v1/persist[/key]}}
> * Ambari Admin View browser navigation
> h2. Acceptance Criteria
> * Visiting {{/}}, {{/main/...}}, or {{/installer/...}} without an
> authenticated server session routes to {{/login}} and safely preserves an
> eligible target.
> * A valid local login sends UTF-8 Basic credentials and URL-encodes the
> username exactly once at the URL boundary.
> * User data, privileges, and authorizations must all load before protected
> content is rendered.
> * A server-authenticated user with empty local storage is restored from the
> {{User}} response header.
> * Authentication responses with {{jwtProviderUrl}} redirect to the provider
> with the current URL as the return target, except on {{/login/local}};
> repeated redirects stop with a visible recovery path.
> * An enabled message of the day requires acknowledgment before navigation.
> Missing, malformed, disabled, or failed MOTD retrieval does not block login.
> * Landing behavior is correct for installed clusters, incomplete
> installation, no-cluster Ambari administrators, and View-only users.
> * Restored targets are internal normalized hash paths and never
> protocol-relative or absolute URLs.
> * Logout stops session-owned work, clears local UI state, attempts server
> logoff, and reaches login even when logoff fails.
> * Keep-alive starts only for an authenticated application and stops on
> unmount or logout.
> * Navigation visibility and direct route entry each enforce their required
> permissions.
> * Inactivity handling selects the administrator or read-only timeout, warns
> 60 seconds before expiration, supports continue/sign out, monitors the window
> and accessible iframes, and skips wizard and stack-upgrade routes.
> * About uses the server version cached during initialization and displays
> {{N/A}} when unavailable without a click-time request.
> * User Settings loads and saves background-operation preference and timezone
> and displays cluster/View privileges under the documented permission gates.
> * Experimental support flags can be loaded, edited, saved, canceled, and
> reset under the documented permission gates.
> * A packaged client/server version mismatch blocks the Installer and displays
> both versions.
> * Unit tests cover authentication branches, authorization failure, URL
> normalization, landing selection, permission gates, logout failure,
> inactivity behavior, and persisted settings.
> * Runtime validation covers local Basic auth, Knox JWT, server-session
> recovery, each landing mode, administrator/read-only inactivity, MOTD
> variants, logout failure, Admin View navigation, and a packaged version
> mismatch.
> h2. Out of Scope
> * Metrics dashboards, charts, widgets, and Metrics data APIs.
> * AngularJS Ambari Admin Console implementation. This issue only covers
> navigation into the existing Admin View.
> * Feature work belonging to Hosts, Services, Alerts, Upgrades, Installer
> steps, Kerberos, or HA beyond the shell entry and lifecycle behavior
> described above.
> h2. Compatibility Decisions
> The React implementation must not reproduce known unsafe or failure-prone
> classic UI behavior:
> * Protocol-relative preferred paths such as {{//host/path}} are rejected even
> though the classic prefix check accepts them.
> * User and privilege data are not sufficient to establish a session when the
> authorization request fails.
> * A plain business-operation {{403 Forbidden}} is not treated as proof that
> the authenticated session expired.
> * Client logout and lifecycle teardown do not wait for successful server
> logoff.
> * Reset UI States does not erase recoverable local wizard data until the
> server-side wizard owner reset succeeds.
> These are intentional compatibility corrections, not missing parity.
> h2. Verification Boundary
> The module is not complete based on static code or unit tests alone. All
> feature IDs remain {{NEEDS_RUNTIME_VALIDATION}} until the runtime matrix in
> {{docs/frontend-refactor/react-current/01-auth-shell-gap.md}} is executed
> against real Ambari Server, Knox, Admin View, packaged web-client versions,
> and representative permission roles.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
