Custom hostname

[serk12]

Hello all, we started to introduce Jasmine for our testing. But, we need a custom hostname, like in Karma. I took a look to the code and it was quite easy to implement, let me now if I missed anything.

[sgravrock]

Thanks for the PR. In principle I'm happy to have this feature, but I'm concerned that it could be a bit of a support burden unless some work is done to make users aware of HSTS preloading issues. The first few hostnames I tried (e.g. "foo") all caused Firefox, Chrome, and Safari to redirect from HTTP to HTTPS. When I ran jasmine-browser-runner serve and visited the spec runner page manually, it wasn't too hard to figure out what went wrong. But when I ran jasmine-browser-runner runSpecs I got this output:

WebDriverError: unknown error: net::ERR_SSL_PROTOCOL_ERROR
  (Session info: chrome=120.0.6099.234)
    at Object.throwDecodedError ([...]/node_modules/selenium-webdriver/lib/error.js:524:15)
    at parseHttpResponse ([...]/node_modules/selenium-webdriver/lib/http.js:601:13)
    at Executor.execute ([...]/node_modules/selenium-webdriver/lib/http.js:529:28)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async thenableWebDriverProxy.execute ([...]/node_modules/selenium-webdriver/lib/webdriver.js:745:17)
    at async Runner.run ([...]/lib/runner.js:103:5)
    at async Object.runSpecs ([...]/index.js:119:25)
    at async Command.runSpecs ([...]/lib/command.js:192:5) {
  remoteStacktrace: '0   chromedriver                        0x0000000100fbc4dc chromedriver + 4162780\n' +
    '1   chromedriver                        0x0000000100fb4664 chromedriver + 4130404\n' +
    '2   chromedriver                        0x0000000100c0bbc0 chromedriver + 293824\n' +
    '3   chromedriver                        0x0000000100c04324 chromedriver + 262948\n' +
    '4   chromedriver                        0x0000000100bf5c7c chromedriver + 203900\n' +
    '5   chromedriver                        0x0000000100bf4a98 chromedriver + 199320\n' +
    '6   chromedriver                        0x0000000100bf3b24 chromedriver + 195364\n' +
    '7   chromedriver                        0x0000000100bf3ad0 chromedriver + 195280\n' +
    '8   chromedriver                        0x0000000100bf1e3c chromedriver + 187964\n' +
    '9   chromedriver                        0x0000000100bf29fc chromedriver + 190972\n' +
    '10  chromedriver                        0x0000000100c0e5d8 chromedriver + 304600\n' +
    '11  chromedriver                        0x0000000100c920b8 chromedriver + 843960\n' +
    '12  chromedriver                        0x0000000100c91ab0 chromedriver + 842416\n' +
    '13  chromedriver                        0x0000000100c456bc chromedriver + 530108\n' +
    '14  chromedriver                        0x0000000100c46930 chromedriver + 534832\n' +
    '15  chromedriver                        0x0000000100f81e08 chromedriver + 3923464\n' +
    '16  chromedriver                        0x0000000100f863dc chromedriver + 3941340\n' +
    '17  chromedriver                        0x0000000100f6a038 chromedriver + 3825720\n' +
    '18  chromedriver                        0x0000000100f86f3c chromedriver + 3944252\n' +
    '19  chromedriver                        0x0000000100f5c6f4 chromedriver + 3770100\n' +
    '20  chromedriver                        0x0000000100fa3980 chromedriver + 4061568\n' +
    '21  chromedriver                        0x0000000100fa3af8 chromedriver + 4061944\n' +
    '22  chromedriver                        0x0000000100fb42e4 chromedriver + 4129508\n' +
    '23  libsystem_pthread.dylib             0x00000001bc8a426c _pthread_start + 148\n' +
    '24  libsystem_pthread.dylib             0x00000001bc89f08c thread_start + 8\n'
}

which isn't exactly ideal.

I think this is a fine implementation of the first 80% of the work needed to ship this feature, but before it could ship we'd also need the second 80%:

• Handling the above error in a more user-friendly way, in all supported browsers
• Documenting the feature and its pitfalls in the README
• Updating lib/types.js. (The API reference docs are generated from that file: https://jasmine.github.io/api/browser-runner/edge/module-jasmine-browser-runner )

[serk12]

Thanks sgravrock, can you share your json config? I can't replicate your error. Also, I'm in Linux, which OS are you?

[sgravrock]

Here's a config that reproduces the problem in Chrome and Firefox on Mac OS and Windows:

{
  "srcDir": "src",
  "srcFiles": [
    "**/*.js"
  ],
  "specDir": "spec",
  "specFiles": [
    "**/*[sS]pec.js"
  ],
  "helpers": [
    "helpers/**/*.js"
  ],
  "hostname": "foo",
  "browser": {
    "name": "chrome"
  }
}

On Debian 11, I was able to get HSTS redirects to happen for specific hostnames like play.google.com but not for any gTLDs. I saw the same behavior in both Chrome and Firefox.

[joeyparrish]

Thanks for the PR. In principle I'm happy to have this feature, but I'm concerned that it could be a bit of a support burden unless some work is done to make users aware of HSTS preloading issues. The first few hostnames I tried (e.g. "foo") all caused Firefox, Chrome, and Safari to redirect from HTTP to HTTPS. When I ran jasmine-browser-runner serve and visited the spec runner page manually, it wasn't too hard to figure out what went wrong. But when I ran jasmine-browser-runner runSpecs I got this output:

Hi @sgravrock! I'm very interested in this PR. Setting its other quality issues aside, the HSTS preload problem described above seems like it might actually be a Chrome bug. They have "foo" in the list, even though it is not a valid public name: https://hstspreload.org/?domain=foo

But I found that it is actually a TLD owned by Google which requires https on all domains: https://security.googleblog.com/2017/09/broadening-hsts-to-secure-more-of-web.html

I think it may be a Chrome bug that they treat the bare name "foo" as a TLD, even when used without a subdomain. I'll file a bug with them about this. Here is the relevant data used by Chrome for HSTS: https://raw.githubusercontent.com/chromium/chromium/main/net/http/transport_security_state_static.json

At the very least we can document that there may surprising, stupid TLDs in that list that will cause things to break if you use them as local network hostnames. It would be ideal to also deal with the friendliness of the error as well. I'll see if I can contribute to that.

My interest here is that we need both hostname settings and TLS in order to do testing of secure-context-requiring web APIs in a test lab. In our case, we will use a real hostname that resolves in public DNS, and real certs that match. And all of this is ultimately to replace Karma, which we had spent years building tons of customizations and plugins for... 😭

[sgravrock]

Closing since #49 got to a merge-able state first. Thanks again for the contribution.