Interface stops working in Chrome

[adhawkins]

Hi,

Across a number of machines now (some on the local network and some connected via VPN) I’m finding that the Duplicati interface becomes inaccessible via Chrome unless using an incognito window.

When I try to open the interface from a regular Chrome window, it just sits there saying ‘waiting for my.host.name.here’ in the status bar of Chrome. Not sure if it is relevant, but I’m accessing via HTTPS on port 8200.

Any suggestions as to how I work out what’s going on here?

Thanks

Andy

[JonMikelV]

I haven’t seen this type of thing before, but then I’m running fully local and not using https. What version(s) of Duplicati are you seeing this with and how can you access the pages using non-SSL connections?

[adhawkins]

Hi,

I’m currently running Duplicati - 2.0.3.5_canary_2018-04-13.

I’m not sure what the question about non-HTTPS means. I’m accessing via HTTPS.

It’s a very strange one. On 2 of my PCs I can only access Duplicati through a Chrome ‘Incognito’ window. On the third PC I can access it ‘normally’ via a standard Chrome window. All three machines are running Windows 10. Not sure about Chrome version, but I tend to apply updates whenever it tells me I need them.

Thanks

Andy

[JonMikelV]

@adhawkins

I’m not sure what the question about non-HTTPS means

Which of these URLs do you use to get to the Duplicati interface?

• http://localhost:8200/
• https://localhost:8200/

A few users have reported some issues with plugins or other websites causing overly long / invalid page requests.

Since Incognito mode usually clears those sorts of things and disables many plugins I would think that’s what you’re running into, however I believe sometime prior to 2.0.3.5 a message was added to let people know something was wrong rather than just getting a blank screen.

Hmmm - I guess I should have asked, when you say “inaccessible” do you mean a blank screen or an actual error message such as “Secure Connection Failed”?

[adhawkins]

Hi,

I’m using an HTTPS URL. It’s being accessed remotely, using a host name rather than ‘localhost’.

All I get is a message in the status bar ‘Waiting for my.host.name…’. The operation never seems to time out or anything, the blank page just remains.

Making the same request in an incognito window on the same machine returns almost instantly (I’m selecting the site from the same bookmark in both cases).

While I find it hard to believe Duplicati can tell the difference, it’s strange that it seems to be the only ‘site’ that has this issue. Equally strangely is that on one of my PCs I can access it just fine in a ‘regular’ browser window!

Thanks

Andy

[mikaitech]

I noticed a similar issue via insecure HTTP access, so I just use Firefox (actually I use Pale Moon) to access these kinds of systems. For me via Chrome, sometimes it works, sometimes it does not, versus it works 100% of the time via Firefox/Pale Moon.

[adhawkins]

Nice to know I’m not the only one seeing this! I guess I could use a different browser, but at the moment it’s as easy for me to open a Chrome Incognito window, so I’ll continue to do that for now.

I’ll try to remember to try it again periodically just in case it’s something that magically disappears with a Chrome update.

Andy

[adhawkins]

Hi,

Just done a bit of digging, and deleted a load of cookies for the host on one of the machines where Duplicat’s web interface wasn’t working. It’s now working again on that machine.

I’ll try to remember to repeat the process on another machine that’s not working, and see if I can work out exactly which cookie it was that resolved the issue.

Does that give any clues?

Andy

[JonMikelV]

@adhawkins

Does that give any clues?

It makes me think it’s related to an old post by somebody who had some utilities or something in their browser that made the cookies larger than they’re allowed to be.

If it happens again, see if you can open the browser debug console and look for some errors there…

Here’s one about “RequestEntityTooLarge” (though I think it was nginx related)

Nginx complains about RequestEntityTooLarge

When I run minio upstream from nginx, Duplicati complains about size (RequestEntityTooLarge). I added (as per minio documentation) proxy_buffering off; but nginx complains nginx: [emerg] invalid value "proxy_buffering". Can someone help?

And here are some others that might be similar to your experience:

Unable to open web app anymore (Mac OS) [SOLVED]

OK, I confirmed the issue is cookies. I cleared the cookies for localhost, and the page loaded. This is obviously an error unique to the fact that I also develop against localhost, and for some reason, the cookies aren’t uniquely including the port as they should. A couple of suggestions: Duplicati should probably render an error message if it can (if it had loaded 400 Bad Request, I might have narrowed it down faster) I wonder how hard it would be to configure something like my.duplicati.com …

Starting Duplicati server-wide (as root) & server-only on the Mac

Well, after a bit of experimentation (first with the LaunchDaemon that worked on the other Mac, but that had the same problem, then with removed ~root/.config, and so forth) this is what I suspect: cookie or browser cache. Because when I cleared the browser’s history/cache it worked. If this is something that the browser code of the Duplicati server can prevent it would be nice.

[adhawkins]

@JonMikelV

It makes me think it’s related to an old post by somebody who had some utilities or something in their browser that made the cookies larger than they’re allowed to be.

If it happens again, see if you can open the browser debug console and look for some errors there…

I’ll try to remember to do that. I did open the ‘Network’ bit of the developer tools, but didn’t see anything in there. I’ll try to remember to look at the console in future.

It seemed to me that no data was being returned from the server, but I don’t really have any evidence of that.

Thanks

Andy

[Kudo]

Hi,

I just had this problem too… No response from the Duplicati web interface in Chrome but no issues at all in incognito mode.

I discovered that my Bitdefender Online Threat Prevention had blocked the local IP address to Duplicati. Now, I have made an exception in Bitdefender [IP:port] and the web page response from Duplicati is back to normal.

[adhawkins]

Coincidentally, had this happen to me again today. Deleted one of the cookies (one of the gsScrollPos ones I think) and it immediately starts working again.

Andy

[JonMikelV]

@Kudo

I discovered that my Bitdefender Online Threat Prevention had blocked the local IP address to Duplicati.

I had a similar issue with Bitdefender and my unRAID GUI (not a local IP) and couldn’t figure out how to whitelist it - so I now I don’t use Bitdefender anymore.

[DisplayNerd]

I had this issue with duplicati and fixed it. I cleared all the cookies for the domain duplicati was on (mine was 192.168.1.19) and it worked fine. To figure out how to clear all the cookies on chrome for specific sites, check the user manual, but this does work.