JS endpoints white-/blacklist issues about docs HOT 6 CLOSED

Secure way to allow http:// and https:// without allowing URL prefixes or port suffixes:

"^(tcp|ssl)://example\.org:80$" instead of "example.org:80"

Allow any port without allowing TLD suffixes (e.g. .orgy instead of .org):

"^tcp://example\.org:" instead of "^tcp://example\.org"

user:pass@ not supported it seems:

require("internal").download("http://user:[email protected]:80")
Could not connect to 'http+tcp://user:0

from docs.

Should we specify the behavior and cases we want? Otherwise we come up with the next half-baked solution. And I would be in favor of dropping all the tcp+ssl nonsense and just support http, https, h2,h2c, vst, vst(s|c) like it is done in any other application. Yes It may be a breaking change and some people will have to fix some URLs. "But it has always been like that!" should not keep us from improving and having nice things.

from docs.

If no port specified in whitelist argument then it doesn't seem to match anything under Windows. Seems to work under Linux though, but needs retesting.

Can't reproduce it in v3.6.1 under Windows. It's possible that I specified the endpoint option with http:// instead of tcp://, in which case I expect that no address at all matches because it will be compared against tcp:// internally I suppose.

Need to add cross-references to arangod option pages to
https://www.arangodb.com/docs/stable/security-security-options.html#endpoint-access

from docs.

@ObiWahn I would like to see the protocol mess cleaned up, but that seems like a 4.0 project.

I'm really confused right now because the following doesn't work with 3.6.1 under Windows:

arangosh --javascript.endpoints-whitelist "ssl://arangodb\.com:443" --log.level security=debug

internal endpoints whitelist:(ssl://arangodb.com:443)

require("internal").download("https://arangodb.com:443") (also without :443)

stacktrace: ArangoError: not allowed to connect to this endpoint 😕

from docs.

Looks like the implementation was changed? https:// instead of ssl:// and the port is apparently no appended internally anymore?

from docs.

At least ssl:// seems buggy but http:// and https:// are now accepted and can be used to match URL paths as well.

from docs.