keycloak sso redirect show 404

[zwmyxzs]

Describe the bug

I overridden the default theme to implement Keycloak SSO, which worked perfectly in version 2.0.0-alpha.1. After a successful Keycloak login, it would redirect back to my documentation page. However, in version 2.0.0-alpha.2, the redirected page shows VitePress's default 404 page. I need to delete the extra parameters in the URL, and sometimes even open a new tab, to display the documentation normally.
I tried removing the parameters from the returned URL: http://localhost:5173/docs/public/kunlun-kie/#state=1f134705-e629-43c0-be3d-c1aa651819f5&session_state=5b5fcf40-7646-48a0-907b-ce7f3fff1890&iss=https%3A%2F%2Fkunlun.shijicloud.com%2Fauth%2Frealms%2FKunlun-DevOps&code=9c33f8e6-6933-437f-90d5-8fbf318ed92d.5b5fcf40-7646-48a0-907b-ce7f3fff1890.ccec98eb-9264-416a-87f2-3f61c842e819. But I couldn't find a pattern—it doesn't seem related to the length. For example, if I delete the entire code parameter, I can access the page normally.

Reproduction

1. Implement SSO. I have customized the Keycloak SSO implementation logic in the onBeforeRouteChange event.
2. After logging in with Keycloak, the system will redirect back to the current document page, resulting in a 404 error.

Expected behavior

Display a valid page

System Info

  System:
    OS: Windows 11 10.0.26200
    CPU: (20) x64 12th Gen Intel(R) Core(TM) i9-12900H
    Memory: 13.46 GB / 31.73 GB
  Binaries:
    Node: 22.12.0 - D:\app\scoop\apps\nodejs-lts\current\node.EXE
    npm: 10.9.0 - D:\app\scoop\apps\nodejs-lts\current\npm.CMD
    pnpm: 10.21.0 - D:\app\scoop\shims\pnpm.EXE
  Browsers:
    Chrome: 142.0.7444.176
    Edge: Chromium (140.0.3485.66)
    Internet Explorer: 11.0.26100.1882
  npmPackages:
    vitepress: 2.0.0-alpha.2 => 2.0.0-alpha.2

Additional context

No response

Validations

• Check if you're on the latest VitePress version.
• Follow our Code of Conduct
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.

[brc-dd]

Don't think there was any change which would've broken this - v2.0.0-alpha.13...v2.0.0-alpha.15

[zwmyxzs]

Sorry. I made a mistake with the versions. Everything worked fine in my testing on 2.0.0-alpha.1, but after redirecting back from Keycloak on 2.0.0-alpha.2, the page lands on a 404. I checked the CHANGELOG and compared the version differences, and there’s a change related to src/client/app/router.ts. I’m not sure if this is related to the issue. Please forgive me as my front-end skills are not very strong.

[brc-dd]

Can you check the browser dev tools (Ctrl + Shift + J on Chrome) and see if it shows any error?

[zwmyxzs]

