Proxy auth doesn't work

[sevmonster]

Description With authMethod set to proxy, the username is always empty even if there is a matching header, which leads to the login page appearing since the login is not successful.

Expected behaviour The user to be fetched from the database and logged in.

What is happening instead? Even if matching header is provided, the user is never fetched.

2024/02/07 10:29:48 /api/login: 403 1.2.3.4 <nil>

Additional context Also tried on PostgreSQL fork and didn't work; thought it was the fork at first but it also doesn't work on master.

How to reproduce?

# filebrowser config set --auth.method proxy --auth.header test  
[...]
Auth method:      proxy
[...]
Auther configuration (raw):
{
  "header": "test"
}

# filebrowser &
2024/02/07 10:44:11 Using config file: .filebrowser.json
2024/02/07 10:44:11 Listening on 127.0.0.1:8080
# curl 127.0.0.1:8080/api/login --header 'test: admin'
403 Forbidden
2024/02/07 10:44:58 /api/login: 403 127.0.0.1 <nil>

[sebastian-mora]

I am running into a similar issue.

I notice when curl -H "X-Remote-User: admin" http://localhost/api/login

I get back a session token but when going to http://localhost/login I get an error. Is there a specific URL the reverse proxy should forward to?

[niubility000]

Maybe because of this one: Listening on 127.0.0.1:8080. You can't visit it from public internet with127.0.0.1. try this first: .\filebrowser config set --address 0.0.0.0 If it doesn't work, then try to change the source code: in vite.config.js server: { proxy: { "/api/command": { target: "ws://127.0.0.1:8080", ws: true, }, "/api": "http://127.0.0.1:8080", }, }, We need change 127.0.0.1:8080 to localhost:8080. If you don't know how to compile, just try the old version like 2.20.1. It don't has vite.config.js.

[sevmonster]

Maybe because of this one: Listening on 127.0.0.1:8080. You can't visit it from public internet with127.0.0.1.

It is not meant to be visited from the public Internet. That has nothing to do with this.

If it doesn't work, then try to change the source code: in vite.config.js

We need change 127.0.0.1:8080 to localhost:8080.

That has nothing to do with this either. The code you are referencing is for running the Filebrowser frontend live in a development environment, not building it. And changing 127.0.0.1 to localhost doesn't do anything anyway.

I've since switched to Filestash because of this issue. I was able to get proxy auth working there using Nginx, but it was a bit wonky, so if anyone is interested I can share.

[bilyboy785]

@sevmonster I'm really interested about how do you make Filestash work with Auth Proxy.

[sevmonster]

@bilyboy785 I've written down my experiences here: https://blog.sev.monster/posts/filestash-review-and-proxy-header-authentication.html

I'll leave this issue open since it is still a problem, but I no longer have any incentive to stick around and debug it. Cheers.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[sevmonster]

.

[tomlyo]

Spent a some time getting this all set up with my proxy and IdP, only to run into these same issues. I was actually hoping if the user didn't exist, it would be created.. as the point was to eliminate the user management from Filebrowser itself.

[sebastian-mora]

Pretty sure I found the bug. The backend does check the header value and proprly issue a JWT for the user in the proxy header but the frontend DOES NOT pass the custom proxy header when making a POST request to the login api.

  const res = await fetch(`${baseURL}/api/login`, {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
    },
    body: JSON.stringify(data),
  });

https://github.com/filebrowser/filebrowser/blob/master/frontend/src/utils/auth.ts#L41

The fix here is simple but the challenge is the frontend has no reference to the custom proxy header set using filebrowser config set --auth.method=proxy --auth.header=X-My-Header for the backend. Adjusting this frontend function to pass the user defined header key expected by the backend is non-trivial.

I think the easiest way to do this is to set static header value expected by the backend when using the proxy auth method and remove the feature to allow users to pick a custom header. Properly supporting the custom header will add complexity to the frontend. Additionally I am not sure there is a strong use case for users setting custom header keys.

The static header could be something like X-Proxy-Username.

[sevmonster]

Additionally I am not sure there is a strong use case for users setting custom header keys.

Some configurations may not allow for this. I have encountered many users (not specifically of this software mind you) that have complex/inflexible setups and can't/won't modify headers to suit such a change. Though it doesn't work at all as it is now, so fixing it even with such a limitation present would still be a benefit over nothing.

[sebastian-mora]

That's a good point. I am not versed enough in vue/frontend to know the best/how map the expected backend header to the frontend so will have to defer to someone with more knowledge

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[chxseh]

This is still an issue.

[kondasandeep13]

Hi Filebrowser Team,

Any update on this issue as we are blocked on the same. Help would be appreciated.

Thanks.

[Jayspek]

I'm also experiencing this

[asthanas]

I am able to pass header manually through the browser and login to filebrowser but when same header is being passed through oauth2proxy, filebrowser is not accepting the header. Both filebrowser and oauth2proxy have been deployed on openshift kubernetes cluster.

[integral-llc]

I'm facing the same issue, even when using curl

curl -v -X POST localhost:8080/api/login -H "X-My-Header: aa" -H "Content-Type: application/json" -d '{"username":"","password":""}'

I'm getting 403, even tough the auth is set to proxy. really a blocker :(

[Chuckame]

Hello, after hours of not being able to login via proxy (authelia), I just discovered this issue.

Caddy (the reverse proxy) is well passing the Remote-User to filebrowser but the url is still going to the login page, sadly 😢

[Chuckame]

Looking at the html, when logged in authelia, but not in filebrowser, it shows up this script:

<!-- Inject Some Variables and generate the manifest json -->
    <script>
      // We can assign JSON directly
      window.FileBrowser = {"AuthMethod":"json",...,"LoginPage":true,...}

The method seems to not be propagated to the frontend. I suspect that when going to any page without the jwt, this AuthMethod is used to know how to retrieve the new jwt, and goes to login page, so does not generate the jwt as expected.

[CristianCardosoArellano]

I'm using a proxy and it's working fine ... make sure address is set to 0.0.0.0

[sevmonster]

I'm using a proxy and it's working fine ... make sure address is set to 0.0.0.0

That is not the kind of proxy we're talking about...?

[CristianCardosoArellano]

what proxy then ?