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.

…eamline sessionStorage usage.

…ze URLs, and enhance `next` state persistence logic.

… unnecessary try-catch block.

…uth checks, and simplify `next` state handling.

…` state.

…t` state handling, and improve redirection cleanup logic.

…` navigation from sessionStorage.

…in config handling, and consolidate rendering logic.

itaigilo

Asking again since it wasn't addressed yet, and it's a very important part of this feature:

@Ben-El can you please provide details on how was this tested?
Besides the different flows, how about the different auth types - Cloud, Enterprise, SCIM and RBAC?

And on the same subject, did you consider adding some automated tests (E2E or integration), so that we'll have more confidence when updating this area of the WebUI in the future?

…N_CONFIG`, and enhance redirection handling with `Navigate`.

…edirection logic, and improve query string handling.

… and `ExternalRedirect` components, and enhance `next` state handling.

Annaseli · 2025-11-02T14:55:16Z

Asking again since it wasn't addressed yet, and it's a very important part of this feature:

@Ben-El can you please provide details on how was this tested? Besides the different flows, how about the different auth types - Cloud, Enterprise, SCIM and RBAC?

And on the same subject, did you consider adding some automated tests (E2E or integration), so that we'll have more confidence when updating this area of the WebUI in the future?

My Thoughts About the Testing

Your changes are great! but they affect the sensitive authentication flow, which we want to be cautious about because it could easily break when interacting with different integrations and environments.

What I Think Should Be Done Regarding Testing

Prepare a test plan that details:

Exactly what currently broken flows you plan to test in addition to the normal authentication flow that works now
On what lakeFS set-up you plan to test it
Whether it was tested
Whether each case was tested manually or is already covered by E2E / integration / unit tests.

That way, we can review it together, identify any missing flows, scenarios, or environments that still need coverage, and prioritize what to test with which setups.

Suggested Structure for the Test Plan

List (in a table) all broken flows fixed by this PR, referencing the issues linked to the Refactor issue.
List all lakeFS setups where authentication should be verified. (Maybe we don’t need to check all of these setups.)
For each flow, indicate whether it was tested in each setup (and how). (Maybe we should prioritize which flows and setups we want to have tests for and whether manual or automated.)

Current My Understanding of the Different Setups

(Please correct or add if I missed anything.)

We currently have multiple ways to handle authentication (verifying identity) and several methods for authorization (managing permissions).
These two are separate concerns but I think it is needed to ensure that (all? @itaigilo ) authentication continues to work correctly with (all? @itaigilo ) our authorization services.

Authentication Options (lakeFS Enterprise)

Local lakeFS credentials
OIDC (Auth0)
SAML
LDAP
To have an option to choose the method

Authorization Options (lakeFS Enterprise)

none
ACL (do we need to maintain it?)
RBAC
external?

Authorization Options (lakeFS)

none
ACL (do we need to maintain it?)
external?

I’m not sure which authorization and authentication is used in Cloud. Maybe SCIM and GIAM are relevant here so you might need to check that.

Essentially, the goal is to ensure that authentication works properly with:

authorization service
across lakeFS OSS, lakeFS Enterprise, and lakeFS Cloud (Maybe for lakeFS Cloud, we can test using lakeFS Enterprise with the same authentication and authorization configurations used in our Cloud setup?).
All the broken flows mentioned in the refactor issue were fixed as promised.

But we only need to check the combinations that our customers might actually use.

Regarding Automated Tests

To check whether we currently have E2E / integration / unit tests that cover any of these flows.
- If we do, maybe to write in the test plan, which ones and what setups they cover.
- For example, I know we have the Quickstart Playwright test, which covers some basic UI and authentication flows. Maybe some of the flows are already validated there.
After completing the test plan, we can decide:

Things to Consider Regarding the Test Plan

Decide which tests should be prioritized and added or manually tested in this PR, and whether we should open a follow-up issue listing the remaining tests for future work.
Do we test the authentication flow that works now?
Are all the broken flows listed to be tested?
Do all the broken flows that were tagged as duplicates in the refactor issues truly duplicates and are listed in the test plan?
Are there missing setups not yet listed and need to be?
Are all the listed setups actually relevant to test these specific flows?
Do we need to test every broken flow/authentication flow across every combination of setups?

@Ben-El @itaigilo @nopcoder - WDYT?

…s and simplify redirection logic.

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...

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.

Ben-El added 9 commits October 30, 2025 19:52

Refactor login redirection: consolidate next state handling and str…

2319d8a

…eamline sessionStorage usage.

Refactor login redirection: streamline redirected handling, normali…

aef4d21

…ze URLs, and enhance `next` state persistence logic.

Refactor login redirection: simplify next state handling and remove…

31855dd

… unnecessary try-catch block.

Refactor login redirection: consolidate rendering logic, centralize a…

c8ab095

…uth checks, and simplify `next` state handling.

Refactor login redirection: remove redundant typeof check for `next…

f028b0b

…` state.

Refactor login redirection: extract withNext function, enhance `nex…

c7de7fc

…t` state handling, and improve redirection cleanup logic.

Enhance login redirection: add useEffect to handle `post_login_next…

521f459

…` navigation from sessionStorage.

Refactor login flow: introduce DEFAULT_LOGIN_CONFIG, streamline log…

c7c75e7

…in config handling, and consolidate rendering logic.

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

3492a62

itaigilo reviewed Oct 30, 2025

View reviewed changes

Ben-El added 3 commits October 30, 2025 22:25

Refactor login flow: streamline rendering logic, remove `DEFAULT_LOGI…

9ebeeb0

…N_CONFIG`, and enhance redirection handling with `Navigate`.

Refactor login redirection: simplify loading state, enhance setup r…

b54602d

…edirection logic, and improve query string handling.

Refactor login flow: extract getLoginIntent, introduce DoNavigate…

4854532

… and `ExternalRedirect` components, and enhance `next` state handling.

Ben-El requested a review from nopcoder November 2, 2025 07:11

Annaseli mentioned this pull request Nov 2, 2025

Web UI refactor client login/change with pulling storage configuration #8811

Open

Ben-El added 2 commits November 2, 2025 20:06

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

6ddf7d5

Refactor navbar and login route: remove unused auth context reference…

c0d46fc

…s and simplify redirection logic.

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

		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");

Centralize Authentication #9593

Are you sure you want to change the base?

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!

Annaseli commented Nov 2, 2025

My Thoughts About the Testing

What I Think Should Be Done Regarding Testing

Suggested Structure for the Test Plan

Current My Understanding of the Different Setups

Authentication Options (lakeFS Enterprise)

Authorization Options (lakeFS Enterprise)

Authorization Options (lakeFS)

Regarding Automated Tests

Things to Consider Regarding the Test Plan

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!

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