Centralize Authentication #9593

Ben-El · 2025-10-21T19:11:51Z

Summary

This PR refactors the WebUI authentication and navigation flow to improve reliability and consistency across login, logout, and protected routes.

Motivation

Previously, authentication state and redirects were handled in multiple components, which caused inconsistencies:

Logout didn't always clear UI state immediately.
After logging out, clicking Back in the browser displayed the previous authenticated page.
Users could access /auth/credentials after session expiry or cookie deletion until a refresh occurred.
The top navigation bar sometimes persisted or disappeared unexpectedly between auth transitions.

Etc.

Changes

Centralized authentication state via AuthContext and unified markAuthenticated / markUnauthenticated API.
Added RequireAuth to handle redirects for unauthenticated users consistently.
Updated useUser to rely on AuthContext status and cache only when authenticated.
Adjusted ConfigProvider to re-fetch configuration when user state changes.
Improved logout behavior in navbar.jsx to cleanly reset user state and redirect properly.
Removed redundant or stale local storage reads/writes.
Ensured /auth/login no longer shows when the user is already authenticated.
Guaranteed login page loads without the main navbar when logged out.

Testings

Tested manually across the following flows:

https://docs.google.com/spreadsheets/d/1-1UFTf0sbI16325zvV8FYfnoc7y8i62Mb_GbVHhXdv8/edit?gid=0#gid=0

… replace scattered authentication logic in the frontend.

…d `useAPI`, streamlining state management and simplifying configuration retrieval logic.

itaigilo

Will review this soon, but before starting -
@Ben-El can you please describe how this was tested?

This change touches a lot of sensitive flows, in different system setups.
We should be very careful with QA and testing this change, so I'd be happy for more details about it.

Also, @Annaseli may have some more context as the one recently updated these files.

itaigilo

Thanks for this massive change -
It's a very good step forward!

And I like the RequiresAuth idea, it makes a lot of sense.

Blocking mainly since the login flow is still scattered, and I think it can be further encapsulated.

And in addition:
These are maybe the most delicate flows in the WebUI, require proper testing, and are not properly covered by unit or integration tests.
Hence, IMHO the hardest part in this change is validating and QA-ing the different flows.
So please make sure that you have validated all the different flows yourself, including Cloud, Enterprise, SCIM and RBAC. According to the PR description, these are still missing.

itaigilo · 2025-10-23T06:53:27Z

webui/src/lib/auth/status.ts

In other contexts (for example configProvider.tsx) all the types are on the same file.
I think we should keep a unified pattern.

itaigilo · 2025-10-23T06:54:36Z

webui/src/lib/auth/authContext.tsx

