Change port 10080 to something else so Chrome doesn't block us about skotos HOT 11 CLOSED

Mentioning @saraht45 - this is the issue you were hitting.

from skotos.

I don't know if it matters but I only had this issue when connecting to my local server. I've had no issues connecting to vRWOT, Gables, or my VPS on this port.

from skotos.

I should check, but I don't think the current remote setup has you connect to port 10080 -- NGinX does that locally under the hood, which shouldn't affect Chrome in the slightest.

We removed NGinX from the local config, so Chrome connects directly to the websocket tunnel. So in the local config, we have to care whether it likes the port number.

from skotos.

Ah, right, we do have NGinX connect to a weird port, but it's 10803 rather than 10080. I should fix that so that we're connecting to port 443 -- then we won't have to worry if somebody else comes up with a service that runs on port 10803 and Chrome decides it's a security risk.

from skotos.

Weighing in here port 10XXX is the series that the skotos guys picked for Gables back in the day, it has no special meaning outside of that context.

That said, the concept of 10000 being the portbase everything else depends on is still important so make sure that if you change this, anything else depending on it follows suit. Ideally this would be some sort of configuration knob that allows the rest of the codebase to just do a bit of arithmetic.

from skotos.

Yeah, there are a few options here. I don't want to bring back NGinX in the local config (though that would definitely solve it.) But I could add another tunnel-or-similar to forward traffic to port 10080 from some other port -- basically add an HTTP-alike port via duplication.

from skotos.

I think that the adjustability of the ports has a direct link with the "portbase" setting in the internal config file. That's where I found it in the first place. 10080 is definitely adjustable internally and in fact IIRC the internal binding of the HTTP port is based directly on this via "80 + <portbase>"

from skotos.

I wanted to point out that portbase and with it the HTTP port is meant to be adjusted

from skotos.

Definitely possible to adjust the portbase. The basic problem here is that a lot of ports are previously claimed. I could adjust the portbase to, say, 11000 rather than 10000. And it's fine as long as we don't run afoul of a port for some other service. Right now that would be fine - it looks like we literally picked the only port above the 6000-range that Chrome considers unsafe for our HTTP port (bad port list: https://superuser.com/questions/188058/which-ports-are-considered-unsafe-by-chrome). But if we have to adjust everything in a block with portbase then if Chrome ever decides a different port is unsafe then we have to move everything -- in DGD, but also in any other scripts that use port numbers (websocket tunnel configs, dev setup, Wafer setup, stackscripts, thin-auth URLs, etc.)

So it seems convenient to me to have a way to replicate just one port. I also don't really want the dev and prod configs to have different portbases since it makes it hard to share scripts between them (e.g. the "see if DGD has finished booting yet" script, which needs to the DGD HTTP port number.)

from skotos.

In the interests of proper computer science, I would like to insist that this "relative dependency" on the port base be honored to avoid further complications, since the base skotos codebase was designed on this being a configurable point.

My advice is to have some way for the same configurability on the other side.

Try to make everything that depends on the port numbers just as configurable, best of all is if you could have some sort of automated way to reflect the portbase item from the config to whatever needs it outside of the DGD instance.

My opinion is that no scripts should themselves be using direct port numbers in the first place, that's a dependency violation and it is brittle, because it's effectively hard coding a constant on something that should rather be defined by a macro, so to speak.

I don't know exactly how the scripts are being implemented but I strongly suggest that they be configurable in the same way by having some sort of arithmetically derived offset from a configurable port base, so that they can flexibly keep parity with the internal portbase config being used by Skotoslib.

from skotos.

I don't want the configs to have different portbases either, but I also don't think the portbases should be being hardcoded at all in the first place.

That's the main point I am seeing that I have a contention with. At the very least having some sort of central macro that can be configured in one place and then have some sort of...I dunno, preprocessor style things to automatically use that to derive all the other port numbers would be best IMO.

I kinda lost track of what is actually being implemented, I kinda burned out after the initial public release. Could you clue me in on where I should look for the implemetnation? Or would you rather I look for myself?

I'm just speaking on sound principles of computer science, at least from what I've observed as apparent best practice in other codebases.

from skotos.