Page 1 of 1

Ajax web interface issue, all browsers

Posted: Mon Mar 11, 2019 11:16 pm
by wrwindsor
OSE/FOSS version.

I recently upgraded Zimbra from something ancient (circa 2010) to 8.8.11_P2 by using zextras (30 day trial) to export everything and import into 8.8.11_P2.

For a short while, ajax worked for my account (FireFox), never worked for wife's account (Chrome, FireFox, McEdge). Then after trying to pull it up on other browsers, it quit working on mine too across the board.

I dug through the forums, found the "set default search to in:sent" trick, that didn't work.

Then P3 was announced, so I upgraded to it last weekend.

For me, Ajax GUI started working again (FireFox), wife still having problems. She logs in from work (another computer) and it works! yay.

An hour ago, I restarted FireFox on my laptop and the Ajax login quit working again.

I've tried clearing the cache'n'cookies in FireFox, I've killed'n'restarted FireFox. I've pulled up all three other browsers (Chrome, Edge, IE) and it doesn't work there, either.

I've also tried it on another (fresh install) W7 system with chrome and IE and it hangs there as well.

I've cleared the cache in Zimbra, I've restarted the server.

When it fails, it's the typical hang at the "Loading ..." grey box.

Where do I start looking for Ajax-related logs? This is horribly annoying.

Thanks.

Re: Ajax web interface issue, all browsers

Posted: Wed Mar 13, 2019 2:55 pm
by wrwindsor
A minor update to this...

If Ajax interface is wedged in FireFox, opening in any other browser mimics the problem.

If I log out in FireFox, I can open it fine in Chrome.

Starting to look more like a browser issue.

Re: Ajax web interface issue, all browsers

Posted: Wed Mar 13, 2019 6:11 pm
by JDunphy

Re: Ajax web interface issue, all browsers

Posted: Thu Mar 14, 2019 2:35 pm
by wrwindsor
wrwindsor wrote:Then P3 was announced, so I upgraded to it last weekend.
JDunphy wrote:Zimbra offered patches. https://blog.zimbra.com/2019/03/new-zim ... 1-patch-9/
Um... ok.

Re: Ajax web interface issue, all browsers

Posted: Thu Mar 14, 2019 11:13 pm
by wrwindsor
Another minor update.

If I log out of FireFox, get it up and running in Chrome, I can bring it up again (later) in FireFox and it works fine.

Or in other words.. it appears to be a bit random on when it does and does not work. I'll have to play with it more to narrow that down.

This is all 8.8.11_p3, btw.

Re: Ajax web interface issue, all browsers

Posted: Thu Mar 21, 2019 5:40 pm
by wrwindsor
The problem crops up when NoScript catches (and blocks) something trying to run scripts off of worldcdn.net.

It's not NoScript that's the problem, though. At the same time I can pull up Chrome (no plugins installed) and it fails there as well. Also, wife can pull up any browser on her system and it fails during the same timeframe (she doesn't run the 1337 plugins).

Given that it's https, I doubt there's a MIM attack/proxy doing this.

Does zimbra have some DNS prefetch code inside it?

Re: Ajax web interface issue, all browsers

Posted: Fri Mar 22, 2019 2:50 pm
by Klug
You might want to re-apply P3.

They released it with an (unneeded) patch for Chrome (beta) that breaks Firefox.
So they re-released it (the day after IIRC) with the fix, without changing its name (it's still P3, not P4 nor P3b).

If you installed the first P3, you should re-download it and re-apply it.

Re: Ajax web interface issue, all browsers

Posted: Fri Mar 22, 2019 10:45 pm
by wrwindsor
Thanks for the tip, I'll do that soon and see how it goes.

Re: Ajax web interface issue, all browsers

Posted: Mon Aug 26, 2019 5:17 pm
by wrwindsor
Long overdue followup to this issue, in case anyone else runs into this. (Hello to those of you that found it via google search.)

I finally figured out the problem. The VPS has nginx reverse proxy in front of my mail server and the nginx dns pre-fetch was causing issues. Once I asked the VPS crew to disable this (they disabled "web acceleration" wholesale), the problem went away.

Part of the debugging process involved going to the mail server via IP address instead of FQDN. That caused the issue to go away (ignoring the SSL cert error that popped up, of course), which then pointed me at a nginx reverse proxy.