It has always been set to Port 443 and that worked fine for over 2 years. Nothing in that installation has been changed.
Only software update have been, OS X, ngrok and DEVONthink. That Mac is used for nothing else.
The last ngrok update was a few months back, and there were no problems.
Unfortunately I can’t pinpoint a moment it stopped working - but I’m guessing one of the recent OS X security updates, as there have been a few.
Does a reboot fix this or changing the port?
443 is the standard HTTPS port. Try something different, like 65530 and see if there’s any change.
Tried 65530 and others as well, but no success. Only 443 allows a connection. (I changed the port setting in both DEVONthink server and in ngrok, and rebooted).
ngrok have looked at this and advised the connection is ok, and ngrok does not change any of the data flowing through. So the jumbled rendering of the screen is likely rated to the application.
I setup a new user account, new ngrok installation, but same end result. I get this login page no problem.
I log in fine, but then I get this rendering in Firefox, and a blank page in Safari. (I can click the buttons and it does work, and I can log out ok).
So strange but thanks for the diligence in trying our suggestions! 
While Safari always gives a blank page, Firefox sometime presents a blank page, and sometimes presents a mixed up layout with odd icons. However, these icons are clickable, and ultimately opens the underlying data like a PDF. You just have to scroll a long way down as all the icons are in a long list. (see image below).
One error which always comes up is the “stylesheet is not loaded”. Maybe that is why the layout is all scrambled?
I could buy an SSL and then get a P12 and load that onto the web server, but I doubt that will make a difference.
When Firefox presents a blank page, the console shows a 401 unauthorised error, as well as the stylesheet error. Below are the console outputs if that means anything.…
These are the secure page details;
Probably. But that’s a CSP issue, as I already said. Somehow, the server did not deliver the stylesheet with the correct MIME type. This could be related to SSL, in which case getting your own certificate would probably not make a difference.
I don’t know enough about Safari but I could imagine that it gets kind of picky when SSL is active so that it refuses to download the CSS (or other resources) if they look fishy to it (again, the relevant term is CSP in this context).
The network view you posted is less helpful then the console tab in this context. I’m not even sure that the network tab would show errors.
What exactly is it that ngrok is supposed to be doing?
Just to make the terminology clear: you can’t buy SSL, you buy a certificate. And you do that for a domain (dtserv.ngrok.io, for example), not for an address. I know that this may sound overly picky, but it helps to use the right terms when trying to solve a problem.
And no, you should not have to buy a certificate for this domain. At least if the browser is not too restrictive, it should offer you the possibility to accept the certificate although it does not match the domain name.
Also, there already seems a certificate issued for this domain as shown in the page information. You could check that by inspecting the certificate information by clicking on the lock in the address bar.
When I try your server dtserv.eu.ngrok.io, I get
Tunnel dtserver.eu.ngrok.io not found
ERR_NGROK_3200
If I understand you correctly, you’d basically need a DynDNS service. Ngrok seems to do a lot more than that (secure tunnel - whatever that might mean and why would one need it with HTTPS anyway?). Maybe another, simpler DynDNS service would solve the problem.
Also, DEVONntech might check the CSP in their product. At least Firefox is not happy with it. But it should be: a broken CSP sooner or later leads to a broken app, in my experience.
My service is via EE 4G network, (no broadband here). Port forwarding does not work because they use CGNAT. It’s the reason why I eventually ended up with ngrok as the solution.
ngrok creates a secure tunnel to my DEVONthink web server using an application running on that Mac. I don’t know the in-depth details but it was very easy to setup and has always worked well. My 4G service is solid, between 15-30Mbps up & down.
Note that address you tried to reach has a typo: https://dvserver.eu.ngrok.io/ should work.
ngrok folks suggest the messages from the logs about the stylesheet are because the content type is wrong:
The stylesheet https://dvserver.eu.ngrok.io/app/css/app.lac68303.css was not loaded because its MIME type, “text/plain”, is not “text/css”
They say usually that’s a typo in the sylesheet link or something.
Regarding the DynDNS option - I don’t have any experience. First question is what is the “hostname” I am supposed to provide when signing up for this? Sorry for the dumb questions…
I don’t get it. You’d forward port 443 (https) from your router to your server. Why would your internet provider be involved in that?
I know. But why do you need a “secure tunnel” if you’re using HTTPS anyway? This introduces an additional level of complexity without a recognizable benefit.
Generally you just choose something from the domain of your DynDNS provider. Same as with your ngrok.io hostname.
BTW: you said that everything works ok inside your local network. Did you test that with HTTPS or HTTP?
A typo in the name of a CSS file would not be limited to an external connection to your server. Proposing this as an explanation as the support did is not very confidence-inspiring.
From EE tech support (my 4G provider);
“…EE block no ports. However it is probable that you are up against a limitation of EE’s mobile network. The EE mobile network uses Carrier Grade NAT (CGNAT), which means that you don’t get your own public IP address but share it with other users. So you can’t be uniquely id’ed on the Net & therefore your LAN cannot be addressed from outside for unsolicited accesses. This is unlike fixed BB.…”
This is why I ended up with the ngrok solution.
Initially I used a standard ngrok tunnel, and it worked fine for over 2 years. When it stoped working, and “connection not private” messages were being shown, I switched to a secure tunnel to see if that would help. That was only last week. Obviously it did not help.
It only works with HTTPS
An update;
In the end I moved the DT Web Server licence to a different Mac, and tried using ngrok on that Mac. Same result - connects fine over the Internet, but after logging in it presents either a blank page or jumbled page of icons. The jumbled icons are clickable and navigable - but impossible to use as they are so misplaced. Safari, Edge, Firefox are blank, Chrome and Brave are jumbled.
Weirdly, after the initial new setup, the web server worked perfectly on Brave, and I thought at least my colleagues could switch that that browser. However, after the third or forth login it went to the jumbled state and remains mostly* the same.
*On occasion it sometime loads and runs perfectly - but I find no reason why. Comparing all Brave settings on two separate Macs they are identical, but it sometimes works on one Mac, and never on the other. (Same DV and MacOS).
Then I tried using Remote.it
Installed and setup the HTTPS service, and I get exactly the same problems as above.
Lastly - I now also have Starlink. Sadly that has the same port forward limitations.
Whether I use the 4G connection or the Starlink connection the jumbled icon problem remains the same.
Any ideas?
This does not explain your situation but might be a solution.
Do you happen to run a Synology NAS on your network?
Synology DSM software includes a reverse proxy feature. I have found that to be helpful in solving some situations which were challenging using only standard port forwarding.
The only thing that I can think of is some kind of “optimisation” in your provider’s network. I seem to (very) vaguely remember something like that from ages ago in the Blackberry network. Though my memory might be wrong, it’s so long ago.
In one of your older posts (Web Server blank page - #47 by peter999) you posted a screenshot that clearly showed that two style sheets where not loaded by the browser because of a CSP violation. If the CSS is not loaded, the page may very well be blanc or completely broken or whatever.
I’ll try to explain the issue as best and briefly as I can – which is not very well. You should really read about CSP. The idea behind content security policy is that a HTML document should only load well-defined resources. The CSP defines the rules for that. They can specify that the fonts must be stored locally, that all CSS files must come from https://example.com and a whole bunch of other things.
So it could be a CSP problem as your browser console says. But it could also (and I think that’s the case here) be something completely different, as described here
or here
So it might be worth trying to load the CSS directly into the browser, i.e. by copy/pasting its URL (https://dvserver.eu.ngrok.io/app/css/app.1ac68303.css) into the browser’s address field. Does that work or does it give you a 404 error?
Also, it would be helpful to see what the DT server log is reporting about successful and failed CSS requests. I don’t if and where this information is available, though, but @cgrunenberg might.
I do have a Synology NAS, and will see if I can work out how to do this over the weekend.
It does not work - only shows a very long page of code like this;
Thank you for your efforts giving such detailed information on CSS/CSP. I have read through the posts, and it sounds positive, but to be honest I have no idea where to find or how to edit the files which relate to this.
To be honest, I am not very knowledgeable in things like this - I can only fiddle around the edges and hope not to break stuff.…
I think if the reverse proxy idea does not work I will have to give this up.
It’s just so frustrating as it had worked fine for over 2 years and then suddenly this problem appeared.
It does in fact work because this is the stylesheet. And that is what you get when you use the URL “https://dvserver.eu.ngrok…” from the outside, not from inside your local network?
Than we’re back at the original error message: the MIME type send by the server is not “text/css” (which it should be) but rather “text/plain”. This could be tackled in two ways:
The second method should also involve fiddling with the server’s config file(s).
In any case, @cgrunenberg (or someone else from DEVONtechnologies) should weigh in here and provide some detail on if and how any of these modifications is possible.
The next release will fix the MIME type.
In that case I will wait for the next release and keep fingers crossed! Thanks again for all the help.
Just for info - it seems like this thread may have had a similar issue;
possible, although @rpallred’s browser did not show any error messages (or at least the screenshot didn’t show them)
