dotasek

Relevant: https://stackoverflow.com/questions/16697939/communicating-from-https-website-to-http-server-on-localhost-cross-domain https://stackoverflow.com/questions/6793174/third-party-signed-ssl-certificate-for-localhost-or-127-0-0-1 And a thread about the relevant security issues: https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/eV89JXcsBC0

For the above solution (having a cytoscape.org subdomain registered with a CA, and having that subdomain registered in a DNS as 127.0.0.1) there are some major problems. The primary one,...

The final nail in the coffin for the DNS/127.0.0.1 approach is that letsencrypt specifically says not to do it: https://letsencrypt.org/docs/certificates-for-localhost/

The ray of light here is that 127.0.0.1 is treated very differently than localhost. This is also specified in https://letsencrypt.org/docs/certificates-for-localhost/ which references a w3.org Candidate Recommendation which singles out 127.0.0.1...

Edge appears to have addressed this issue: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/11963735/ I am updating my edge version to see if this is the case.

Related issues in chromium and firefox: https://chromium.googlesource.com/chromium/src.git/+/130ee686fa00b617bfc001ceb3bb49782da2cb4e https://bugzilla.mozilla.org/show_bug.cgi?id=903966

After edge update (to version 42.17134.1.0) is confirmed to be able to access 127.0.0.1 from an https page.

~WebKit (Safari) is apparently in the WONT FIX camp: https://bugs.webkit.org/show_bug.cgi?id=171934~

WebKit (Safari) has re-opened the bug, but it isn't resolved: https://bugs.webkit.org/show_bug.cgi?id=171934

The nodeList in the best-case automation scenario is treated as a String that needs to be parsed and formatted within R or Python, with special-case values. I'm suggesting an approach...