If you mean server options, they’re current (not old), and sometimes interact with GUI config.
For example --webservice-password can set it and can also be used to disable password.
It’s not happening here, starting from new configuration (no Duplicati-server.sqlite). It’s blank.
Duplicati upgrade - “The host header sent by the client is not allowed” explains why * is bad.
Definitely more convenient though, but not secure, and the choice was to default to secure…
Possibly your Docker packager did some things. I’m still trying to learn what Docker you use.
https://github.com/linuxserver/docker-duplicati/blob/master/root/etc/services.d/duplicati/run
makes me think LinuxServer.io Docker decided to defeat security by setting * for Hostnames.
I confirmed that a given --webservice-allowed-hostnames does in fact populate GUI field.
We might need a Docker expert (especially on network). I don’t use Docker, so am not expert.
How are you setting up the iFrame so that it connect to Duplicati’s IP which might be dynamic?
Docker documentation Container networking has IP address and hostname section.discussing.
I have no idea if Home Assistant does anything to make getting to servers any easier than that.
Theoretically, perhaps the reverse proxy could steer the incoming connection to right container.
Cross-site request forgery protection. In your F12 view, requests get an X-XSRF-Token header.
You might also be able to find the cookie in the store for whatever host or IP address you go to.
Did you reload the page (preferably using a hard refresh)? I think that should get a new cookie.
Typically I get these if I try to use one browser connected to multiple Duplicati at different ports.
I’m not a web developer, but I think the cookies step on each other because host is the same…
I’m not sure what’s going on in your case, but you have the tools set up to watch action. Code is
Any C# or web developers, please feel free to comment.