Should ports be considered as part of domain?

[stevage]

Currently, terriajs-server treats these as three different domains:

"foo",
"foo:80",
"foo:8000"

Is this a good thing? I found it very unintuitive when attempting to add a WMS server using a non-standard port. Couldn't work out why it wasn't being proxied.

[kring]

Certainly browsers consider these to be different hosts for CORS purposes, so I think it's reasonable that we do too. We could add a feature where * in place of the port means "any port" maybe?

[stevage]

Hmm, alternatively, "foo" could mean "all ports on foo", and "foo:80" could mean "only port 80". What would the downside of this be?

[kring]

Well if you ask me, we (NationalMap and our others apps) should just run an open proxy. The benefits substantially outweigh the risks IMO. But that's not a universal opinion. And similarly, people might argue that opening up all ports on a given host is riskier because it increases the likelihood of things like using our proxy to connect to a compromised server running on a non-standard port, or causing harm to a poorly written non-HTTP server by sending it craftily designed HTTP requests via our proxy.

So if you buy into that fear at all, you might also think that making it easy to (accidentally?) whitelist non-standard ports is a bad thing. I don't really feel strongly about it either way though.

[stevage]

Hmm, good thoughts. Another option that's just occurred to me would be to whitelist on the basis of the non-host part of the URL. For instance, whitelist any URL containing "wms" or "wfs" or "geojson" etc etc. That would make a pretty good default for most projects I think.

[RacingTadpole]

One thought - as a way of implementing steve's last point, we could allow an explicit wildcard such as *. Then the whitelist could include both csiro.au and *wms*.

[kring]

I think allowing *wms* is not much different from just having an open proxy. It's pretty easy to include a string like that someplace in just about any URL. But I do like the idea of filtering based on the content. i.e. ensure that the request looks like a valid GetCapabilities or GetMap and that the response is a proper WMS XML document. That's a fair bit of work though.

[x-Code-x]

Drive by comment FWIW :)

tl;dr:

• URI's are unique by definition
• URI schemes do include the authority portion
• Thus, if you currently have a policy which allows wildcards in the authority portion of the URI (e.g. .csiro.au, data.gov.), then by extension, that policy already covers wildcards for ports.
• x2 tl;dr on next para: maybe think about making an open proxy branch/deployment of Terria, and an AusGov security FTW version (which may be able to assume FedLink implementations talking to FedLinked data sources so all IP's are safe, and where wildcard ports may well be accepted for upstream sources, as long as downstream endpoints are locked to 80.

Long version

Re: Steve's first comment - overall that is a correct implementation of the standard afaik - they are indeed 3 different "things" (authorities in fact, which contain the same "foo" domain portion. Example 2 is however fact redundant (since default for HTTP is 80) in that foo and foo:80 de-reference to the same "thing". Note that 3986 states "URI producers and normalizers should omit the port component and its ":" delimiter if port is empty or if its value would be the same as that of the scheme's default." , however, it is a SHOULD, not MUST.

Now while the above tl;dr initial points might be technically correct (the best kind) against the RFC paste below - a harsh reality given how Terria apps are fast becoming a standard feature of the WoG open data ecosystem - your colleagues at Industry (namely Vanguard/AusKey etc) may have some very valid points around wild carding anything in the authority portion of the URI - namely - issues (technical or otherwise) around wild carded certificates etc - it's very much looking like agencies are more likely to want to explicitly name ports/defaults/sub-doms etc due to the troubles in managing certificate type things.

(All in all: just random drive by thoughts. Personal PoV and all that. Oh - Steve's points around whitelisting on the path - IMO that works, since those patterns are likely to be surprisingly standard moving forwards (thinking standard API patterns, standardised data.gov.au subdoms etc) which would allow for a lot of flexibility around say, running a federated Terria data provider network (a.k.a Government ;) )...

(Sorry - I should go for walks at lunch instead of reading GitHub updates)

C.

https://tools.ietf.org/html/rfc3986#section-3.2

Given authority = [ userinfo "@" ] host [ ":" port ]

3.2.3. Port
The port subcomponent of authority is designated by an optional port number in decimal following the host and delimited from it by a single colon (":") character.

     port        = *DIGIT

A scheme may define a default port. For example, the "http" scheme defines a default port of "80", corresponding to its reserved TCP port number. The type of port designated by the port number (e.g., TCP, UDP, SCTP) is defined by the URI scheme. URI producers and normalizers should omit the port component and its ":" delimiter if port is empty or if its value would be the same as that of the scheme's default.