+import React, { createContext, useContext, useMemo, useState, ReactNode } from "react";
+import { AUTH_STATUS, type AuthStatus } from "./status";
+
+type AuthContextShape = {


Nit: what's "shape"?
Let's align to AuthContextType like the other contexts we have.

itaigilo · 2025-10-23T06:58:17Z

webui/src/lib/auth/authContext.tsx

+
+function readPersistedStatus(): AuthStatus {
+    try {
+        const v = window.localStorage.getItem(STORAGE_KEY);


In api/index.js, the "user" is persisted into cache (see auth.login()).
Why do we need to save and maintain this information twice, instead of encapsulating it into a single place?

itaigilo · 2025-10-23T07:03:33Z

webui/src/lib/auth/authContext.tsx

+        status,
+        markAuthenticated: () => {
+            setStatus(AUTH_STATUS.AUTHENTICATED);
+            try { window.localStorage.setItem(STORAGE_KEY, AUTH_STATUS.AUTHENTICATED); } catch { return }


An empty catch clause is a bad practice.
At least log an error there.

itaigilo · 2025-10-23T07:06:14Z

webui/src/lib/auth/authContext.tsx

+
+type AuthContextShape = {
+    status: AuthStatus;
+    markAuthenticated: () => void;


Why do you need two functions here, and not unify to a single setStatus() function?

Or even better - maybe use useEffect() to update the localStorage as a side effect (as done in configProvider, for example)?

Since the recent changes, useEffect is no longer necessary 👍

itaigilo · 2025-10-23T07:22:26Z

webui/src/lib/components/navbar.jsx

                    auth.clearCurrentUser();
-                    window.location = logoutUrl;
+                    markUnauthenticated();
+                    if (logoutUrl !== "/logout") {


Please explain this change.

For SSO: external IdP logout must be a full navigation and replace history

itaigilo · 2025-10-23T07:27:40Z

webui/src/lib/components/requireAuth.tsx

+import {useAuth} from "../auth/authContext";
+import {AUTH_STATUS} from "../auth/status";
+
+export default function RequireAuth() {


Nit but important - should be RequiresAuth, since it's a trait of a component.

itaigilo · 2025-10-23T07:32:59Z

webui/src/lib/components/navbar.jsx

+                        return;
+                    }
+
+                    router.navigate("/auth/login", { replace: true });


I would expect a redirection to "/", and have the "/" to redirect to login if needed.
In other words, have the "/auth/login" redirection in a single place.

…e redundant `status.ts`, and rename `RequireAuth` to `RequiresAuth` for consistency.

…d `markUnauthenticated` into `setAuthStatus`, simplifying auth state management.

…alizing auth redirection logic and simplifying `login.tsx`.

…simplify child rendering logic.

… and improve readability of authentication logic.

…istency with functional component style.

Annaseli · 2025-10-23T12:06:00Z

@Ben-El @itaigilo
Hi I will review it as well a bit later today

… definitions for improved readability and organization.

…` and `setAuthStatus`, simplifying and centralizing auth logic.

…ng redundant type assertions.

… maintain consistency in authentication flow.

…avigation logic and simplify SSO handling flow.

…riable assignment.

…r cleaner and simplified authentication flow.

… destructuring for cleaner code.

… centralize redirect logic and ensure consistent handling of authenticated and unauthenticated states.

…ng redundant parentheses.

itaigilo

Great progress here @Ben-El .
I think that the architecture is now in place,
And the AuthProvider and RequiresAuth are a good solution,
And the code looks good.

Added some comments, most of them mainly revolve around cleaning up the code and readability.

In addition, please address the questions raised about testing this:
We've already had some changes in the auth area that ended up in either new production bugs or in regression. Since the changes in this PR are major, we should do the most for finding these bugs before releasing. Since these area isn't properly covered by tests, the whole testing / QA of this feature must be addressed.

itaigilo · 2025-11-03T06:45:06Z

webui/src/lib/auth/authContext.tsx

+    if (path === "/auth/login") return true;
+    return path.startsWith("/auth/oidc");


Suggested change

if (path === "/auth/login") return true;

return path.startsWith("/auth/oidc");

if (path === "/auth/login") return true;

if (path.startsWith("/auth/oidc")) return true;

return false;

Suggested change

if (path === "/auth/login") return true;

return path.startsWith("/auth/oidc");

return path === "/auth/login" || path.startsWith("/auth/oidc");

itaigilo · 2025-11-03T06:47:18Z

webui/src/lib/auth/authContext.tsx

+export const AUTH_STATUS = {
+    AUTHENTICATED: "authenticated",
+    UNAUTHENTICATED: "unauthenticated",
+    UNKNOWN: "unknown",


Maybe replace UKNOWN with PENDING?
Is there a scenario in which there's no auth request initiated?

The UNKNOWN (or PENDING) state just represents this short initial phase before that request completes, not a scenario where the request doesn't happen.

So PENDING might indeed be a clearer name, since it better conveys "auth check in progress" rather than "no request".

itaigilo · 2025-11-03T06:49:17Z

webui/src/lib/auth/authContext.tsx

+
+export const useAuth = (): AuthContextType => {
+    const ctx = useContext(AuthContext);
+    if (!ctx) throw new Error("useAuth must be used within <AuthProvider>");


Can this happen?
Isn't AuthContext initialized no matter what?

It can happen if a component using useAuth() is rendered outside the <AuthProvider>, for example in a storybook, or future refactors where a subtree is mounted separately.

The guard makes the failure explicit and easy to debug, instead of causing null errors later.
So it's a safety net, it should never trigger in production, but it's still valuable during development.

itaigilo · 2025-11-03T06:52:36Z

webui/src/lib/auth/authContext.tsx

+        auth.clearCurrentUser();
+        setStatus(AUTH_STATUS.UNAUTHENTICATED);
+        const path = window.location.pathname;
+        const next = path + (window.location.search || "") + (window.location.hash || "");


Can you please explain this hashing?
What it does and why it's needed?

The hash was Anna's suggestion, the "hash" here refers to the fragment part of the URL (the part after #, not cryptographic hashing).

We include both location.search and location.hash in the next value so that when the user gets redirected back after login, they return to the exact same URL, including query params and hash anchors.

Without this, the redirect would lose any #fragment and land the user at the base page instead.

Maybe hashing is not critical for now, but in the future we may have anchors or something, so it'll cover that too.

itaigilo · 2025-11-03T06:53:21Z

webui/src/lib/auth/authContext.tsx

+const AuthContext = createContext<AuthContextType | null>(null);
+
+const isPublicAuthRoute = (path: string) => {
+    if (path === "/auth/login") return true;


Both "/auth/login" and "/auth/oidc" should be consts.

itaigilo · 2025-11-03T07:03:12Z

webui/src/lib/components/requiresAuth.tsx

+
+    if (loading) return <Loading/>;
+    if (!user) {
+        const next = location.pathname + (location.search || "") + (location.hash || "");


Is this logic also required here (and not only in authContext)? Isn't this covered by flows catched by the context?

Good question!
The check in RequiresAuth is intentional.
While authContext handles unauthorized events globally (e.g. when a token expires or the server returns 401), RequiresAuth acts as a route guard that ensures protected pages aren’t rendered even briefly when there's no active user yet.

So the logic overlaps a bit but serves a different timing:
authContext reacts after unauthorized events, while RequiresAuth prevents access before rendering a protected route.

itaigilo · 2025-11-03T07:04:36Z

webui/src/lib/hooks/configProvider.tsx

    const pluginManager = usePluginManager();
    const {user} = useUser();
-    const [storageConfig, setConfig] = useState<ConfigContextType>(configInitialState);
+    const { response, loading, error } = useAPI(() => config.getConfig(), [user]);


itaigilo · 2025-11-03T07:28:07Z

webui/src/lib/hooks/user.jsx

I agree with @Annaseli here.
This hook is already minimal -
It can be unified with the authContext for simplicity and easier tracking.

itaigilo · 2025-11-03T07:30:05Z

webui/src/pages/auth/login.tsx

+    }
+};
+
+const getLoginIntent = (location: ReturnType<typeof useLocation>) => {


Please make this code more readable, either by extracting to sub-functions, renaming vars or adding comments.
Currently it's pretty hard to understand what it does.

itaigilo · 2025-11-03T07:32:11Z

webui/src/pages/auth/login.tsx

                            await auth.login(username, password);
-                            router.push(next || '/');
-                            navigate(0);
+                            setAuthStatus(AUTH_STATUS.AUTHENTICATED);


I suspect there might be a race condition here, between setAuthStatus and router.navigate.
How about making sure that the router.navigate will happen after the setAuthStatus?

…s`, replace `AUTH_STATUS.UNKNOWN` with `AUTH_STATUS.PENDING`, and centralize utility functions for redirection and route management.

itaigilo

@Ben-El great progress, it's almost there.

Still some questions,
And some small improvements required.

itaigilo · 2025-11-05T14:37:17Z

webui/src/lib/auth/authContext.tsx

+
+    useEffect(() => {
+        if (status === AUTH_STATUS.AUTHENTICATED) {
+            const stored = window.sessionStorage.getItem("lakefs_post_login_next");


Make lakefs_post_login_next a const common to all relevant files.

Nit: rename stored to postLoginNext or something like this.

itaigilo · 2025-11-05T14:41:56Z

webui/src/lib/utils.ts

+export const isPublicAuthRoute = (path: string) =>
+    path === ROUTES.LOGIN || path.startsWith(ROUTES.OIDC_PREFIX);
+
+export const buildNextFromWindow = () =>


I read this function a few time, and still can't figure out what it's doing,
And what "build next from window" means.

It builds the redirect target URL from window.location.
I will change to a clearer name, getCurrentRelativeUrl or something.
Thx.

itaigilo · 2025-11-05T14:42:49Z

webui/src/lib/auth/authContext.tsx

+        auth.clearCurrentUser();
+        setStatus(AUTH_STATUS.UNAUTHENTICATED);
+        const path = window.location.pathname;
+        const next = buildNextFromWindow();


Nit: this can be inside the if.

itaigilo · 2025-11-05T14:45:10Z

webui/src/lib/components/layout.tsx

-    // handle global dark mode here
-    const {state} = useContext(AppContext);
-    document.documentElement.setAttribute('data-bs-theme', state.settings.darkMode ? 'dark' : 'light')
+        document.documentElement.setAttribute(


Why this is inside useEffect?
Did you test the behavior of the Dark Mode after this change?

Good question!
I moved this logic into useEffect because setting a DOM attribute is a side-effect,
and React best practices recommend running side-effects inside useEffect rather than during render.
This ensures that the attribute is updated only when darkMode changes, and prevents double execution under strict mode.
I tested it and confirmed that dark mode toggling and initial theme load still behave as expected.

itaigilo · 2025-11-05T14:52:44Z

webui/src/lib/components/requiresAuth.tsx

+    if (loading) return <Loading/>;
+    if (!user) {
+        const next = buildNextFromWindow();
+        const url = `${ROUTES.LOGIN}?redirected=true&next=${encodeURIComponent(next)}`;


This is both hard to read and tricky to maintain.
Please use URLSearchParams() or something similar to create this in a more robust way.

itaigilo · 2025-11-05T14:53:49Z

webui/src/lib/utils.ts

+    qp: URLSearchParams
+) => {
+    const qs = qp.toString();
+    return `${loc.pathname}${qs ? `?${qs}` : ""}${loc.hash ?? ""}`;


This is both hard to read and tricky to maintain.
Please use URLSearchParams() or something similar to create this in a more robust way.

itaigilo · 2025-11-05T14:56:30Z

webui/src/lib/hooks/user.jsx

@Ben-El this comment still awaits your addressing.

itaigilo · 2025-11-05T14:58:39Z

webui/src/lib/utils.ts

+export const queryOf = (loc: ReturnType<typeof useLocation>) =>
+    new URLSearchParams(loc.search);
+
+export const isTrue = (v: string | null) => v === "true";


itaigilo · 2025-11-05T15:00:38Z

webui/src/pages/auth/login.tsx

+        u.searchParams.set("next", safeNext);
+        return u.toString();
+    } catch {
+        return `${url}${url.includes("?") ? "&" : "?"}next=${encodeURIComponent(safeNext)}`;


This is both hard to read and tricky to maintain.
Please use URLSearchParams() or something similar to create this in a more robust way.

itaigilo · 2025-11-05T15:13:31Z

webui/src/pages/auth/login.tsx

    if (setupResponse && (setupResponse.state !== SETUP_STATE_INITIALIZED || setupResponse.comm_prefs_missing)) {
-        router.push({pathname: '/setup', params: {}, query: router.query as Record<string, string>})
-        return null;
+        const qs = new URLSearchParams(location.search);


TBH, this whole login algorithm/flow is still not clear.
Note that there's been a decent amount of comments in the original code, for a reason.
Making this flow clearer will make it much easier to review.

…CurrentRelativeUrl`, unify `lakefs_post_login_next` handling, and centralize redirection utilities for consistency.

…management in `authContext`, and update components accordingly.

itaigilo

LGTM, nice work!

I hope the testing part will work out fine 🤞

itaigilo · 2025-11-06T14:13:40Z

webui/src/lib/auth/authContext.tsx

+import { useNavigate } from "react-router-dom";
+import { auth } from "../api";
+import {getCurrentRelativeUrl, isPublicAuthRoute, ROUTES} from "../utils";


Nit: what's the style, {aaa} or { aaa }?

itaigilo · 2025-11-06T14:19:37Z

webui/src/pages/auth/login.tsx

-    if (error) {
-        return <AlertError error={error} className={"mt-1 w-50 m-auto"} onDismiss={() => window.location.reload()} />;
-    }
+    // Setup doesn't complete, send to /setup with redirected=true&next=...


This comment belongs to the next line...

…on consistency after page restores.

Annaseli · 2025-11-06T19:46:21Z

webui/src/lib/auth/authContext.tsx

+type AuthContextType = {
+    status: AuthStatus;
+    user: User;
+    refreshUser: (opts?: { useCache?: boolean }) => Promise<void>;


Can you add a comment that explains this code?

The idea is that refreshUser can optionally receive an object of options, currently only { useCache?: boolean }.
refreshUser is an async method to reload the current user state from the API.
It accepts an optional options object (currently { useCache?: boolean }),
allowing callers to control whether to use cached data or force a fresh fetch.

Annaseli · 2025-11-06T19:47:15Z

webui/src/lib/auth/authContext.tsx

+    user: User;
+    refreshUser: (opts?: { useCache?: boolean }) => Promise<void>;
+    setStatus: (s: AuthStatus) => void;
+    onUnauthorized: () => void;


Why onUnauthorized and not onUnauthenticated?

Annaseli · 2025-11-06T20:03:56Z

webui/src/lib/utils.ts

+
+export const ROUTES = {
+    LOGIN: "/auth/login",
+    OIDC_PREFIX: "/auth/oidc",


I’m not familiar with /auth/oidc, but I am familiar with /oidc/login and /oidc/logout. Could you point out where you saw /auth/oidc being used?

Will change it

Annaseli · 2025-11-06T22:59:52Z

webui/src/lib/auth/authContext.tsx

+
+        if (isPublicAuthRoute(window.location.pathname)) return;
+
+        navigate(ROUTES.LOGIN, {


Why redirect to ROUTES.LOGIN instead of to the root, which already redirects to the login page?
Also, shouldn’t the /logout endpoints handle this redirection already?

We redirect explicitly to ROUTES.LOGIN instead of / for a few reasons:

onUnauthorized is triggered by 401s from XHR/fetch calls anywhere in the app.
Redirects returned by the /logout endpoint don't affect SPA navigation (the browser will not change window.location), so the client must navigate explicitly.

Going directly to /auth/login avoids an extra hop (root → login) and reduces flicker.

It also guarantees we keep the intended next target and doesn't rely on whatever logic the root route currently implements.

We keep the isPublicAuthRoute guard to avoid redirect loops if we are already on the login/oidc/sso paths.

TL;DR: direct, deterministic navigation to the login page is safer and smoother here.

Annaseli · 2025-11-06T23:34:59Z

webui/src/lib/auth/authContext.tsx

+        async ({ useCache = true }: { useCache?: boolean } = {}) => {
+            try {
+                const u = useCache
+                    ? await auth.getCurrentUserWithCache()


Why aren’t you wrapping await auth.getCurrentUserWithCache() with useAPI?
Also, related to this, if you’re recalculating this while the user is in a loading state, shouldn’t you handle it by setting setStatus(AUTH_STATUS.PENDING)?

I decided not to use useAPI here because the AuthContext runs outside the component lifecycle - we call refreshUser on app startup, after login/logout, and on pageshow events.
Using useAPI here would introduce redundant redirects and implicit 401 handling that conflict with onUnauthorized.
Regarding PENDING, I will add a selective state update: it will set only when performing a cold refresh (useCache: false) and the user isn't already authenticated.
This will avoid flicker during background updates while still providing a proper loading state.

Annaseli · 2025-11-08T17:09:08Z

webui/src/pages/auth/login.tsx

+
+/** Tiny component for external redirects (SSO) */
+const ExternalRedirect: React.FC<{ to: string }> = ({ to }) => {
+    useEffect(() => { window.location.replace(to); }, [to]);


Why is it in useEffect?
Also, it looks similar to the DoNavigate func

Annaseli · 2025-11-08T17:18:05Z

webui/src/pages/auth/login.tsx

+        return <Navigate to={ROUTES.SETUP} replace />;
    }
+
+    if (error) return <AlertError error={error} className="mt-1 w-50 m-auto" onDismiss={() => window.location.reload()} />;


in the previous code, the check for error was above the check for setup

Annaseli · 2025-11-08T17:22:30Z

webui/src/pages/auth/login.tsx

    }
+
+    if (error) return <AlertError error={error} className="mt-1 w-50 m-auto" onDismiss={() => window.location.reload()} />;
+    if (redirectedFromQuery) return <DoNavigate to={cleanUrl} replace state={{ redirected: true, next }} />;


Why was this step added here? we didn't have a step like that before, didn't we?

webui/src/pages/auth/login.tsx

Annaseli · 2025-11-08T17:33:59Z

webui/src/pages/index.jsx

-                                </Route>
+                                <Route path="*" element={<Navigate to="/repositories" replace/>}/>
+                            </Route>
+                            <Route path="auth" element={<Layout/>}>


Note that in the previous code we had:

<Route index element={<Navigate to="credentials" />} />

right after:

<Route path="auth" element={<Layout />} >

and before:

<Route path="login" element={<LoginPage />} /> <Route path="users/create" element={...} />

But we want the credentials page to be guarded, no?
We want it to be accessible only when the user is authenticated.
In the current implementation the <Route index element={} is under
<Route element={}>.
If it should not be, please do tell.

…henticated`, improve user refresh logic, and streamline login flow by removing unused utilities and centralizing route management.

…le cache for user refresh, and improve logout redirection logic.

itaigilo · 2025-11-09T20:15:00Z

webui/src/lib/auth/authContext.tsx

+import React, {createContext, useContext, useMemo, useState, ReactNode, useCallback, useEffect} from "react";
+import { useNavigate } from "react-router-dom";
+import { auth } from "../api";
+import {getCurrentRelativeUrl, isPublicAuthRoute, ROUTES} from "../utils";


Suggested change

import React, {createContext, useContext, useMemo, useState, ReactNode, useCallback, useEffect} from "react";

import { useNavigate } from "react-router-dom";

import { auth } from "../api";

import {getCurrentRelativeUrl, isPublicAuthRoute, ROUTES} from "../utils";

import React, { createContext, useContext, useMemo, useState, ReactNode, useCallback, useEffect } from "react";

import { useNavigate } from "react-router-dom";

import { auth } from "../api";

import { getCurrentRelativeUrl, isPublicAuthRoute, ROUTES } from "../utils";

Annaseli · 2025-11-11T16:20:58Z

webui/src/lib/components/navbar.jsx

                    auth.clearCurrentUser();
-                    window.location = logoutUrl;
+                    window.sessionStorage.removeItem(LAKEFS_POST_LOGIN_NEXT);
+                    window.history.replaceState(null, "", `${ROUTES.LOGIN}?redirected=true`);


shouldn't ${ROUTES.LOGIN}?redirected=true include the whole origin url path (before /auth/login)?

In this case we intentionally don't include the full origin.
history.replaceState treats relative URLs as scoped to the current origin, so
replaceState(null, "", "/auth/login?redirected=true") automatically becomes
http://<current-origin>/auth/login?redirected=true.

Keeping it relative is safer and more portable.
It works consistently in local dev, production, and behind reverse proxies, without hardcoding the origin.

Annaseli · 2025-11-11T16:37:59Z

webui/src/lib/hooks/api.jsx

-            // they are first redirected to the '/auth/login' endpoint. For users logging in via lakeFS
-            // (not via SSO), after successful authentication they will be redirected back to the original endpoint
-            // they attempted to access. The redirected flag is set here so it can later be used to properly
-            // handle SSO redirection when login via SSO is configured.


I think we should keep a comment (where it should be in the new version) explaining why the redirected flag is set to true, since it wasn’t clear to either Barak or me when we first saw it.

webui/src/pages/auth/login.tsx

Annaseli · 2025-11-11T17:23:17Z

webui/src/pages/auth/login.tsx

    if (setupResponse && (setupResponse.state !== SETUP_STATE_INITIALIZED || setupResponse.comm_prefs_missing)) {
-        router.push({pathname: '/setup', params: {}, query: router.query as Record<string, string>})
-        return null;
+        return <Navigate to={ROUTES.SETUP} replace />;


In the previous version we kept the: query: router.query

I will update the redirect to keep the existing query.
In React Router v6, we do this with location.search.

webui/src/pages/auth/login.tsx

@Isan-Rivkin

Authentication changed in #9593. This broke the ability to redirect to a non-React URL after logging in -- which @Isan-Rivkin discovered broke `lakectl login`. Restore the ability to go to the particular route needed under /api/v1. Checked by re-logging-in.

@Isan-Rivkin

* Add LoginToken support to OpenAPI - OpenAPI support - Login tokens abstraction - Controller hookup to login tokens abstraction (This feature is unimplemented in base lakeFS, and only a trivial login tokens abstraction exists here.) * Add releaseTokenToMailbox API This is typically only called by the browser -- but it's still handled as OpenAPI in the controller. * Add `lakectl login` client code * Release token correctly, with usable web page * make gen * [lint] Make govet & golanci-lint pass again * Open browser at login URL * Update `lakectl help` golden file * Use RetryClient in lakectl login Use the same RetryClient type as the rest of lakeFS, only with a different retry policy - one that retries status code 404. This involves refactoring getClient... so do that. * Use different (longer) login retries config * Explicitly redirect to login page from controller during lakectl login releaseToken is _not_ part of the UI, and there is no implicit redirection there from middleware. Instead, redirect there from the controller. * golangci-lint * [bug] Copilot fixes: HTTP header issues, nit in doc * [CR] Limit loginRequestToken length; extract X-Lakefs-Mailbox header * [CR] Retrieve login URL from config when possible * [CR] Fix bug: full redirect after login Authentication changed in #9593. This broke the ability to redirect to a non-React URL after logging in -- which @Isan-Rivkin discovered broke `lakectl login`. Restore the ability to go to the particular route needed under /api/v1. Checked by re-logging-in. * [bug] Correctly encode "next" URL It's a query param that contains "/" and ":" and things - encode it as such! * [bug] Fix golangci-lint: actually copy URL

Introduce centralized authentication context to manage auth state and…

11519b2

… replace scattered authentication logic in the frontend.

Ben-El added the exclude-changelog PR description should not be included in next release changelog label Oct 21, 2025

Ben-El changed the title ~~Introduce centralized authentication context to manage auth state and replace scattered authentication logic in the frontend.~~ Centralize Authentication Oct 21, 2025

Ben-El requested a review from itaigilo October 22, 2025 07:47

Refactor useUser and ConfigProvider hooks to use useCallback an…

9ef2f9d

…d `useAPI`, streamlining state management and simplifying configuration retrieval logic.

itaigilo requested changes Oct 22, 2025

View reviewed changes

itaigilo requested a review from Annaseli October 22, 2025 16:31

Ben-El requested a review from itaigilo October 22, 2025 18:46

itaigilo requested changes Oct 23, 2025

View reviewed changes

Ben-El added 7 commits October 23, 2025 11:09

Consolidate authentication status and logic into authContext, remov…

69a0025

…e redundant `status.ts`, and rename `RequireAuth` to `RequiresAuth` for consistency.

Refactor authentication logic by consolidating markAuthenticated an…

626debf

…d `markUnauthenticated` into `setAuthStatus`, simplifying auth state management.

Merge branch 'master' into webui-refactor-centralize-authentication

4bca6ab

Refactor login flow to use RedirectIfAuthenticated component, centr…

4796e8b

…alizing auth redirection logic and simplifying `login.tsx`.

Refactor RedirectIfAuthenticated to use a functional component and …

d8368f3

…simplify child rendering logic.

Refactor authContext to use functional components, arrow functions,…

0ff7e8d

… and improve readability of authentication logic.

Refactor RequiresAuth to use React.FC and arrow function for cons…

3352594

…istency with functional component style.

Refactor authContext to reorder AuthContext and AuthContextType…

95b9d5a

… definitions for improved readability and organization.

Ben-El requested a review from itaigilo October 26, 2025 09:11

Ben-El added 11 commits October 26, 2025 13:54

Refactor login flow to handle redirect authentication with `useEffect…

5d881bc

…` and `setAuthStatus`, simplifying and centralizing auth logic.

Refactor login.tsx to simplify next variable assignment by removi…

ca2f40d

…ng redundant type assertions.

Merge branch 'master' into webui-refactor-centralize-authentication

46038ea

Refactor login.tsx to reorder conditional logic for readability and…

6f930a2

… maintain consistency in authentication flow.

Refactor login.tsx to replace useEffect with direct conditional n…

e3a698d

…avigation logic and simplify SSO handling flow.

Refactor login.tsx to remove unused useEffect import.

a61eb21

Refactor login.tsx to remove redundant type assertions in next va…

b8260b5

…riable assignment.

Refactor login.tsx to remove unused authenticated redirect logic fo…

f33070a

…r cleaner and simplified authentication flow.

Refactor login.tsx to remove unused imports and redundant useAuth…

5cd834e

… destructuring for cleaner code.

Refactor authentication flow in login.tsx and requiresAuth.tsx to…

2ced21e

… centralize redirect logic and ensure consistent handling of authenticated and unauthenticated states.

Refactor login.tsx to simplify next variable assignment by removi…

c13ade2

…ng redundant parentheses.

itaigilo requested changes Nov 3, 2025

View reviewed changes

Ben-El added 3 commits November 3, 2025 12:32

Refactor authentication handling: rename setAuthStatus to `setStatu…

92dfe09

…s`, replace `AUTH_STATUS.UNKNOWN` with `AUTH_STATUS.PENDING`, and centralize utility functions for redirection and route management.

Merge branch 'master' into webui-refactor-centralize-authentication

b3675eb

Merge branch 'master' into webui-refactor-centralize-authentication

2ce217a

Ben-El requested a review from itaigilo November 4, 2025 13:19

Merge branch 'master' into webui-refactor-centralize-authentication

474adc6

itaigilo requested changes Nov 5, 2025

View reviewed changes

Ben-El added 3 commits November 6, 2025 10:04

Refactor authentication flow: replace buildNextFromWindow with `get…

64cc7de

…CurrentRelativeUrl`, unify `lakefs_post_login_next` handling, and centralize redirection utilities for consistency.

Merge branch 'master' into webui-refactor-centralize-authentication

4702fd5

Refactor authentication flow: remove useUser hook, centralize user …

ab7efcb

…management in `authContext`, and update components accordingly.

Ben-El requested a review from itaigilo November 6, 2025 12:59

itaigilo approved these changes Nov 6, 2025

View reviewed changes

Ben-El added 3 commits November 7, 2025 12:28

commit

6bc2e24

Merge branch 'master' into webui-refactor-centralize-authentication

dbb9341

Enhance authContext: refresh user data on pageshow for better sessi…

d0ecd0b

…on consistency after page restores.

Annaseli requested changes Nov 9, 2025

View reviewed changes

Refactor authentication handling: rename onUnauthorized to `onUnaut…

95ccf52

…henticated`, improve user refresh logic, and streamline login flow by removing unused utilities and centralizing route management.

Ben-El requested a review from Annaseli November 9, 2025 16:28

Refactor authContext and navbar: remove redundant dependencies, disab…

c39f938

…le cache for user refresh, and improve logout redirection logic.

itaigilo reviewed Nov 9, 2025

View reviewed changes

Ben-El added 2 commits November 10, 2025 10:37

Format imports in authContext.tsx for consistent styling.

917f6ae

commit

91eef37

Annaseli approved these changes Nov 11, 2025

View reviewed changes

Ben-El added 2 commits November 11, 2025 22:37

Merge branch 'master' into webui-refactor-centralize-authentication

717bf67

changes

9c787c5

Ben-El merged commit e2c3727 into master Nov 12, 2025
41 checks passed

Ben-El deleted the webui-refactor-centralize-authentication branch November 12, 2025 19:37

arielshaqed mentioned this pull request Nov 18, 2025

Support lakectl login: client, controller stub #9644

Merged

		if (path === "/auth/login") return true;
		return path.startsWith("/auth/oidc");

	if (path === "/auth/login") return true;
	return path.startsWith("/auth/oidc");
	return path === "/auth/login" \|\| path.startsWith("/auth/oidc");


		if (isPublicAuthRoute(window.location.pathname)) return;

		navigate(ROUTES.LOGIN, {

Centralize Authentication #9593

Centralize Authentication #9593

Uh oh!

Conversation

Ben-El commented Oct 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Motivation

Changes

Testings

Uh oh!

itaigilo left a comment

Choose a reason for hiding this comment

Uh oh!

itaigilo left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

itaigilo Oct 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Annaseli commented Oct 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

itaigilo left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Ben-El Nov 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Ben-El Nov 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Ben-El commented Oct 21, 2025 •

edited

Loading

itaigilo Oct 23, 2025 •

edited

Loading

Annaseli commented Oct 23, 2025 •

edited

Loading

Ben-El Nov 3, 2025 •

edited

Loading

Ben-El Nov 3, 2025 •

edited

Loading