// router.ts alpha2
export function createRouter(loadPageModule, fallbackComponent) {
    const route = reactive(getDefaultRoute());
    const router = {
        route,
        async go(href, options) {
            href = normalizeHref(href);
            if ((await router.onBeforeRouteChange?.(href)) === false)
                return;
            if (!inBrowser || (await changeRoute(href, options)))
                await loadPage(href);
            syncRouteQueryAndHash();
            await router.onAfterRouteChange?.(href);
        }
    };
...
...

async function changeRoute(href, { smoothScroll = false, initialLoad = false } = {}) {
    const loc = normalizeHref(location.href);
    const { pathname, hash } = new URL(href, fakeHost);
    const currentLoc = new URL(loc, fakeHost);
    if (href === loc) {
        if (!initialLoad) {
            scrollTo(hash, smoothScroll);
            return false;
        }
    }
    else {
        // save scroll position before changing URL
        history.replaceState({ scrollPosition: window.scrollY }, '');

// router.ts alpha1
    async function go(href = inBrowser ? location.href : '/') {
        href = normalizeHref(href);
        if ((await router.onBeforeRouteChange?.(href)) === false)
            return;
        if (inBrowser && href !== normalizeHref(location.href)) {
            // save scroll position before changing url
            history.replaceState({ scrollPosition: window.scrollY }, '');
            history.pushState({}, '', href);
        }
        await loadPage(href);
        await (router.onAfterRouteChange ?? router.onAfterRouteChanged)?.(href);
    }

In 2.0.0-alpha.2,the loadPage method is not being called when redirecting back from Keycloak. This is because the condition if (href === loc) in the changeRoute method fails to match:

href is: /docs/public/kunlun-kie/#state=82df01c5-5b76-4b2e-a2ec-76d925ef6a06&session_state=87a1e246-e6fd-4828-a76a-accb89966f64&iss=https%3A%2F%2Fkunlun.shijicloud.com%2Fauth%2Frealms%2FKunlun-DevOps&code=f44886c3-ea93-4228-81b2-a5d06318eb3d.87a1e246-e6fd-4828-a76a-accb89966f64.ccec98eb-9264-416a-87f2-3f61c842e819

loc is: /docs/public/kunlun-kie/
Thus, the condition returns false.
Only after I modified the URL did the two values match (the condition returned true), triggering the subsequent loadPage method.
However, in version 2.0.0-alpha.1, there was no changeRoute method. The loadPage method could be directly invoked with the full parameter: /docs/public/kunlun-kie/#state=58d12a78-d473-47d3-bc95-d9c8f034c76d&session_state=74dca6d5-54ae-4326-811c-430190013945&iss=https%3A%2F%2Fkunlun.shijicloud.com%2Fauth%2Frealms%2FKunlun-DevOps&code=b96807a4-ad15-4214-825d-1589fd17dfa0.74dca6d5-54ae-4326-811c-430190013945.ccec98eb-9264-416a-87f2-3f61c842e819
I’m not sure if this change (the addition of changeRoute) is the root cause of the issue.

[zwmyxzs]

Sorry. I made a mistake with the versions. Everything worked fine in my testing on 2.0.0-alpha.1, but after redirecting back from Keycloak on 2.0.0-alpha.2, the page lands on a 404. I checked the CHANGELOG and compared the version differences, and there’s a change related to src/client/app/router.ts. I’m not sure if this is related to the issue. Please forgive me as my front-end skills are not very strong.

// The first time redirecting back, it throws a 404 error.

kunlun.shijicloud.com/auth/realms/Kunlun-DevOps/protocol/openid-connect/3p-cookies/step1.html:1  requestStorageAccess: Permission denied.
kunlun.shijicloud.com/auth/realms/Kunlun-DevOps/protocol/openid-connect/3p-cookies/step1.html:1  requestStorageAccess: Must be handling a user gesture to use.

// I can access it normally after removing the last code parameter.

requestStorageAccess: Must be handling a user gesture to use.
step1.html:1  requestStorageAccess: Permission denied.
index.ts:18 页面加载前路由检查: /docs/public/kunlun-kie/#state=67e715d8-b2e6-4b02-8a17-dfe44c419d5f&session_state=11c787a5-1aff-499d-837c-55354af05aa8&iss=https%3A%2F%2Fkunlun.shijicloud.com%2Fauth%2Frealms%2FKunlun-DevOps

kunlun.shijicloud.com/auth deployed keycloak server.

[zwmyxzs]

async function changeRoute(href, {smoothScroll=false, initialLoad=false}={}) {
    const loc = normalizeHref(location.href);
    const {pathname, hash} = new URL(href,fakeHost);
    const currentLoc = new URL(loc,fakeHost);
    if (href === loc) {
        if (!initialLoad) {
            scrollTo(hash, smoothScroll);
            return false;
        }

When I modified the URL to http://localhost:5173/docs/public/kunlun-kie/#state=41d7ae70-1a6e-4a56-a0c3-c3b162594441&session_state=080a3623-f7bc-4747-a63a-4f56c1f7e0fb&iss=https%3A%2F%2Fkunlun.shijicloud.com%2Fauth%2Frealms%2FKunlun-DevOps — which means removing the final code parameter — and debugged it in a new tab, the href === loc condition in the code above evaluated to true ultimately, triggering the loadPage method.