I’m trying to host the webapp (/index.htm) at a non-root location. This is part of a remote-access system, where the iotawatt is on a VPN and accessed via reverse-proxy.
So instead of http://iotawatt.local/index.htm it is accessed via http://server1.com/remote/site1/index.htm
Linked resources and XHR/JSON calls need to be http://server1.com/remote/site1/config.txt but currently the Javascript code calls (for example) http://server1.com/config.txt.
If I remove the “/” from all the relevant paths (eg var configNewURL = "config+1.txt"; # Note no /) it works ok. In particular, the config.txt file can be updated via /edit XHR call.
(Note that the /edit.htm ACE works-ish but fails on some files due to CORS problem. Likely fixable but low priority for me.)
This “relative-rooting” is consistent with the css loading (unchanged: <link rel="stylesheet" type="text/css" href="cnfstyle.css">). Hence css loads without problems from http://server1.com/remote/site1/cnfstyle.css.
I hope that makes sense!
So finally, my question: do you think this will break anything, or a bad idea for any reason? Modified file attached. Happy to try a PR.
index.htm (117.6 KB)
Not real clear on how it all fits together, but take a look at this and see if it resembles what you are doing.
As you can see I made progress up to a point, but then hit a wall and got very nervous about changing the basic way the file paths are specified. As the number of modules and changes to them mounted up, I realized there was no way to do the necessary testing required to ship that volume of changes.
I am thinking that it’s worth looking for a possible different way to do the reverse proxy that puts all of the changes into one place and only has the potential to affect someone using it.
Hiya. Yes, that is the same issue - I didn’t find it in my search. I’ve done a fair bit of research and checked what’s happening with firebug. I think I understand it but am no Nginx export. There are some possible solutions:
- host at root with separation via subdomains or ports: this is my limited workaround
- dynamic rewrite of paths: did a proof of concept with a python script but fragile, hard to make /edit config file saves work
- remove the “/” to make paths relative. as per the above, but I didn’t check graphs so, as you say, maybe more complex.
- grafana approach: config via .ini file (toggle for relative paths / absolute domain). Good for grafana but probably too complex.
I can’t see a nice solution which isolates the changes only proxy users.
One option might be just change index.htm as this is very simple and (I think) have no wider ramifications. It provides status/config changes but (maybe) not edit or graphs.