-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should ports be considered as part of domain? #13
Comments
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? |
Hmm, alternatively, "foo" could mean "all ports on foo", and "foo:80" could mean "only port 80". What would the downside of this be? |
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. |
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.
|
One thought - as a way of implementing steve's last point, we could allow an explicit wildcard such as |
I think allowing |
Drive by comment FWIW :) tl;dr:
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
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. |
Currently, terriajs-server treats these as three different domains:
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.
The text was updated successfully, but these errors were encountered: