Http.hugo and filemanager (Solved with bugfix to filemanager)

Hi All,

I’m looking for some clues to unexpected behavior with plugin http.hugo.

I downloaded and installed Caddy 0.10.4 with the http.hugo plugin a few weeks ago. It was working great! Thanks for all the hard work on this awesome web server!

A couple days ago, I decided to pull down version 0.10.6 with (what I thought was) the same “customization” plugin set. This version of caddy with http.hugo seems to work differently (with no changes in Caddyfile or Hugo’s config.toml): after authenticating at the /admin URL (using HTTP Basic Auth), I am presented with a second authentication page presented by the filemanager. This auth page does not recognize my credentials. On reverting back to caddy 0.10.4 the second authentication challenge does not appear and I am able to view and edit the files.

I tried adding no_auth to the hugo section of my Caddyfile (below), with no effect.

I would very much appreciate any pointers and suggestions anyone could offer.


~David {
  root /var/www/
  basicauth /admin username **SUPER SECRET PASSWORD**
  hugo /var/www/broadcasttool-src {
    flag destination /var/www/
} is a little dry on info in this regard. suggests that, as you’ve attempted already, putting no_auth in the hugo section should have been the solution.

CC @hacdias, thoughts?


Sorry, but I’m having some problems regarding the compatibility between filemanager and hugo with Caddy basicauth (and probably even with other auth middlewares).

The thing is that I’m using the HTTP Auth header (which is the standard) even when no_auth is activated. And that messes with the Basic Auth authentication.

Here are some already reported issues:

My suggestion is to use FM/Hugo with its own native login for now. Just remove the no_auth thing and login with admin/admin. Then, you can go to Settings and change the password.

I’ll try to fix this ASAP. Sorry :frowning:

1 Like

Great discussion! Thanks for your replies @Whitestrake and @hacdias! What is more puzzling to me is why the behavior changed between caddy versions 0.10.4 and 0.10.6. I have not yet diffed the code, but there seems to be nothing in the change logs that indicates what might have changed.

I will keep digging and welcome more thoughts!



1 Like

I think I know a way of fixing this! :wink:

@dklann hopefully it’s fixed! Try downloading it again :slight_smile: Thanks for reporting this

1 Like

Hi Henrique, @hacdias!

I downloaded from the caddy site. No difference, still seeing an authentication page for File Manager. Should I get the plugin from somewhere else? If so, I do not know how to integrate it with caddy without compiling from source code. Is that how you want me to do this? I am happy to learn how to do this, but I’m a noobie at the moment. :slight_smile:


Another data point. I just cleared the auth cookie from my browser, disabled (commented out) basicauth in Caddyfile, and successfully signed in to the file manager with admin / admin. Is it possible that I could have previously signed in to the file manager (the second auth request) with the default credentials? It still seems like a bug, and I’ll try a newer version when I can.


1 Like

Please try cleaning the cache and add no_auth to hugo’s options on your Caddyfile.

Done. Working! I also added basicauth back to Caddyfile and it still works!

Thanks for looking at this and for fixing it quickly @hacdias !!

Now on to the next mystery: why hugo cannot seem to find config.toml when I install hugo as a snap package (it’s looking in /var/lib/snap/void for the config file!!!)… For posterity: this is on Ubuntu 16.04 Server.

1 Like

NP! :smiley:

Could you please try going to SettingsGlobal Settings and check if the Hugo Root path is defined, please?

Hello @hacdias, I see no such setting “Global Settings” in the filemanager Settings. Are you referring to a different settings? Thanks for your on-going support!

Here :slight_smile: :

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.