filebrowser: Can't use external authentication method

Description

I am trying to switch from V1.11.0 to 2.0.0 and I get “Something really went wrong.” when accessing my files

Expected behaviour

Access to my files

What is happening instead?

Additional context I use filebrowser in docker-compose behind an nginx proxy.

on V1.11.0 I gave the command: --auth.method=None --baseurl=/files

On 2.0.0 I switched to filebrowser.json config file, my config file is:

{
  "port": 80,
  "address": "",
  "noAuth": true,
  "baseURL": "/files",
  "log": "stdout",
  "plugin": "",
  "scope":"/srv/",
  "allowCommands": false,
  "allowEdit": true,
  "allowNew": true,
  "commands": [ ]
}

My docker-compose config:

files:
        hostname: files
        image: filebrowser/filebrowser:v2.0.0
        restart: unless-stopped
        command: --config /.filebrowser.json
        volumes:
            - home:/srv/
            - ./filebrowser.json:/.filebrowser.json
        networks:
            - default

My nginx proxy:

location /files/{
    proxy_pass http://files/files;
}

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 22 (12 by maintainers)

Most upvoted comments

I just tested it with 2.0.2 and I confirm that it is fixed, thanks for your help 😃

dbeniamine on Feb 6, 2019

@1138-4EB the issue was that basic auth was rewriting our HTTP header so File Browser didn’t work.

hacdias on Jan 29, 2019

@dbeniamine basic auth won’t work until this is fixed.

So, right now we have two options:

Implement Basic Auth.
Just change the Header name to something else and add a note to the documentation to keep that header when proxying (some proxies might try to remove the header)

I’m implementing the second since is the fastest and easiest and might not cause warm.

/cc @1138-4EB

hacdias on Jan 29, 2019

@liranbg the issue of not using the default authentication header is that proxies and browsers might not know how to treat it. By using Authentication, we can ensure that external proxies know how to deal with this more sensitive header.

Implementing what you said or just use a custom header is an option.

Another option is to implement basic auth.

hacdias on Jan 27, 2019

I think that this is due to the noAuth key in the configuration (if that still is supported?). I have had similar issues when running with --noauth (which is supported as of the command-line help, I believe) and trying to protect through basic authentication in the reverse proxy instead. The log of my reverse proxy reports an error when accessing /api/resources as it does not carry the same username (probably meaning one of headers has been mangled). I am running behind caddy though, so this might be a different issue.

efrecon on Jan 16, 2019