[cgalo5758]

Farm mode strips the port from the incoming Host header before building each site's url option. A farm running on a non-default port (e.g. http://site.localtest.me:8092 for local development) spawns sites that think their URL is http://site.localtest.me, so OAuth callbacks and trusted origins derived from argv.url point at port 80 and sign-on only works on the standard port.

This keeps the port when building newargv.url. incHost stays portless, so the allowed/wikiDomains checks and the data directory paths are unchanged. An explicit :80 or :443 is still dropped, same as defaultargs does for a standalone server, and anything that isn't a valid port number is ignored rather than passed into the URL. A farm on the standard port sees no change at all, since browsers omit the default port from the Host header.

This is also how the farm originally worked: farm.coffee kept the port in incHost and only stripped it for the data path (the incHost.split(':')[0] there is a leftover). The strip at the top came in with the restrict-farm-growth work (c655d0f) so hosts could be compared against data directory names, and those comparisons still see a portless host.

Tested with node --check and prettier --check; eslint output is unchanged. Running a farm with --port 8092, the spawned site's url now carries the port.

Companion change in wiki-security-social opens the sign-on dialog on the browser's port; together they make farm sign-on work on non-default http ports (extremely useful in local development or non-standard networking setups)

[WardCunningham]

Current practice has been to use ports to distinguish wiki-server implementations but not to distinguish collections of pages. For example: localhost and localhost:3000 would be served from different servers launched a different times from different places. but localhost/welcome-visitors.json and localhost:3000/welcome-visitors.json would serve the same page json.

I understand that the change here is intended to link sign on machinery to the server, not to distinguish distinct versions of page json or other per-site data saved in, say, state/owner.json.

Note: we have seen different sign on practices store different state in owner.json without confusion when we have migrated hosts to use different identity providers.

[cgalo5758]

Current practice has been to use ports to distinguish wiki-server implementations but not to distinguish collections of pages. For example: localhost and localhost:3000 would be served from different servers launched a different times from different places. but localhost/welcome-visitors.json and localhost:3000/welcome-visitors.json would serve the same page json.

I understand that the change here is intended to link sign on machinery to the server, not to distinguish distinct versions of page json or other per-site data saved in, say, state/owner.json.

Note: we have seen different sign on practices store different state in owner.json without confusion when we have migrated hosts to use different identity providers.

That's the intent, yes. The port only flows into newargv.url, which the sign-on machinery reads to learn the browser-facing address. The data directory is still keyed by the portless hostname (the incHost.split(':')[0] on the data path), so localhost and localhost:3000 keep resolving to the same page collection and the same status/owner.json. Nothing about how per-site data is located or stored changes; only the OAuth callback and origin URLs learn the port the browser is actually using.

[paul90]

Thanks @cgalo5758 for this and the associated security plugin which has also been merged.