OIDC login redirect URL does not respect baseURL, breaks OIDC login flow

[GermanCoding]

Description Attempting to configure OIDC login with Filebrowser Quantum. Filebrowser runs at a subpath /filebrowser on the domain. So all filebrowser paths are accessible at https://example.com/filebrowser/. To configure this,

server:
  baseURL: "/filebrowser/"

is set in config.yaml

Expected behaviour OIDC login works. The first step towards OIDC login is that filebrowser directs the browser to ./api/auth/oidc/login (which will then issue the actual redirect to the identity provider). Since we have a baseURL set, the browser should be redirected to the (absolute) URL path /filebrowser/api/auth/oidc/login.

What is happening instead? The browser is instead redirected to /api/auth/oidc/login, ignoring the configured baseURL entirely. This results in a 404 error on my reverse proxy, thus breaking OIDC login flow.

Additional context It appears that the redirect URL for the browser is hardcoded in the frontend here:

https://github.com/gtsteffaniak/filebrowser/blob/e3dc484c2805f22785849101cfb1c9f10c3c9fc2/frontend/src/router/index.ts#L153

This redirects the browser window without considering the sub-path the browser is currently on (the baseURL).

How to reproduce?

1. Setup filebrowser. Configure any OIDC server

auth:
  methods:
    password:
      enabled: false
    oidc:
      enabled: true
       issuerUrl: "<some IdP url>"
       # other OIDC parameters, not relevant here

2. Set a baseURL that is not the default:

server:
  baseURL: "/filebrowser/"

3. Attempt to login by navigating to http://localhost/filebrowser/. Observe the invalid redirect URI to http://localhost/api/auth/oidc/login

Files N/A

[GermanCoding]

Similarly, while working around this problem with a reverse proxy I noticed that the final redirect issued by filebrowser (after the identity provider has sent the browser back to the client) also doesn't respect the baseURL, e.g. I get redirected back to https://example.com/files/ instead of https://example.com/filebrowser/files/.

The authentication cookie set also has the path hardcoded to /.

[gtsteffaniak]

I'll take another look at this to make sure I didn't miss anything.

[gtsteffaniak]

I didn't have an issue with this myself using baseurl, but I am updating the line you provided to use the vue router which should be baseurl aware.

[gtsteffaniak]

fixed in 0.7.10