Difference: WebSampHttps (1 vs. 25)

Revision 252024-05-21 - StephaneErard

 
META TOPICPARENT name="SampInfo"

Web SAMP and HTTPS

Problem

The SAMP Web Profile allows web applications to talk to other SAMP clients, communicating with the Hub using an XMLHttpRequest to a well-known port (21012) on the local host. There are problems with doing this if the web page hosting the web application is served from HTTPS rather than HTTP, since access to the hub URL http://localhost:21012/ counts (at least in some interpretations) as mixed active content, which is generally blocked by browsers. This issue has been known since 2014, but is becoming more pressing as more data providers use HTTPS for service delivery. See Presentation at Sydney Interop (2015) for more details.

Bad solution

A possible solution was proposed that defines a new Profile involving use of an external Relay service and abuse of mixed passive content to bootstrap communications, as described in Taylor presentation at Cape Town Interop (2016). This has been shown to work, e.g. it is currently deployed at ASI-SSDC based on a custom/prototype JSAMP hub, see Verrecchia presentation at Paris Interop (2019). This solution however is not elegant, efficient, robust or nice. There is some more discussion of this as well as alternative bad solutions in https://arxiv.org/abs/1912.00917 (presented by Taylor at ADASS 2019; this paper is now mostly obsolete).

Good solution?

Following discussion at Groningen Interop (2019), some more progress was made that could get HTTPS-based web applications to use the Web Profile as it stands:

  • Felix Stoehr pointed out that in recent tests, this just works in some browsers anyway, i.e. the problem has just gone away. This was a surprise, that arises from changes to the various w3c security standards over the last few years (see analysis).
  • Sonia Zorba prepared a browser extension samp-browser-extension for browsers that still have problems with this
These two developments may provide a good-enough solution to this problem; some (hopefully increasingly many) browsers will work anyway, and for others users can be encouraged to install a browser extension that will make them work.

Current status

We are assessing which browsers now support Web SAMP over HTTPS without making any special arrangements. I believe those that do, do so because of browser implementation of the W3C Secure Contexts document. Thanks to those who have tried out browser/OS combinations following the instructions below. The headline results seem to be:

  • Recent versions of Firefox, Chrome, Edge: SAMP over HTTPS works with no problems
  • Safari: SAMP over HTTPS doesn't work (see here for long and acrimonious discussion - may change eventually? MarkTaylor - 2024-03-11 )
  • Others: Vivaldi works. Luakit works. Internet Explorer: not sure.
  • ... but there are apparently exceptions; I've highlighted these in the table
The OS doesn't seem to make a difference (Linux, MacOS, Windows 10 all tried).

This looks quite positive; services may decide on that basis that it's worth providing Web SAMP in HTTPS-based services on the basis that they will work for many/most users. Optionally, they could provide the browser extensions for others.

Deleted:
<
<
 

You can try this out using your browser/OS combination(s):

To work out the status of HTTPS+SAMP on your browser/OS, follow these easy instructions:

  1. Start a SAMP Hub+client on your machine (e.g. run TOPCAT)
  2. Visit this HTTP page. Click the button.
    • A popup should appear asking you to allow SAMP registration from a web application (with an http://... Origin). Accept, and a table should be loaded in TOPCAT. (If this doesn't happen, your problems are not related to HTTPS)
  3. Visit this HTTPS page. Click the button.
    • Either as before, you are prompted to allow registration (for a web app with an https://... Origin) and a table is loaded in TOPCAT as before - this means SAMP+HTTPS does work on your browser
    • Or nothing happens - this means SAMP+HTTPS does not work on your browser.
  4. Record in the table below whether it did or didn't work ("yes" or "no" in the Works out of the box? column)
If you've done that but don't have easy write access to the wiki, you can mail your results to either m.b.taylor@bristol.ac.uk or apps-samp@ivoa.net.

(If you want to try some more interesting examples, including 2-way communications, others are available: HTTP / HTTPS. I'm expecting that if HTTPS works/fails for one SAMP example it will be the same for all, but if you find different, please report it).

Results: some anomalous outcomes are highlighted

HTTPS + SAMP Survey
Browser Version OS Works out of the box? Reporter
Chrome 77 Ubuntu yes Felix Stoehr
Chromium 78.0 Ubuntu yes Mark Taylor
Chromium 85.0 Ubuntu yes Mark Taylor
Firefox 70.0.1 OSX Mojave yes Felix Stoehr
Firefox 70.0 Ubuntu no Felix Stoehr
Firefox 59 RHEL6 no Mark Taylor
Firefox 70.0.1 Ubuntu no Mark Taylor
Firefox 81.0 Ubuntu yes Mark Taylor
Firefox Nightly 75.0 (64-bit) GUIX yes Hugo Buddelmeijer
Chrome 85.0 MacOS 10.13.6 yes Thomas Boch
Firefox 81.0 MacOS 10.13.6 yes Thomas Boch
Safari 13.1.2 MacOS 10.13.6 no Thomas Boch
Chrome 85.0 Fedora 31 yes Marco Molinaro
Firefox 80.0 Fedora 31 yes Marco Molinaro
Chrome 85.0. MacOS 10.11.3 yes Susana Sánchez Expósito
Firefox 78.2 MacOS 10.11.3 yes Susana Sánchez Expósito
Safari 9.0.3 MacOS 10.11.3 No Susana Sánchez Expósito
Firefox 81.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Chrome 85.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Safari 13.1 MacOS 10.14.6 No Susana Sánchez Expósito
Firefox 86.0.1 MacOS 10.14.6 Yes Stéphane Erard
Safari 13.1.2 MacOS 10.14.6 No Stéphane Erard
Chrome 89.0.4389.90 MacOS 10.14.6 Yes Stéphane Erard
Added:
>
>
Firefox 115.11.0esr (64 bits) MacOS 14.4.1 Yes Stéphane Erard
 
Firefox 81.0(64 bits) Ubuntu 20.04.1 LTS yes Regis Haigron
Firefox 80 Windows 10 yes Regis Haigron
Firefox 81.0(64 bits) Ubuntu 18.04.1 LTS yes Pierre Le Sidaner
Chrome 86.0.4240.75 Ubuntu 18.04.1 LTS Yes Pierre Le Sidaner
Vivaldi 3.3.2022.47 Ubuntu 18.04.1 LTS Yes Pierre Le Sidaner
Chrome 84.0.4147.125 MacOS 10.12.5 Yes Juan Carlos Segovia
Safari 10.1.1 MacOS 10.12.5 No Juan Carlos Segovia
Firefox 75.0 MacOS 10.12.5 Yes Juan Carlos Segovia
Chrome 57.0 MacOS 10.12.6 Yes Alcione Mora
Safari 11.0.2 MacOS 10.12.6 Yes Alcione Mora
Firefox 69.0 MacOS 10.12.6 Yes Alcione Mora
Chrome 86.0 MacOS 10.14.6 Yes Hector Canovas
Safari 12.1.2 MacOS 10.14.6 No Hector Canovas
Firefox 81.0.1 MacOS 10.14.6 No Hector Canovas
Edge 86.0 Windows 10.0 Yes Mark Taylor
Chrome 86.0.4240.80 MacOS 10.13.6 Yes Tom Donaldson
Firefox 81.0.2 MacOS 10.13.6 Yes Tom Donaldson
Safari 13.1.2 MacOS 10.13.6 No Tom Donaldson
Luakit 2.0.0 Debian buster Yes Markus
Internet Explorer 11.0.9600.19867 Windows Server 2012 R2 Standard No Yan Grange
Internet Explorer 11.1198.18362.0 Windows 10 1909 Yes Yan Grange
Edge 87.0.664.47 Windows 10 1909 Yes Yan Grange
Internet Explorer 11.630.19041.0 Windows 10 19041 No? Mark Taylor
Safari 13.1.2 MacOS 10.13.6 No Baptiste Cecconi
Firefox 89.0.1 MacOS 10.13.6 Yes Baptiste Cecconi
Chrome 91.0.4472.114 MacOS 10.13.6 Yes Baptiste Cecconi
Safari 14.1.2 macOS 11.5.1 No John Swinbank
Safari Technology Preview Release 128 (Safari 15.0) macOS 11.5.1 No John Swinbank
Firefox 90.0.2 (64-bit) macOS 11.5.1 Yes John Swinbank
Safari Technology Preview Release 132 (Safari 15.4) macOS 11.6 No John Swinbank
Safari 15.3 macOS 12.2.1 No Hendrik Heinl
Changed:
<
<
Arc 1.12.1 (42373) MacOS 13.6 No (HTTP does not work, HTTPS does) Yan Grange
>
>
Arc 1.12.1 (42373) MacOS 13.6 No (HTTP does not work, HTTPS does) Yan Grange
 For more discussion on this topic, see the apps-samp mailing list.

-- MarkTaylor - 2020-10-13

Deleted:
<
<

Revision 242024-03-27 - MarkTaylor

 
META TOPICPARENT name="SampInfo"

Web SAMP and HTTPS

Problem

The SAMP Web Profile allows web applications to talk to other SAMP clients, communicating with the Hub using an XMLHttpRequest to a well-known port (21012) on the local host. There are problems with doing this if the web page hosting the web application is served from HTTPS rather than HTTP, since access to the hub URL http://localhost:21012/ counts (at least in some interpretations) as mixed active content, which is generally blocked by browsers. This issue has been known since 2014, but is becoming more pressing as more data providers use HTTPS for service delivery. See Presentation at Sydney Interop (2015) for more details.

Bad solution

A possible solution was proposed that defines a new Profile involving use of an external Relay service and abuse of mixed passive content to bootstrap communications, as described in Taylor presentation at Cape Town Interop (2016). This has been shown to work, e.g. it is currently deployed at ASI-SSDC based on a custom/prototype JSAMP hub, see Verrecchia presentation at Paris Interop (2019). This solution however is not elegant, efficient, robust or nice. There is some more discussion of this as well as alternative bad solutions in https://arxiv.org/abs/1912.00917 (presented by Taylor at ADASS 2019; this paper is now mostly obsolete).

Good solution?

Following discussion at Groningen Interop (2019), some more progress was made that could get HTTPS-based web applications to use the Web Profile as it stands:

  • Felix Stoehr pointed out that in recent tests, this just works in some browsers anyway, i.e. the problem has just gone away. This was a surprise, that arises from changes to the various w3c security standards over the last few years (see analysis).
  • Sonia Zorba prepared a browser extension samp-browser-extension for browsers that still have problems with this
These two developments may provide a good-enough solution to this problem; some (hopefully increasingly many) browsers will work anyway, and for others users can be encouraged to install a browser extension that will make them work.

Current status

Changed:
<
<
We are assessing which browsers now support Web SAMP over HTTPS without making any special arrangements. Thanks to those who have tried out browser/OS combinations following the instructions below. The headline results seem to be:
>
>
We are assessing which browsers now support Web SAMP over HTTPS without making any special arrangements. I believe those that do, do so because of browser implementation of the W3C Secure Contexts document. Thanks to those who have tried out browser/OS combinations following the instructions below. The headline results seem to be:
 
  • Recent versions of Firefox, Chrome, Edge: SAMP over HTTPS works with no problems
  • Safari: SAMP over HTTPS doesn't work (see here for long and acrimonious discussion - may change eventually? MarkTaylor - 2024-03-11 )
  • Others: Vivaldi works. Luakit works. Internet Explorer: not sure.
  • ... but there are apparently exceptions; I've highlighted these in the table
The OS doesn't seem to make a difference (Linux, MacOS, Windows 10 all tried).

This looks quite positive; services may decide on that basis that it's worth providing Web SAMP in HTTPS-based services on the basis that they will work for many/most users. Optionally, they could provide the browser extensions for others.

You can try this out using your browser/OS combination(s):

To work out the status of HTTPS+SAMP on your browser/OS, follow these easy instructions:

  1. Start a SAMP Hub+client on your machine (e.g. run TOPCAT)
  2. Visit this HTTP page. Click the button.
    • A popup should appear asking you to allow SAMP registration from a web application (with an http://... Origin). Accept, and a table should be loaded in TOPCAT. (If this doesn't happen, your problems are not related to HTTPS)
  3. Visit this HTTPS page. Click the button.
    • Either as before, you are prompted to allow registration (for a web app with an https://... Origin) and a table is loaded in TOPCAT as before - this means SAMP+HTTPS does work on your browser
    • Or nothing happens - this means SAMP+HTTPS does not work on your browser.
  4. Record in the table below whether it did or didn't work ("yes" or "no" in the Works out of the box? column)
If you've done that but don't have easy write access to the wiki, you can mail your results to either m.b.taylor@bristol.ac.uk or apps-samp@ivoa.net.

(If you want to try some more interesting examples, including 2-way communications, others are available: HTTP / HTTPS. I'm expecting that if HTTPS works/fails for one SAMP example it will be the same for all, but if you find different, please report it).

Results: some anomalous outcomes are highlighted

HTTPS + SAMP Survey
Browser Version OS Works out of the box? Reporter
Chrome 77 Ubuntu yes Felix Stoehr
Chromium 78.0 Ubuntu yes Mark Taylor
Chromium 85.0 Ubuntu yes Mark Taylor
Firefox 70.0.1 OSX Mojave yes Felix Stoehr
Firefox 70.0 Ubuntu no Felix Stoehr
Firefox 59 RHEL6 no Mark Taylor
Firefox 70.0.1 Ubuntu no Mark Taylor
Firefox 81.0 Ubuntu yes Mark Taylor
Firefox Nightly 75.0 (64-bit) GUIX yes Hugo Buddelmeijer
Chrome 85.0 MacOS 10.13.6 yes Thomas Boch
Firefox 81.0 MacOS 10.13.6 yes Thomas Boch
Safari 13.1.2 MacOS 10.13.6 no Thomas Boch
Chrome 85.0 Fedora 31 yes Marco Molinaro
Firefox 80.0 Fedora 31 yes Marco Molinaro
Chrome 85.0. MacOS 10.11.3 yes Susana Sánchez Expósito
Firefox 78.2 MacOS 10.11.3 yes Susana Sánchez Expósito
Safari 9.0.3 MacOS 10.11.3 No Susana Sánchez Expósito
Firefox 81.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Chrome 85.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Safari 13.1 MacOS 10.14.6 No Susana Sánchez Expósito
Firefox 86.0.1 MacOS 10.14.6 Yes Stéphane Erard
Safari 13.1.2 MacOS 10.14.6 No Stéphane Erard
Chrome 89.0.4389.90 MacOS 10.14.6 Yes Stéphane Erard
Firefox 81.0(64 bits) Ubuntu 20.04.1 LTS yes Regis Haigron
Firefox 80 Windows 10 yes Regis Haigron
Firefox 81.0(64 bits) Ubuntu 18.04.1 LTS yes Pierre Le Sidaner
Chrome 86.0.4240.75 Ubuntu 18.04.1 LTS Yes Pierre Le Sidaner
Vivaldi 3.3.2022.47 Ubuntu 18.04.1 LTS Yes Pierre Le Sidaner
Chrome 84.0.4147.125 MacOS 10.12.5 Yes Juan Carlos Segovia
Safari 10.1.1 MacOS 10.12.5 No Juan Carlos Segovia
Firefox 75.0 MacOS 10.12.5 Yes Juan Carlos Segovia
Chrome 57.0 MacOS 10.12.6 Yes Alcione Mora
Safari 11.0.2 MacOS 10.12.6 Yes Alcione Mora
Firefox 69.0 MacOS 10.12.6 Yes Alcione Mora
Chrome 86.0 MacOS 10.14.6 Yes Hector Canovas
Safari 12.1.2 MacOS 10.14.6 No Hector Canovas
Firefox 81.0.1 MacOS 10.14.6 No Hector Canovas
Edge 86.0 Windows 10.0 Yes Mark Taylor
Chrome 86.0.4240.80 MacOS 10.13.6 Yes Tom Donaldson
Firefox 81.0.2 MacOS 10.13.6 Yes Tom Donaldson
Safari 13.1.2 MacOS 10.13.6 No Tom Donaldson
Luakit 2.0.0 Debian buster Yes Markus
Internet Explorer 11.0.9600.19867 Windows Server 2012 R2 Standard No Yan Grange
Internet Explorer 11.1198.18362.0 Windows 10 1909 Yes Yan Grange
Edge 87.0.664.47 Windows 10 1909 Yes Yan Grange
Internet Explorer 11.630.19041.0 Windows 10 19041 No? Mark Taylor
Safari 13.1.2 MacOS 10.13.6 No Baptiste Cecconi
Firefox 89.0.1 MacOS 10.13.6 Yes Baptiste Cecconi
Chrome 91.0.4472.114 MacOS 10.13.6 Yes Baptiste Cecconi
Safari 14.1.2 macOS 11.5.1 No John Swinbank
Safari Technology Preview Release 128 (Safari 15.0) macOS 11.5.1 No John Swinbank
Firefox 90.0.2 (64-bit) macOS 11.5.1 Yes John Swinbank
Safari Technology Preview Release 132 (Safari 15.4) macOS 11.6 No John Swinbank
Safari 15.3 macOS 12.2.1 No Hendrik Heinl
Arc 1.12.1 (42373) MacOS 13.6 No (HTTP does not work, HTTPS does) Yan Grange
For more discussion on this topic, see the apps-samp mailing list.

-- MarkTaylor - 2020-10-13

Added:
>
>

Revision 232024-03-11 - MarkTaylor

 
META TOPICPARENT name="SampInfo"

Web SAMP and HTTPS

Problem

The SAMP Web Profile allows web applications to talk to other SAMP clients, communicating with the Hub using an XMLHttpRequest to a well-known port (21012) on the local host. There are problems with doing this if the web page hosting the web application is served from HTTPS rather than HTTP, since access to the hub URL http://localhost:21012/ counts (at least in some interpretations) as mixed active content, which is generally blocked by browsers. This issue has been known since 2014, but is becoming more pressing as more data providers use HTTPS for service delivery. See Presentation at Sydney Interop (2015) for more details.

Bad solution

A possible solution was proposed that defines a new Profile involving use of an external Relay service and abuse of mixed passive content to bootstrap communications, as described in Taylor presentation at Cape Town Interop (2016). This has been shown to work, e.g. it is currently deployed at ASI-SSDC based on a custom/prototype JSAMP hub, see Verrecchia presentation at Paris Interop (2019). This solution however is not elegant, efficient, robust or nice. There is some more discussion of this as well as alternative bad solutions in https://arxiv.org/abs/1912.00917 (presented by Taylor at ADASS 2019; this paper is now mostly obsolete).

Good solution?

Following discussion at Groningen Interop (2019), some more progress was made that could get HTTPS-based web applications to use the Web Profile as it stands:

  • Felix Stoehr pointed out that in recent tests, this just works in some browsers anyway, i.e. the problem has just gone away. This was a surprise, that arises from changes to the various w3c security standards over the last few years (see analysis).
  • Sonia Zorba prepared a browser extension samp-browser-extension for browsers that still have problems with this
These two developments may provide a good-enough solution to this problem; some (hopefully increasingly many) browsers will work anyway, and for others users can be encouraged to install a browser extension that will make them work.

Current status

We are assessing which browsers now support Web SAMP over HTTPS without making any special arrangements. Thanks to those who have tried out browser/OS combinations following the instructions below. The headline results seem to be:

  • Recent versions of Firefox, Chrome, Edge: SAMP over HTTPS works with no problems
Changed:
<
<
  • Safari: SAMP over HTTPS doesn't work
>
>
  • Safari: SAMP over HTTPS doesn't work (see here for long and acrimonious discussion - may change eventually? MarkTaylor - 2024-03-11 )
 
  • Others: Vivaldi works. Luakit works. Internet Explorer: not sure.
  • ... but there are apparently exceptions; I've highlighted these in the table
The OS doesn't seem to make a difference (Linux, MacOS, Windows 10 all tried).

This looks quite positive; services may decide on that basis that it's worth providing Web SAMP in HTTPS-based services on the basis that they will work for many/most users. Optionally, they could provide the browser extensions for others.

Added:
>
>
 

You can try this out using your browser/OS combination(s):

To work out the status of HTTPS+SAMP on your browser/OS, follow these easy instructions:

  1. Start a SAMP Hub+client on your machine (e.g. run TOPCAT)
  2. Visit this HTTP page. Click the button.
    • A popup should appear asking you to allow SAMP registration from a web application (with an http://... Origin). Accept, and a table should be loaded in TOPCAT. (If this doesn't happen, your problems are not related to HTTPS)
  3. Visit this HTTPS page. Click the button.
    • Either as before, you are prompted to allow registration (for a web app with an https://... Origin) and a table is loaded in TOPCAT as before - this means SAMP+HTTPS does work on your browser
    • Or nothing happens - this means SAMP+HTTPS does not work on your browser.
  4. Record in the table below whether it did or didn't work ("yes" or "no" in the Works out of the box? column)
If you've done that but don't have easy write access to the wiki, you can mail your results to either m.b.taylor@bristol.ac.uk or apps-samp@ivoa.net.

(If you want to try some more interesting examples, including 2-way communications, others are available: HTTP / HTTPS. I'm expecting that if HTTPS works/fails for one SAMP example it will be the same for all, but if you find different, please report it).

Results: some anomalous outcomes are highlighted

HTTPS + SAMP Survey
Browser Version OS Works out of the box? Reporter
Chrome 77 Ubuntu yes Felix Stoehr
Chromium 78.0 Ubuntu yes Mark Taylor
Chromium 85.0 Ubuntu yes Mark Taylor
Firefox 70.0.1 OSX Mojave yes Felix Stoehr
Firefox 70.0 Ubuntu no Felix Stoehr
Firefox 59 RHEL6 no Mark Taylor
Firefox 70.0.1 Ubuntu no Mark Taylor
Firefox 81.0 Ubuntu yes Mark Taylor
Firefox Nightly 75.0 (64-bit) GUIX yes Hugo Buddelmeijer
Chrome 85.0 MacOS 10.13.6 yes Thomas Boch
Firefox 81.0 MacOS 10.13.6 yes Thomas Boch
Safari 13.1.2 MacOS 10.13.6 no Thomas Boch
Chrome 85.0 Fedora 31 yes Marco Molinaro
Firefox 80.0 Fedora 31 yes Marco Molinaro
Chrome 85.0. MacOS 10.11.3 yes Susana Sánchez Expósito
Firefox 78.2 MacOS 10.11.3 yes Susana Sánchez Expósito
Safari 9.0.3 MacOS 10.11.3 No Susana Sánchez Expósito
Firefox 81.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Chrome 85.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Safari 13.1 MacOS 10.14.6 No Susana Sánchez Expósito
Firefox 86.0.1 MacOS 10.14.6 Yes Stéphane Erard
Safari 13.1.2 MacOS 10.14.6 No Stéphane Erard
Chrome 89.0.4389.90 MacOS 10.14.6 Yes Stéphane Erard
Firefox 81.0(64 bits) Ubuntu 20.04.1 LTS yes Regis Haigron
Firefox 80 Windows 10 yes Regis Haigron
Firefox 81.0(64 bits) Ubuntu 18.04.1 LTS yes Pierre Le Sidaner
Chrome 86.0.4240.75 Ubuntu 18.04.1 LTS Yes Pierre Le Sidaner
Vivaldi 3.3.2022.47 Ubuntu 18.04.1 LTS Yes Pierre Le Sidaner
Chrome 84.0.4147.125 MacOS 10.12.5 Yes Juan Carlos Segovia
Safari 10.1.1 MacOS 10.12.5 No Juan Carlos Segovia
Firefox 75.0 MacOS 10.12.5 Yes Juan Carlos Segovia
Chrome 57.0 MacOS 10.12.6 Yes Alcione Mora
Safari 11.0.2 MacOS 10.12.6 Yes Alcione Mora
Firefox 69.0 MacOS 10.12.6 Yes Alcione Mora
Chrome 86.0 MacOS 10.14.6 Yes Hector Canovas
Safari 12.1.2 MacOS 10.14.6 No Hector Canovas
Firefox 81.0.1 MacOS 10.14.6 No Hector Canovas
Edge 86.0 Windows 10.0 Yes Mark Taylor
Chrome 86.0.4240.80 MacOS 10.13.6 Yes Tom Donaldson
Firefox 81.0.2 MacOS 10.13.6 Yes Tom Donaldson
Safari 13.1.2 MacOS 10.13.6 No Tom Donaldson
Luakit 2.0.0 Debian buster Yes Markus
Internet Explorer 11.0.9600.19867 Windows Server 2012 R2 Standard No Yan Grange
Internet Explorer 11.1198.18362.0 Windows 10 1909 Yes Yan Grange
Edge 87.0.664.47 Windows 10 1909 Yes Yan Grange
Internet Explorer 11.630.19041.0 Windows 10 19041 No? Mark Taylor
Safari 13.1.2 MacOS 10.13.6 No Baptiste Cecconi
Firefox 89.0.1 MacOS 10.13.6 Yes Baptiste Cecconi
Chrome 91.0.4472.114 MacOS 10.13.6 Yes Baptiste Cecconi
Safari 14.1.2 macOS 11.5.1 No John Swinbank
Safari Technology Preview Release 128 (Safari 15.0) macOS 11.5.1 No John Swinbank
Firefox 90.0.2 (64-bit) macOS 11.5.1 Yes John Swinbank
Safari Technology Preview Release 132 (Safari 15.4) macOS 11.6 No John Swinbank
Safari 15.3 macOS 12.2.1 No Hendrik Heinl
Arc 1.12.1 (42373) MacOS 13.6 No (HTTP does not work, HTTPS does) Yan Grange
For more discussion on this topic, see the apps-samp mailing list.

-- MarkTaylor - 2020-10-13

Revision 222023-10-18 - YanGrange

 
META TOPICPARENT name="SampInfo"

Web SAMP and HTTPS

Problem

The SAMP Web Profile allows web applications to talk to other SAMP clients, communicating with the Hub using an XMLHttpRequest to a well-known port (21012) on the local host. There are problems with doing this if the web page hosting the web application is served from HTTPS rather than HTTP, since access to the hub URL http://localhost:21012/ counts (at least in some interpretations) as mixed active content, which is generally blocked by browsers. This issue has been known since 2014, but is becoming more pressing as more data providers use HTTPS for service delivery. See Presentation at Sydney Interop (2015) for more details.

Bad solution

A possible solution was proposed that defines a new Profile involving use of an external Relay service and abuse of mixed passive content to bootstrap communications, as described in Taylor presentation at Cape Town Interop (2016). This has been shown to work, e.g. it is currently deployed at ASI-SSDC based on a custom/prototype JSAMP hub, see Verrecchia presentation at Paris Interop (2019). This solution however is not elegant, efficient, robust or nice. There is some more discussion of this as well as alternative bad solutions in https://arxiv.org/abs/1912.00917 (presented by Taylor at ADASS 2019; this paper is now mostly obsolete).

Good solution?

Following discussion at Groningen Interop (2019), some more progress was made that could get HTTPS-based web applications to use the Web Profile as it stands:

  • Felix Stoehr pointed out that in recent tests, this just works in some browsers anyway, i.e. the problem has just gone away. This was a surprise, that arises from changes to the various w3c security standards over the last few years (see analysis).
  • Sonia Zorba prepared a browser extension samp-browser-extension for browsers that still have problems with this
These two developments may provide a good-enough solution to this problem; some (hopefully increasingly many) browsers will work anyway, and for others users can be encouraged to install a browser extension that will make them work.

Current status

We are assessing which browsers now support Web SAMP over HTTPS without making any special arrangements. Thanks to those who have tried out browser/OS combinations following the instructions below. The headline results seem to be:

  • Recent versions of Firefox, Chrome, Edge: SAMP over HTTPS works with no problems
  • Safari: SAMP over HTTPS doesn't work
  • Others: Vivaldi works. Luakit works. Internet Explorer: not sure.
  • ... but there are apparently exceptions; I've highlighted these in the table
The OS doesn't seem to make a difference (Linux, MacOS, Windows 10 all tried).

This looks quite positive; services may decide on that basis that it's worth providing Web SAMP in HTTPS-based services on the basis that they will work for many/most users. Optionally, they could provide the browser extensions for others.

You can try this out using your browser/OS combination(s):

To work out the status of HTTPS+SAMP on your browser/OS, follow these easy instructions:

  1. Start a SAMP Hub+client on your machine (e.g. run TOPCAT)
  2. Visit this HTTP page. Click the button.
    • A popup should appear asking you to allow SAMP registration from a web application (with an http://... Origin). Accept, and a table should be loaded in TOPCAT. (If this doesn't happen, your problems are not related to HTTPS)
  3. Visit this HTTPS page. Click the button.
    • Either as before, you are prompted to allow registration (for a web app with an https://... Origin) and a table is loaded in TOPCAT as before - this means SAMP+HTTPS does work on your browser
    • Or nothing happens - this means SAMP+HTTPS does not work on your browser.
  4. Record in the table below whether it did or didn't work ("yes" or "no" in the Works out of the box? column)
If you've done that but don't have easy write access to the wiki, you can mail your results to either m.b.taylor@bristol.ac.uk or apps-samp@ivoa.net.

(If you want to try some more interesting examples, including 2-way communications, others are available: HTTP / HTTPS. I'm expecting that if HTTPS works/fails for one SAMP example it will be the same for all, but if you find different, please report it).

Results: some anomalous outcomes are highlighted

HTTPS + SAMP Survey
Browser Version OS Works out of the box? Reporter
Chrome 77 Ubuntu yes Felix Stoehr
Chromium 78.0 Ubuntu yes Mark Taylor
Chromium 85.0 Ubuntu yes Mark Taylor
Firefox 70.0.1 OSX Mojave yes Felix Stoehr
Firefox 70.0 Ubuntu no Felix Stoehr
Firefox 59 RHEL6 no Mark Taylor
Firefox 70.0.1 Ubuntu no Mark Taylor
Firefox 81.0 Ubuntu yes Mark Taylor
Firefox Nightly 75.0 (64-bit) GUIX yes Hugo Buddelmeijer
Chrome 85.0 MacOS 10.13.6 yes Thomas Boch
Firefox 81.0 MacOS 10.13.6 yes Thomas Boch
Safari 13.1.2 MacOS 10.13.6 no Thomas Boch
Chrome 85.0 Fedora 31 yes Marco Molinaro
Firefox 80.0 Fedora 31 yes Marco Molinaro
Chrome 85.0. MacOS 10.11.3 yes Susana Sánchez Expósito
Firefox 78.2 MacOS 10.11.3 yes Susana Sánchez Expósito
Safari 9.0.3 MacOS 10.11.3 No Susana Sánchez Expósito
Firefox 81.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Chrome 85.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Safari 13.1 MacOS 10.14.6 No Susana Sánchez Expósito
Firefox 86.0.1 MacOS 10.14.6 Yes Stéphane Erard
Safari 13.1.2 MacOS 10.14.6 No Stéphane Erard
Chrome 89.0.4389.90 MacOS 10.14.6 Yes Stéphane Erard
Firefox 81.0(64 bits) Ubuntu 20.04.1 LTS yes Regis Haigron
Firefox 80 Windows 10 yes Regis Haigron
Firefox 81.0(64 bits) Ubuntu 18.04.1 LTS yes Pierre Le Sidaner
Chrome 86.0.4240.75 Ubuntu 18.04.1 LTS Yes Pierre Le Sidaner
Vivaldi 3.3.2022.47 Ubuntu 18.04.1 LTS Yes Pierre Le Sidaner
Chrome 84.0.4147.125 MacOS 10.12.5 Yes Juan Carlos Segovia
Safari 10.1.1 MacOS 10.12.5 No Juan Carlos Segovia
Firefox 75.0 MacOS 10.12.5 Yes Juan Carlos Segovia
Chrome 57.0 MacOS 10.12.6 Yes Alcione Mora
Safari 11.0.2 MacOS 10.12.6 Yes Alcione Mora
Firefox 69.0 MacOS 10.12.6 Yes Alcione Mora
Chrome 86.0 MacOS 10.14.6 Yes Hector Canovas
Safari 12.1.2 MacOS 10.14.6 No Hector Canovas
Firefox 81.0.1 MacOS 10.14.6 No Hector Canovas
Edge 86.0 Windows 10.0 Yes Mark Taylor
Chrome 86.0.4240.80 MacOS 10.13.6 Yes Tom Donaldson
Firefox 81.0.2 MacOS 10.13.6 Yes Tom Donaldson
Safari 13.1.2 MacOS 10.13.6 No Tom Donaldson
Luakit 2.0.0 Debian buster Yes Markus
Internet Explorer 11.0.9600.19867 Windows Server 2012 R2 Standard No Yan Grange
Internet Explorer 11.1198.18362.0 Windows 10 1909 Yes Yan Grange
Edge 87.0.664.47 Windows 10 1909 Yes Yan Grange
Internet Explorer 11.630.19041.0 Windows 10 19041 No? Mark Taylor
Safari 13.1.2 MacOS 10.13.6 No Baptiste Cecconi
Firefox 89.0.1 MacOS 10.13.6 Yes Baptiste Cecconi
Chrome 91.0.4472.114 MacOS 10.13.6 Yes Baptiste Cecconi
Safari 14.1.2 macOS 11.5.1 No John Swinbank
Safari Technology Preview Release 128 (Safari 15.0) macOS 11.5.1 No John Swinbank
Firefox 90.0.2 (64-bit) macOS 11.5.1 Yes John Swinbank
Safari Technology Preview Release 132 (Safari 15.4) macOS 11.6 No John Swinbank
Safari 15.3 macOS 12.2.1 No Hendrik Heinl
Added:
>
>
Arc 1.12.1 (42373) MacOS 13.6 No (HTTP does not work, HTTPS does) Yan Grange
 For more discussion on this topic, see the apps-samp mailing list.

-- MarkTaylor - 2020-10-13

Revision 212023-04-26 - HendriklHein

 
META TOPICPARENT name="SampInfo"

Web SAMP and HTTPS

Problem

The SAMP Web Profile allows web applications to talk to other SAMP clients, communicating with the Hub using an XMLHttpRequest to a well-known port (21012) on the local host. There are problems with doing this if the web page hosting the web application is served from HTTPS rather than HTTP, since access to the hub URL http://localhost:21012/ counts (at least in some interpretations) as mixed active content, which is generally blocked by browsers. This issue has been known since 2014, but is becoming more pressing as more data providers use HTTPS for service delivery. See Presentation at Sydney Interop (2015) for more details.

Bad solution

Changed:
<
<
A possible solution was proposed that defines a new Profile involving use of an external Relay service and abuse of mixed passive content to bootstrap communications, as described in Taylor presentation at Cape Town Interop (2016). This has been shown to work, e.g. it is currently deployed at ASI-SSDC based on a custom/prototype JSAMP hub, see Verrecchia presentation at Paris Interop (2019). This solution however is not elegant, efficient, robust or nice. There is some more discussion of this as well as alternative bad solutions in https://arxiv.org/abs/1912.00917 (presented by Taylor at ADASS 2019; this paper is now mostly obsolete).
>
>
A possible solution was proposed that defines a new Profile involving use of an external Relay service and abuse of mixed passive content to bootstrap communications, as described in Taylor presentation at Cape Town Interop (2016). This has been shown to work, e.g. it is currently deployed at ASI-SSDC based on a custom/prototype JSAMP hub, see Verrecchia presentation at Paris Interop (2019). This solution however is not elegant, efficient, robust or nice. There is some more discussion of this as well as alternative bad solutions in https://arxiv.org/abs/1912.00917 (presented by Taylor at ADASS 2019; this paper is now mostly obsolete).
 

Good solution?

Changed:
<
<
Following discussion at Groningen Interop (2019), some more progress was made that could get HTTPS-based web applications to use the Web Profile as it stands:
>
>
Following discussion at Groningen Interop (2019), some more progress was made that could get HTTPS-based web applications to use the Web Profile as it stands:
 
  • Felix Stoehr pointed out that in recent tests, this just works in some browsers anyway, i.e. the problem has just gone away. This was a surprise, that arises from changes to the various w3c security standards over the last few years (see analysis).
  • Sonia Zorba prepared a browser extension samp-browser-extension for browsers that still have problems with this
These two developments may provide a good-enough solution to this problem; some (hopefully increasingly many) browsers will work anyway, and for others users can be encouraged to install a browser extension that will make them work.

Current status

We are assessing which browsers now support Web SAMP over HTTPS without making any special arrangements. Thanks to those who have tried out browser/OS combinations following the instructions below. The headline results seem to be:

  • Recent versions of Firefox, Chrome, Edge: SAMP over HTTPS works with no problems
  • Safari: SAMP over HTTPS doesn't work
  • Others: Vivaldi works. Luakit works. Internet Explorer: not sure.
  • ... but there are apparently exceptions; I've highlighted these in the table
The OS doesn't seem to make a difference (Linux, MacOS, Windows 10 all tried).

This looks quite positive; services may decide on that basis that it's worth providing Web SAMP in HTTPS-based services on the basis that they will work for many/most users. Optionally, they could provide the browser extensions for others.

Deleted:
<
<
 

You can try this out using your browser/OS combination(s):

To work out the status of HTTPS+SAMP on your browser/OS, follow these easy instructions:

  1. Start a SAMP Hub+client on your machine (e.g. run TOPCAT)
Changed:
<
<
  1. Visit this HTTP page. Click the button.
>
>
  1. Visit this HTTP page. Click the button.
 
    • A popup should appear asking you to allow SAMP registration from a web application (with an http://... Origin). Accept, and a table should be loaded in TOPCAT. (If this doesn't happen, your problems are not related to HTTPS)
Changed:
<
<
  1. Visit this HTTPS page. Click the button.
>
>
  1. Visit this HTTPS page. Click the button.
 
    • Either as before, you are prompted to allow registration (for a web app with an https://... Origin) and a table is loaded in TOPCAT as before - this means SAMP+HTTPS does work on your browser
    • Or nothing happens - this means SAMP+HTTPS does not work on your browser.
  1. Record in the table below whether it did or didn't work ("yes" or "no" in the Works out of the box? column)
If you've done that but don't have easy write access to the wiki, you can mail your results to either m.b.taylor@bristol.ac.uk or apps-samp@ivoa.net.

(If you want to try some more interesting examples, including 2-way communications, others are available: HTTP / HTTPS. I'm expecting that if HTTPS works/fails for one SAMP example it will be the same for all, but if you find different, please report it).

Results: some anomalous outcomes are highlighted

HTTPS + SAMP Survey
Browser Version OS Works out of the box? Reporter
Chrome 77 Ubuntu yes Felix Stoehr
Chromium 78.0 Ubuntu yes Mark Taylor
Chromium 85.0 Ubuntu yes Mark Taylor
Firefox 70.0.1 OSX Mojave yes Felix Stoehr
Firefox 70.0 Ubuntu no Felix Stoehr
Firefox 59 RHEL6 no Mark Taylor
Firefox 70.0.1 Ubuntu no Mark Taylor
Firefox 81.0 Ubuntu yes Mark Taylor
Firefox Nightly 75.0 (64-bit) GUIX yes Hugo Buddelmeijer
Chrome 85.0 MacOS 10.13.6 yes Thomas Boch
Firefox 81.0 MacOS 10.13.6 yes Thomas Boch
Safari 13.1.2 MacOS 10.13.6 no Thomas Boch
Chrome 85.0 Fedora 31 yes Marco Molinaro
Firefox 80.0 Fedora 31 yes Marco Molinaro
Chrome 85.0. MacOS 10.11.3 yes Susana Sánchez Expósito
Firefox 78.2 MacOS 10.11.3 yes Susana Sánchez Expósito
Safari 9.0.3 MacOS 10.11.3 No Susana Sánchez Expósito
Firefox 81.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Chrome 85.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Safari 13.1 MacOS 10.14.6 No Susana Sánchez Expósito
Firefox 86.0.1 MacOS 10.14.6 Yes Stéphane Erard
Safari 13.1.2 MacOS 10.14.6 No Stéphane Erard
Chrome 89.0.4389.90 MacOS 10.14.6 Yes Stéphane Erard
Firefox 81.0(64 bits) Ubuntu 20.04.1 LTS yes Regis Haigron
Firefox 80 Windows 10 yes Regis Haigron
Firefox 81.0(64 bits) Ubuntu 18.04.1 LTS yes Pierre Le Sidaner
Chrome 86.0.4240.75 Ubuntu 18.04.1 LTS Yes Pierre Le Sidaner
Vivaldi 3.3.2022.47 Ubuntu 18.04.1 LTS Yes Pierre Le Sidaner
Chrome 84.0.4147.125 MacOS 10.12.5 Yes Juan Carlos Segovia
Safari 10.1.1 MacOS 10.12.5 No Juan Carlos Segovia
Firefox 75.0 MacOS 10.12.5 Yes Juan Carlos Segovia
Chrome 57.0 MacOS 10.12.6 Yes Alcione Mora
Safari 11.0.2 MacOS 10.12.6 Yes Alcione Mora
Firefox 69.0 MacOS 10.12.6 Yes Alcione Mora
Chrome 86.0 MacOS 10.14.6 Yes Hector Canovas
Safari 12.1.2 MacOS 10.14.6 No Hector Canovas
Firefox 81.0.1 MacOS 10.14.6 No Hector Canovas
Edge 86.0 Windows 10.0 Yes Mark Taylor
Chrome 86.0.4240.80 MacOS 10.13.6 Yes Tom Donaldson
Firefox 81.0.2 MacOS 10.13.6 Yes Tom Donaldson
Safari 13.1.2 MacOS 10.13.6 No Tom Donaldson
Luakit 2.0.0 Debian buster Yes Markus
Internet Explorer 11.0.9600.19867 Windows Server 2012 R2 Standard No Yan Grange
Internet Explorer 11.1198.18362.0 Windows 10 1909 Yes Yan Grange
Edge 87.0.664.47 Windows 10 1909 Yes Yan Grange
Internet Explorer 11.630.19041.0 Windows 10 19041 No? Mark Taylor
Safari 13.1.2 MacOS 10.13.6 No Baptiste Cecconi
Firefox 89.0.1 MacOS 10.13.6 Yes Baptiste Cecconi
Chrome 91.0.4472.114 MacOS 10.13.6 Yes Baptiste Cecconi
Safari 14.1.2 macOS 11.5.1 No John Swinbank
Safari Technology Preview Release 128 (Safari 15.0) macOS 11.5.1 No John Swinbank
Firefox 90.0.2 (64-bit) macOS 11.5.1 Yes John Swinbank
Safari Technology Preview Release 132 (Safari 15.4) macOS 11.6 No John Swinbank
Changed:
<
<
>
>
Safari 15.3 macOS 12.2.1 No Hendrik Heinl
 For more discussion on this topic, see the apps-samp mailing list.

-- MarkTaylor - 2020-10-13

Deleted:
<
<

Revision 202023-04-21 - MarkTaylor

 
META TOPICPARENT name="SampInfo"

Web SAMP and HTTPS

Problem

The SAMP Web Profile allows web applications to talk to other SAMP clients, communicating with the Hub using an XMLHttpRequest to a well-known port (21012) on the local host. There are problems with doing this if the web page hosting the web application is served from HTTPS rather than HTTP, since access to the hub URL http://localhost:21012/ counts (at least in some interpretations) as mixed active content, which is generally blocked by browsers. This issue has been known since 2014, but is becoming more pressing as more data providers use HTTPS for service delivery. See Presentation at Sydney Interop (2015) for more details.

Bad solution

A possible solution was proposed that defines a new Profile involving use of an external Relay service and abuse of mixed passive content to bootstrap communications, as described in Taylor presentation at Cape Town Interop (2016). This has been shown to work, e.g. it is currently deployed at ASI-SSDC based on a custom/prototype JSAMP hub, see Verrecchia presentation at Paris Interop (2019). This solution however is not elegant, efficient, robust or nice. There is some more discussion of this as well as alternative bad solutions in https://arxiv.org/abs/1912.00917 (presented by Taylor at ADASS 2019; this paper is now mostly obsolete).

Good solution?

Following discussion at Groningen Interop (2019), some more progress was made that could get HTTPS-based web applications to use the Web Profile as it stands:

  • Felix Stoehr pointed out that in recent tests, this just works in some browsers anyway, i.e. the problem has just gone away. This was a surprise, that arises from changes to the various w3c security standards over the last few years (see analysis).
  • Sonia Zorba prepared a browser extension samp-browser-extension for browsers that still have problems with this
These two developments may provide a good-enough solution to this problem; some (hopefully increasingly many) browsers will work anyway, and for others users can be encouraged to install a browser extension that will make them work.

Current status

We are assessing which browsers now support Web SAMP over HTTPS without making any special arrangements. Thanks to those who have tried out browser/OS combinations following the instructions below. The headline results seem to be:

  • Recent versions of Firefox, Chrome, Edge: SAMP over HTTPS works with no problems
  • Safari: SAMP over HTTPS doesn't work
  • Others: Vivaldi works. Luakit works. Internet Explorer: not sure.
  • ... but there are apparently exceptions; I've highlighted these in the table
The OS doesn't seem to make a difference (Linux, MacOS, Windows 10 all tried).

This looks quite positive; services may decide on that basis that it's worth providing Web SAMP in HTTPS-based services on the basis that they will work for many/most users. Optionally, they could provide the browser extensions for others.

Deleted:
<
<
If you use a browser not in the above list, please consider following the instructions below to try it out and add your results into the table (or if you have trouble editing the wiki you can mail m.b.taylor@bristol.ac.uk and I'll add them).
 

You can try this out using your browser/OS combination(s):

To work out the status of HTTPS+SAMP on your browser/OS, follow these easy instructions:

  1. Start a SAMP Hub+client on your machine (e.g. run TOPCAT)
Changed:
<
<
  1. Visit this HTTP page. Click the button.
>
>
  1. Visit this HTTP page. Click the button.
 
    • A popup should appear asking you to allow SAMP registration from a web application (with an http://... Origin). Accept, and a table should be loaded in TOPCAT. (If this doesn't happen, your problems are not related to HTTPS)
Changed:
<
<
  1. Visit this HTTPS page. Click the button.
>
>
  1. Visit this HTTPS page. Click the button.
 
    • Either as before, you are prompted to allow registration (for a web app with an https://... Origin) and a table is loaded in TOPCAT as before - this means SAMP+HTTPS does work on your browser
    • Or nothing happens - this means SAMP+HTTPS does not work on your browser.
  1. Record in the table below whether it did or didn't work ("yes" or "no" in the Works out of the box? column)
If you've done that but don't have easy write access to the wiki, you can mail your results to either m.b.taylor@bristol.ac.uk or apps-samp@ivoa.net.
Changed:
<
<
(If you want to try some more interesting examples, including 2-way communications, others are available: HTTP / HTTPS. I'm expecting that if HTTPS works/fails for one SAMP example it will be the same for all, but if you find different, please report it).
>
>
(If you want to try some more interesting examples, including 2-way communications, others are available: HTTP / HTTPS. I'm expecting that if HTTPS works/fails for one SAMP example it will be the same for all, but if you find different, please report it).
  Results: some anomalous outcomes are highlighted

HTTPS + SAMP Survey
Browser Version OS Works out of the box? Reporter
Chrome 77 Ubuntu yes Felix Stoehr
Chromium 78.0 Ubuntu yes Mark Taylor
Chromium 85.0 Ubuntu yes Mark Taylor
Firefox 70.0.1 OSX Mojave yes Felix Stoehr
Firefox 70.0 Ubuntu no Felix Stoehr
Firefox 59 RHEL6 no Mark Taylor
Firefox 70.0.1 Ubuntu no Mark Taylor
Firefox 81.0 Ubuntu yes Mark Taylor
Firefox Nightly 75.0 (64-bit) GUIX yes Hugo Buddelmeijer
Chrome 85.0 MacOS 10.13.6 yes Thomas Boch
Firefox 81.0 MacOS 10.13.6 yes Thomas Boch
Safari 13.1.2 MacOS 10.13.6 no Thomas Boch
Chrome 85.0 Fedora 31 yes Marco Molinaro
Firefox 80.0 Fedora 31 yes Marco Molinaro
Chrome 85.0. MacOS 10.11.3 yes Susana Sánchez Expósito
Firefox 78.2 MacOS 10.11.3 yes Susana Sánchez Expósito
Safari 9.0.3 MacOS 10.11.3 No Susana Sánchez Expósito
Firefox 81.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Chrome 85.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Safari 13.1 MacOS 10.14.6 No Susana Sánchez Expósito
Firefox 86.0.1 MacOS 10.14.6 Yes Stéphane Erard
Safari 13.1.2 MacOS 10.14.6 No Stéphane Erard
Chrome 89.0.4389.90 MacOS 10.14.6 Yes Stéphane Erard
Firefox 81.0(64 bits) Ubuntu 20.04.1 LTS yes Regis Haigron
Firefox 80 Windows 10 yes Regis Haigron
Firefox 81.0(64 bits) Ubuntu 18.04.1 LTS yes Pierre Le Sidaner
Chrome 86.0.4240.75 Ubuntu 18.04.1 LTS Yes Pierre Le Sidaner
Vivaldi 3.3.2022.47 Ubuntu 18.04.1 LTS Yes Pierre Le Sidaner
Chrome 84.0.4147.125 MacOS 10.12.5 Yes Juan Carlos Segovia
Safari 10.1.1 MacOS 10.12.5 No Juan Carlos Segovia
Firefox 75.0 MacOS 10.12.5 Yes Juan Carlos Segovia
Chrome 57.0 MacOS 10.12.6 Yes Alcione Mora
Safari 11.0.2 MacOS 10.12.6 Yes Alcione Mora
Firefox 69.0 MacOS 10.12.6 Yes Alcione Mora
Chrome 86.0 MacOS 10.14.6 Yes Hector Canovas
Safari 12.1.2 MacOS 10.14.6 No Hector Canovas
Firefox 81.0.1 MacOS 10.14.6 No Hector Canovas
Edge 86.0 Windows 10.0 Yes Mark Taylor
Chrome 86.0.4240.80 MacOS 10.13.6 Yes Tom Donaldson
Firefox 81.0.2 MacOS 10.13.6 Yes Tom Donaldson
Safari 13.1.2 MacOS 10.13.6 No Tom Donaldson
Luakit 2.0.0 Debian buster Yes Markus
Internet Explorer 11.0.9600.19867 Windows Server 2012 R2 Standard No Yan Grange
Internet Explorer 11.1198.18362.0 Windows 10 1909 Yes Yan Grange
Edge 87.0.664.47 Windows 10 1909 Yes Yan Grange
Internet Explorer 11.630.19041.0 Windows 10 19041 No? Mark Taylor
Safari 13.1.2 MacOS 10.13.6 No Baptiste Cecconi
Firefox 89.0.1 MacOS 10.13.6 Yes Baptiste Cecconi
Chrome 91.0.4472.114 MacOS 10.13.6 Yes Baptiste Cecconi
Safari 14.1.2 macOS 11.5.1 No John Swinbank
Safari Technology Preview Release 128 (Safari 15.0) macOS 11.5.1 No John Swinbank
Firefox 90.0.2 (64-bit) macOS 11.5.1 Yes John Swinbank
Safari Technology Preview Release 132 (Safari 15.4) macOS 11.6 No John Swinbank

For more discussion on this topic, see the apps-samp mailing list.

-- MarkTaylor - 2020-10-13

Added:
>
>

Revision 192021-09-24 - JohnSwinbank

 
META TOPICPARENT name="SampInfo"

Web SAMP and HTTPS

Problem

The SAMP Web Profile allows web applications to talk to other SAMP clients, communicating with the Hub using an XMLHttpRequest to a well-known port (21012) on the local host. There are problems with doing this if the web page hosting the web application is served from HTTPS rather than HTTP, since access to the hub URL http://localhost:21012/ counts (at least in some interpretations) as mixed active content, which is generally blocked by browsers. This issue has been known since 2014, but is becoming more pressing as more data providers use HTTPS for service delivery. See Presentation at Sydney Interop (2015) for more details.

Bad solution

A possible solution was proposed that defines a new Profile involving use of an external Relay service and abuse of mixed passive content to bootstrap communications, as described in Taylor presentation at Cape Town Interop (2016). This has been shown to work, e.g. it is currently deployed at ASI-SSDC based on a custom/prototype JSAMP hub, see Verrecchia presentation at Paris Interop (2019). This solution however is not elegant, efficient, robust or nice. There is some more discussion of this as well as alternative bad solutions in https://arxiv.org/abs/1912.00917 (presented by Taylor at ADASS 2019; this paper is now mostly obsolete).

Good solution?

Following discussion at Groningen Interop (2019), some more progress was made that could get HTTPS-based web applications to use the Web Profile as it stands:

  • Felix Stoehr pointed out that in recent tests, this just works in some browsers anyway, i.e. the problem has just gone away. This was a surprise, that arises from changes to the various w3c security standards over the last few years (see analysis).
  • Sonia Zorba prepared a browser extension samp-browser-extension for browsers that still have problems with this
These two developments may provide a good-enough solution to this problem; some (hopefully increasingly many) browsers will work anyway, and for others users can be encouraged to install a browser extension that will make them work.

Current status

We are assessing which browsers now support Web SAMP over HTTPS without making any special arrangements. Thanks to those who have tried out browser/OS combinations following the instructions below. The headline results seem to be:

  • Recent versions of Firefox, Chrome, Edge: SAMP over HTTPS works with no problems
  • Safari: SAMP over HTTPS doesn't work
  • Others: Vivaldi works. Luakit works. Internet Explorer: not sure.
  • ... but there are apparently exceptions; I've highlighted these in the table
The OS doesn't seem to make a difference (Linux, MacOS, Windows 10 all tried).

This looks quite positive; services may decide on that basis that it's worth providing Web SAMP in HTTPS-based services on the basis that they will work for many/most users. Optionally, they could provide the browser extensions for others.

If you use a browser not in the above list, please consider following the instructions below to try it out and add your results into the table (or if you have trouble editing the wiki you can mail m.b.taylor@bristol.ac.uk and I'll add them).

You can try this out using your browser/OS combination(s):

To work out the status of HTTPS+SAMP on your browser/OS, follow these easy instructions:

  1. Start a SAMP Hub+client on your machine (e.g. run TOPCAT)
  2. Visit this HTTP page. Click the button.
    • A popup should appear asking you to allow SAMP registration from a web application (with an http://... Origin). Accept, and a table should be loaded in TOPCAT. (If this doesn't happen, your problems are not related to HTTPS)
  3. Visit this HTTPS page. Click the button.
    • Either as before, you are prompted to allow registration (for a web app with an https://... Origin) and a table is loaded in TOPCAT as before - this means SAMP+HTTPS does work on your browser
    • Or nothing happens - this means SAMP+HTTPS does not work on your browser.
  4. Record in the table below whether it did or didn't work ("yes" or "no" in the Works out of the box? column)
If you've done that but don't have easy write access to the wiki, you can mail your results to either m.b.taylor@bristol.ac.uk or apps-samp@ivoa.net.

(If you want to try some more interesting examples, including 2-way communications, others are available: HTTP / HTTPS. I'm expecting that if HTTPS works/fails for one SAMP example it will be the same for all, but if you find different, please report it).

Results: some anomalous outcomes are highlighted

HTTPS + SAMP Survey
Browser Version OS Works out of the box? Reporter
Chrome 77 Ubuntu yes Felix Stoehr
Chromium 78.0 Ubuntu yes Mark Taylor
Chromium 85.0 Ubuntu yes Mark Taylor
Firefox 70.0.1 OSX Mojave yes Felix Stoehr
Firefox 70.0 Ubuntu no Felix Stoehr
Firefox 59 RHEL6 no Mark Taylor
Firefox 70.0.1 Ubuntu no Mark Taylor
Firefox 81.0 Ubuntu yes Mark Taylor
Firefox Nightly 75.0 (64-bit) GUIX yes Hugo Buddelmeijer
Chrome 85.0 MacOS 10.13.6 yes Thomas Boch
Firefox 81.0 MacOS 10.13.6 yes Thomas Boch
Safari 13.1.2 MacOS 10.13.6 no Thomas Boch
Chrome 85.0 Fedora 31 yes Marco Molinaro
Firefox 80.0 Fedora 31 yes Marco Molinaro
Chrome 85.0. MacOS 10.11.3 yes Susana Sánchez Expósito
Firefox 78.2 MacOS 10.11.3 yes Susana Sánchez Expósito
Safari 9.0.3 MacOS 10.11.3 No Susana Sánchez Expósito
Firefox 81.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Chrome 85.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Safari 13.1 MacOS 10.14.6 No Susana Sánchez Expósito
Firefox 86.0.1 MacOS 10.14.6 Yes Stéphane Erard
Safari 13.1.2 MacOS 10.14.6 No Stéphane Erard
Chrome 89.0.4389.90 MacOS 10.14.6 Yes Stéphane Erard
Firefox 81.0(64 bits) Ubuntu 20.04.1 LTS yes Regis Haigron
Firefox 80 Windows 10 yes Regis Haigron
Firefox 81.0(64 bits) Ubuntu 18.04.1 LTS yes Pierre Le Sidaner
Chrome 86.0.4240.75 Ubuntu 18.04.1 LTS Yes Pierre Le Sidaner
Vivaldi 3.3.2022.47 Ubuntu 18.04.1 LTS Yes Pierre Le Sidaner
Chrome 84.0.4147.125 MacOS 10.12.5 Yes Juan Carlos Segovia
Safari 10.1.1 MacOS 10.12.5 No Juan Carlos Segovia
Firefox 75.0 MacOS 10.12.5 Yes Juan Carlos Segovia
Chrome 57.0 MacOS 10.12.6 Yes Alcione Mora
Safari 11.0.2 MacOS 10.12.6 Yes Alcione Mora
Firefox 69.0 MacOS 10.12.6 Yes Alcione Mora
Chrome 86.0 MacOS 10.14.6 Yes Hector Canovas
Safari 12.1.2 MacOS 10.14.6 No Hector Canovas
Firefox 81.0.1 MacOS 10.14.6 No Hector Canovas
Edge 86.0 Windows 10.0 Yes Mark Taylor
Chrome 86.0.4240.80 MacOS 10.13.6 Yes Tom Donaldson
Firefox 81.0.2 MacOS 10.13.6 Yes Tom Donaldson
Safari 13.1.2 MacOS 10.13.6 No Tom Donaldson
Luakit 2.0.0 Debian buster Yes Markus
Internet Explorer 11.0.9600.19867 Windows Server 2012 R2 Standard No Yan Grange
Internet Explorer 11.1198.18362.0 Windows 10 1909 Yes Yan Grange
Edge 87.0.664.47 Windows 10 1909 Yes Yan Grange
Internet Explorer 11.630.19041.0 Windows 10 19041 No? Mark Taylor
Safari 13.1.2 MacOS 10.13.6 No Baptiste Cecconi
Firefox 89.0.1 MacOS 10.13.6 Yes Baptiste Cecconi
Chrome 91.0.4472.114 MacOS 10.13.6 Yes Baptiste Cecconi
Safari 14.1.2 macOS 11.5.1 No John Swinbank
Safari Technology Preview Release 128 (Safari 15.0) macOS 11.5.1 No John Swinbank
Firefox 90.0.2 (64-bit) macOS 11.5.1 Yes John Swinbank
Added:
>
>
Safari Technology Preview Release 132 (Safari 15.4) macOS 11.6 No John Swinbank
  For more discussion on this topic, see the apps-samp mailing list.

-- MarkTaylor - 2020-10-13

Revision 182021-08-02 - JohnSwinbank

 
META TOPICPARENT name="SampInfo"

Web SAMP and HTTPS

Problem

The SAMP Web Profile allows web applications to talk to other SAMP clients, communicating with the Hub using an XMLHttpRequest to a well-known port (21012) on the local host. There are problems with doing this if the web page hosting the web application is served from HTTPS rather than HTTP, since access to the hub URL http://localhost:21012/ counts (at least in some interpretations) as mixed active content, which is generally blocked by browsers. This issue has been known since 2014, but is becoming more pressing as more data providers use HTTPS for service delivery. See Presentation at Sydney Interop (2015) for more details.

Bad solution

A possible solution was proposed that defines a new Profile involving use of an external Relay service and abuse of mixed passive content to bootstrap communications, as described in Taylor presentation at Cape Town Interop (2016). This has been shown to work, e.g. it is currently deployed at ASI-SSDC based on a custom/prototype JSAMP hub, see Verrecchia presentation at Paris Interop (2019). This solution however is not elegant, efficient, robust or nice. There is some more discussion of this as well as alternative bad solutions in https://arxiv.org/abs/1912.00917 (presented by Taylor at ADASS 2019; this paper is now mostly obsolete).

Good solution?

Following discussion at Groningen Interop (2019), some more progress was made that could get HTTPS-based web applications to use the Web Profile as it stands:

  • Felix Stoehr pointed out that in recent tests, this just works in some browsers anyway, i.e. the problem has just gone away. This was a surprise, that arises from changes to the various w3c security standards over the last few years (see analysis).
  • Sonia Zorba prepared a browser extension samp-browser-extension for browsers that still have problems with this
These two developments may provide a good-enough solution to this problem; some (hopefully increasingly many) browsers will work anyway, and for others users can be encouraged to install a browser extension that will make them work.

Current status

We are assessing which browsers now support Web SAMP over HTTPS without making any special arrangements. Thanks to those who have tried out browser/OS combinations following the instructions below. The headline results seem to be:

  • Recent versions of Firefox, Chrome, Edge: SAMP over HTTPS works with no problems
  • Safari: SAMP over HTTPS doesn't work
  • Others: Vivaldi works. Luakit works. Internet Explorer: not sure.
  • ... but there are apparently exceptions; I've highlighted these in the table
The OS doesn't seem to make a difference (Linux, MacOS, Windows 10 all tried).

This looks quite positive; services may decide on that basis that it's worth providing Web SAMP in HTTPS-based services on the basis that they will work for many/most users. Optionally, they could provide the browser extensions for others.

If you use a browser not in the above list, please consider following the instructions below to try it out and add your results into the table (or if you have trouble editing the wiki you can mail m.b.taylor@bristol.ac.uk and I'll add them).

You can try this out using your browser/OS combination(s):

To work out the status of HTTPS+SAMP on your browser/OS, follow these easy instructions:

  1. Start a SAMP Hub+client on your machine (e.g. run TOPCAT)
  2. Visit this HTTP page. Click the button.
    • A popup should appear asking you to allow SAMP registration from a web application (with an http://... Origin). Accept, and a table should be loaded in TOPCAT. (If this doesn't happen, your problems are not related to HTTPS)
  3. Visit this HTTPS page. Click the button.
    • Either as before, you are prompted to allow registration (for a web app with an https://... Origin) and a table is loaded in TOPCAT as before - this means SAMP+HTTPS does work on your browser
    • Or nothing happens - this means SAMP+HTTPS does not work on your browser.
  4. Record in the table below whether it did or didn't work ("yes" or "no" in the Works out of the box? column)
If you've done that but don't have easy write access to the wiki, you can mail your results to either m.b.taylor@bristol.ac.uk or apps-samp@ivoa.net.

(If you want to try some more interesting examples, including 2-way communications, others are available: HTTP / HTTPS. I'm expecting that if HTTPS works/fails for one SAMP example it will be the same for all, but if you find different, please report it).

Results: some anomalous outcomes are highlighted

Changed:
<
<
HTTPS + SAMP Survey
Browser Version OS Works out of the box? Reporter
Chrome 77 Ubuntu yes Felix Stoehr
Chromium 78.0 Ubuntu yes Mark Taylor
Chromium 85.0 Ubuntu yes Mark Taylor
Firefox 70.0.1 OSX Mojave yes Felix Stoehr
Firefox 70.0 Ubuntu no Felix Stoehr
Firefox 59 RHEL6 no Mark Taylor
Firefox 70.0.1 Ubuntu no Mark Taylor
Firefox 81.0 Ubuntu yes Mark Taylor
Firefox Nightly 75.0 (64-bit) GUIX yes Hugo Buddelmeijer
Chrome 85.0 MacOS 10.13.6 yes Thomas Boch
Firefox 81.0 MacOS 10.13.6 yes Thomas Boch
Safari 13.1.2 MacOS 10.13.6 no Thomas Boch
Chrome 85.0 Fedora 31 yes Marco Molinaro
Firefox 80.0 Fedora 31 yes Marco Molinaro
Chrome 85.0. MacOS 10.11.3 yes Susana Sánchez Expósito
Firefox 78.2 MacOS 10.11.3 yes Susana Sánchez Expósito
Safari 9.0.3 MacOS 10.11.3 No Susana Sánchez Expósito
Firefox 81.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Chrome 85.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Safari 13.1 MacOS 10.14.6 No Susana Sánchez Expósito
Firefox 86.0.1 MacOS 10.14.6 Yes Stéphane Erard
Safari 13.1.2 MacOS 10.14.6 No Stéphane Erard
Chrome 89.0.4389.90 MacOS 10.14.6 Yes Stéphane Erard
Firefox 81.0(64 bits) Ubuntu 20.04.1 LTS yes Regis Haigron
Firefox 80 Windows 10 yes Regis Haigron
Firefox 81.0(64 bits) Ubuntu 18.04.1 LTS yes Pierre Le Sidaner
Chrome 86.0.4240.75 Ubuntu 18.04.1 LTS Yes Pierre Le Sidaner
Vivaldi 3.3.2022.47 Ubuntu 18.04.1 LTS Yes Pierre Le Sidaner
Chrome 84.0.4147.125 MacOS 10.12.5 Yes Juan Carlos Segovia
Safari 10.1.1 MacOS 10.12.5 No Juan Carlos Segovia
Firefox 75.0 MacOS 10.12.5 Yes Juan Carlos Segovia
Chrome 57.0 MacOS 10.12.6 Yes Alcione Mora
Safari 11.0.2 MacOS 10.12.6 Yes Alcione Mora
Firefox 69.0 MacOS 10.12.6 Yes Alcione Mora
Chrome 86.0 MacOS 10.14.6 Yes Hector Canovas
Safari 12.1.2 MacOS 10.14.6 No Hector Canovas
Firefox 81.0.1 MacOS 10.14.6 No Hector Canovas
Edge 86.0 Windows 10.0 Yes Mark Taylor
Chrome 86.0.4240.80 MacOS 10.13.6 Yes Tom Donaldson
Firefox 81.0.2 MacOS 10.13.6 Yes Tom Donaldson
Safari 13.1.2 MacOS 10.13.6 No Tom Donaldson
Luakit 2.0.0 Debian buster Yes Markus
Internet Explorer 11.0.9600.19867 Windows Server 2012 R2 Standard No Yan Grange
Internet Explorer 11.1198.18362.0 Windows 10 1909 Yes Yan Grange
Edge 87.0.664.47 Windows 10 1909 Yes Yan Grange
Internet Explorer 11.630.19041.0 Windows 10 19041 No? Mark Taylor
Safari 13.1.2 MacOS 10.13.6 No Baptiste Cecconi
Firefox 89.0.1 MacOS 10.13.6 Yes Baptiste Cecconi
Chrome 91.0.4472.114 MacOS 10.13.6 Yes Baptiste Cecconi
>
>
HTTPS + SAMP Survey
Browser Version OS Works out of the box? Reporter
Chrome 77 Ubuntu yes Felix Stoehr
Chromium 78.0 Ubuntu yes Mark Taylor
Chromium 85.0 Ubuntu yes Mark Taylor
Firefox 70.0.1 OSX Mojave yes Felix Stoehr
Firefox 70.0 Ubuntu no Felix Stoehr
Firefox 59 RHEL6 no Mark Taylor
Firefox 70.0.1 Ubuntu no Mark Taylor
Firefox 81.0 Ubuntu yes Mark Taylor
Firefox Nightly 75.0 (64-bit) GUIX yes Hugo Buddelmeijer
Chrome 85.0 MacOS 10.13.6 yes Thomas Boch
Firefox 81.0 MacOS 10.13.6 yes Thomas Boch
Safari 13.1.2 MacOS 10.13.6 no Thomas Boch
Chrome 85.0 Fedora 31 yes Marco Molinaro
Firefox 80.0 Fedora 31 yes Marco Molinaro
Chrome 85.0. MacOS 10.11.3 yes Susana Sánchez Expósito
Firefox 78.2 MacOS 10.11.3 yes Susana Sánchez Expósito
Safari 9.0.3 MacOS 10.11.3 No Susana Sánchez Expósito
Firefox 81.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Chrome 85.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Safari 13.1 MacOS 10.14.6 No Susana Sánchez Expósito
Firefox 86.0.1 MacOS 10.14.6 Yes Stéphane Erard
Safari 13.1.2 MacOS 10.14.6 No Stéphane Erard
Chrome 89.0.4389.90 MacOS 10.14.6 Yes Stéphane Erard
Firefox 81.0(64 bits) Ubuntu 20.04.1 LTS yes Regis Haigron
Firefox 80 Windows 10 yes Regis Haigron
Firefox 81.0(64 bits) Ubuntu 18.04.1 LTS yes Pierre Le Sidaner
Chrome 86.0.4240.75 Ubuntu 18.04.1 LTS Yes Pierre Le Sidaner
Vivaldi 3.3.2022.47 Ubuntu 18.04.1 LTS Yes Pierre Le Sidaner
Chrome 84.0.4147.125 MacOS 10.12.5 Yes Juan Carlos Segovia
Safari 10.1.1 MacOS 10.12.5 No Juan Carlos Segovia
Firefox 75.0 MacOS 10.12.5 Yes Juan Carlos Segovia
Chrome 57.0 MacOS 10.12.6 Yes Alcione Mora
Safari 11.0.2 MacOS 10.12.6 Yes Alcione Mora
Firefox 69.0 MacOS 10.12.6 Yes Alcione Mora
Chrome 86.0 MacOS 10.14.6 Yes Hector Canovas
Safari 12.1.2 MacOS 10.14.6 No Hector Canovas
Firefox 81.0.1 MacOS 10.14.6 No Hector Canovas
Edge 86.0 Windows 10.0 Yes Mark Taylor
Chrome 86.0.4240.80 MacOS 10.13.6 Yes Tom Donaldson
Firefox 81.0.2 MacOS 10.13.6 Yes Tom Donaldson
Safari 13.1.2 MacOS 10.13.6 No Tom Donaldson
Luakit 2.0.0 Debian buster Yes Markus
Internet Explorer 11.0.9600.19867 Windows Server 2012 R2 Standard No Yan Grange
Internet Explorer 11.1198.18362.0 Windows 10 1909 Yes Yan Grange
Edge 87.0.664.47 Windows 10 1909 Yes Yan Grange
Internet Explorer 11.630.19041.0 Windows 10 19041 No? Mark Taylor
Safari 13.1.2 MacOS 10.13.6 No Baptiste Cecconi
Firefox 89.0.1 MacOS 10.13.6 Yes Baptiste Cecconi
Chrome 91.0.4472.114 MacOS 10.13.6 Yes Baptiste Cecconi
Safari 14.1.2 macOS 11.5.1 No John Swinbank
Added:
>
>
Safari Technology Preview Release 128 (Safari 15.0) macOS 11.5.1 No John Swinbank
Firefox 90.0.2 (64-bit) macOS 11.5.1 Yes John Swinbank
  For more discussion on this topic, see the apps-samp mailing list.

-- MarkTaylor - 2020-10-13

Revision 172021-06-24 - BaptisteCecconi

 
META TOPICPARENT name="SampInfo"

Web SAMP and HTTPS

Problem

The SAMP Web Profile allows web applications to talk to other SAMP clients, communicating with the Hub using an XMLHttpRequest to a well-known port (21012) on the local host. There are problems with doing this if the web page hosting the web application is served from HTTPS rather than HTTP, since access to the hub URL http://localhost:21012/ counts (at least in some interpretations) as mixed active content, which is generally blocked by browsers. This issue has been known since 2014, but is becoming more pressing as more data providers use HTTPS for service delivery. See Presentation at Sydney Interop (2015) for more details.

Bad solution

A possible solution was proposed that defines a new Profile involving use of an external Relay service and abuse of mixed passive content to bootstrap communications, as described in Taylor presentation at Cape Town Interop (2016). This has been shown to work, e.g. it is currently deployed at ASI-SSDC based on a custom/prototype JSAMP hub, see Verrecchia presentation at Paris Interop (2019). This solution however is not elegant, efficient, robust or nice. There is some more discussion of this as well as alternative bad solutions in https://arxiv.org/abs/1912.00917 (presented by Taylor at ADASS 2019; this paper is now mostly obsolete).

Good solution?

Following discussion at Groningen Interop (2019), some more progress was made that could get HTTPS-based web applications to use the Web Profile as it stands:

  • Felix Stoehr pointed out that in recent tests, this just works in some browsers anyway, i.e. the problem has just gone away. This was a surprise, that arises from changes to the various w3c security standards over the last few years (see analysis).
  • Sonia Zorba prepared a browser extension samp-browser-extension for browsers that still have problems with this
These two developments may provide a good-enough solution to this problem; some (hopefully increasingly many) browsers will work anyway, and for others users can be encouraged to install a browser extension that will make them work.

Current status

We are assessing which browsers now support Web SAMP over HTTPS without making any special arrangements. Thanks to those who have tried out browser/OS combinations following the instructions below. The headline results seem to be:

  • Recent versions of Firefox, Chrome, Edge: SAMP over HTTPS works with no problems
  • Safari: SAMP over HTTPS doesn't work
  • Others: Vivaldi works. Luakit works. Internet Explorer: not sure.
  • ... but there are apparently exceptions; I've highlighted these in the table
The OS doesn't seem to make a difference (Linux, MacOS, Windows 10 all tried).

This looks quite positive; services may decide on that basis that it's worth providing Web SAMP in HTTPS-based services on the basis that they will work for many/most users. Optionally, they could provide the browser extensions for others.

If you use a browser not in the above list, please consider following the instructions below to try it out and add your results into the table (or if you have trouble editing the wiki you can mail m.b.taylor@bristol.ac.uk and I'll add them).

You can try this out using your browser/OS combination(s):

To work out the status of HTTPS+SAMP on your browser/OS, follow these easy instructions:

  1. Start a SAMP Hub+client on your machine (e.g. run TOPCAT)
  2. Visit this HTTP page. Click the button.
    • A popup should appear asking you to allow SAMP registration from a web application (with an http://... Origin). Accept, and a table should be loaded in TOPCAT. (If this doesn't happen, your problems are not related to HTTPS)
  3. Visit this HTTPS page. Click the button.
    • Either as before, you are prompted to allow registration (for a web app with an https://... Origin) and a table is loaded in TOPCAT as before - this means SAMP+HTTPS does work on your browser
    • Or nothing happens - this means SAMP+HTTPS does not work on your browser.
  4. Record in the table below whether it did or didn't work ("yes" or "no" in the Works out of the box? column)
If you've done that but don't have easy write access to the wiki, you can mail your results to either m.b.taylor@bristol.ac.uk or apps-samp@ivoa.net.

(If you want to try some more interesting examples, including 2-way communications, others are available: HTTP / HTTPS. I'm expecting that if HTTPS works/fails for one SAMP example it will be the same for all, but if you find different, please report it).

Results: some anomalous outcomes are highlighted

HTTPS + SAMP Survey
Browser Version OS Works out of the box? Reporter
Chrome 77 Ubuntu yes Felix Stoehr
Chromium 78.0 Ubuntu yes Mark Taylor
Chromium 85.0 Ubuntu yes Mark Taylor
Firefox 70.0.1 OSX Mojave yes Felix Stoehr
Firefox 70.0 Ubuntu no Felix Stoehr
Firefox 59 RHEL6 no Mark Taylor
Firefox 70.0.1 Ubuntu no Mark Taylor
Firefox 81.0 Ubuntu yes Mark Taylor
Firefox Nightly 75.0 (64-bit) GUIX yes Hugo Buddelmeijer
Chrome 85.0 MacOS 10.13.6 yes Thomas Boch
Firefox 81.0 MacOS 10.13.6 yes Thomas Boch
Safari 13.1.2 MacOS 10.13.6 no Thomas Boch
Chrome 85.0 Fedora 31 yes Marco Molinaro
Firefox 80.0 Fedora 31 yes Marco Molinaro
Chrome 85.0. MacOS 10.11.3 yes Susana Sánchez Expósito
Firefox 78.2 MacOS 10.11.3 yes Susana Sánchez Expósito
Safari 9.0.3 MacOS 10.11.3 No Susana Sánchez Expósito
Firefox 81.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Chrome 85.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Safari 13.1 MacOS 10.14.6 No Susana Sánchez Expósito
Firefox 86.0.1 MacOS 10.14.6 Yes Stéphane Erard
Safari 13.1.2 MacOS 10.14.6 No Stéphane Erard
Chrome 89.0.4389.90 MacOS 10.14.6 Yes Stéphane Erard
Firefox 81.0(64 bits) Ubuntu 20.04.1 LTS yes Regis Haigron
Firefox 80 Windows 10 yes Regis Haigron
Firefox 81.0(64 bits) Ubuntu 18.04.1 LTS yes Pierre Le Sidaner
Chrome 86.0.4240.75 Ubuntu 18.04.1 LTS Yes Pierre Le Sidaner
Vivaldi 3.3.2022.47 Ubuntu 18.04.1 LTS Yes Pierre Le Sidaner
Chrome 84.0.4147.125 MacOS 10.12.5 Yes Juan Carlos Segovia
Safari 10.1.1 MacOS 10.12.5 No Juan Carlos Segovia
Firefox 75.0 MacOS 10.12.5 Yes Juan Carlos Segovia
Chrome 57.0 MacOS 10.12.6 Yes Alcione Mora
Safari 11.0.2 MacOS 10.12.6 Yes Alcione Mora
Firefox 69.0 MacOS 10.12.6 Yes Alcione Mora
Chrome 86.0 MacOS 10.14.6 Yes Hector Canovas
Safari 12.1.2 MacOS 10.14.6 No Hector Canovas
Firefox 81.0.1 MacOS 10.14.6 No Hector Canovas
Edge 86.0 Windows 10.0 Yes Mark Taylor
Chrome 86.0.4240.80 MacOS 10.13.6 Yes Tom Donaldson
Firefox 81.0.2 MacOS 10.13.6 Yes Tom Donaldson
Safari 13.1.2 MacOS 10.13.6 No Tom Donaldson
Luakit 2.0.0 Debian buster Yes Markus
Internet Explorer 11.0.9600.19867 Windows Server 2012 R2 Standard No Yan Grange
Internet Explorer 11.1198.18362.0 Windows 10 1909 Yes Yan Grange
Edge 87.0.664.47 Windows 10 1909 Yes Yan Grange
Internet Explorer 11.630.19041.0 Windows 10 19041 No? Mark Taylor
Added:
>
>
Safari 13.1.2 MacOS 10.13.6 No Baptiste Cecconi
Firefox 89.0.1 MacOS 10.13.6 Yes Baptiste Cecconi
Chrome 91.0.4472.114 MacOS 10.13.6 Yes Baptiste Cecconi
  For more discussion on this topic, see the apps-samp mailing list.

-- MarkTaylor - 2020-10-13

Revision 162021-03-23 - StephaneErard

 
META TOPICPARENT name="SampInfo"

Web SAMP and HTTPS

Problem

The SAMP Web Profile allows web applications to talk to other SAMP clients, communicating with the Hub using an XMLHttpRequest to a well-known port (21012) on the local host. There are problems with doing this if the web page hosting the web application is served from HTTPS rather than HTTP, since access to the hub URL http://localhost:21012/ counts (at least in some interpretations) as mixed active content, which is generally blocked by browsers. This issue has been known since 2014, but is becoming more pressing as more data providers use HTTPS for service delivery. See Presentation at Sydney Interop (2015) for more details.

Bad solution

A possible solution was proposed that defines a new Profile involving use of an external Relay service and abuse of mixed passive content to bootstrap communications, as described in Taylor presentation at Cape Town Interop (2016). This has been shown to work, e.g. it is currently deployed at ASI-SSDC based on a custom/prototype JSAMP hub, see Verrecchia presentation at Paris Interop (2019). This solution however is not elegant, efficient, robust or nice. There is some more discussion of this as well as alternative bad solutions in https://arxiv.org/abs/1912.00917 (presented by Taylor at ADASS 2019; this paper is now mostly obsolete).

Good solution?

Following discussion at Groningen Interop (2019), some more progress was made that could get HTTPS-based web applications to use the Web Profile as it stands:

  • Felix Stoehr pointed out that in recent tests, this just works in some browsers anyway, i.e. the problem has just gone away. This was a surprise, that arises from changes to the various w3c security standards over the last few years (see analysis).
  • Sonia Zorba prepared a browser extension samp-browser-extension for browsers that still have problems with this
These two developments may provide a good-enough solution to this problem; some (hopefully increasingly many) browsers will work anyway, and for others users can be encouraged to install a browser extension that will make them work.

Current status

We are assessing which browsers now support Web SAMP over HTTPS without making any special arrangements. Thanks to those who have tried out browser/OS combinations following the instructions below. The headline results seem to be:

  • Recent versions of Firefox, Chrome, Edge: SAMP over HTTPS works with no problems
  • Safari: SAMP over HTTPS doesn't work
  • Others: Vivaldi works. Luakit works. Internet Explorer: not sure.
  • ... but there are apparently exceptions; I've highlighted these in the table
The OS doesn't seem to make a difference (Linux, MacOS, Windows 10 all tried).

This looks quite positive; services may decide on that basis that it's worth providing Web SAMP in HTTPS-based services on the basis that they will work for many/most users. Optionally, they could provide the browser extensions for others.

If you use a browser not in the above list, please consider following the instructions below to try it out and add your results into the table (or if you have trouble editing the wiki you can mail m.b.taylor@bristol.ac.uk and I'll add them).

You can try this out using your browser/OS combination(s):

To work out the status of HTTPS+SAMP on your browser/OS, follow these easy instructions:

  1. Start a SAMP Hub+client on your machine (e.g. run TOPCAT)
  2. Visit this HTTP page. Click the button.
    • A popup should appear asking you to allow SAMP registration from a web application (with an http://... Origin). Accept, and a table should be loaded in TOPCAT. (If this doesn't happen, your problems are not related to HTTPS)
  3. Visit this HTTPS page. Click the button.
    • Either as before, you are prompted to allow registration (for a web app with an https://... Origin) and a table is loaded in TOPCAT as before - this means SAMP+HTTPS does work on your browser
    • Or nothing happens - this means SAMP+HTTPS does not work on your browser.
  4. Record in the table below whether it did or didn't work ("yes" or "no" in the Works out of the box? column)
If you've done that but don't have easy write access to the wiki, you can mail your results to either m.b.taylor@bristol.ac.uk or apps-samp@ivoa.net.

(If you want to try some more interesting examples, including 2-way communications, others are available: HTTP / HTTPS. I'm expecting that if HTTPS works/fails for one SAMP example it will be the same for all, but if you find different, please report it).

Results: some anomalous outcomes are highlighted

HTTPS + SAMP Survey
Browser Version OS Works out of the box? Reporter
Chrome 77 Ubuntu yes Felix Stoehr
Chromium 78.0 Ubuntu yes Mark Taylor
Chromium 85.0 Ubuntu yes Mark Taylor
Firefox 70.0.1 OSX Mojave yes Felix Stoehr
Firefox 70.0 Ubuntu no Felix Stoehr
Firefox 59 RHEL6 no Mark Taylor
Firefox 70.0.1 Ubuntu no Mark Taylor
Firefox 81.0 Ubuntu yes Mark Taylor
Firefox Nightly 75.0 (64-bit) GUIX yes Hugo Buddelmeijer
Chrome 85.0 MacOS 10.13.6 yes Thomas Boch
Firefox 81.0 MacOS 10.13.6 yes Thomas Boch
Safari 13.1.2 MacOS 10.13.6 no Thomas Boch
Chrome 85.0 Fedora 31 yes Marco Molinaro
Firefox 80.0 Fedora 31 yes Marco Molinaro
Chrome 85.0. MacOS 10.11.3 yes Susana Sánchez Expósito
Firefox 78.2 MacOS 10.11.3 yes Susana Sánchez Expósito
Safari 9.0.3 MacOS 10.11.3 No Susana Sánchez Expósito
Firefox 81.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Chrome 85.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Safari 13.1 MacOS 10.14.6 No Susana Sánchez Expósito
Added:
>
>
Firefox 86.0.1 MacOS 10.14.6 Yes Stéphane Erard
Safari 13.1.2 MacOS 10.14.6 No Stéphane Erard
Chrome 89.0.4389.90 MacOS 10.14.6 Yes Stéphane Erard
 
Firefox 81.0(64 bits) Ubuntu 20.04.1 LTS yes Regis Haigron
Firefox 80 Windows 10 yes Regis Haigron
Firefox 81.0(64 bits) Ubuntu 18.04.1 LTS yes Pierre Le Sidaner
Chrome 86.0.4240.75 Ubuntu 18.04.1 LTS Yes Pierre Le Sidaner
Vivaldi 3.3.2022.47 Ubuntu 18.04.1 LTS Yes Pierre Le Sidaner
Chrome 84.0.4147.125 MacOS 10.12.5 Yes Juan Carlos Segovia
Safari 10.1.1 MacOS 10.12.5 No Juan Carlos Segovia
Firefox 75.0 MacOS 10.12.5 Yes Juan Carlos Segovia
Chrome 57.0 MacOS 10.12.6 Yes Alcione Mora
Safari 11.0.2 MacOS 10.12.6 Yes Alcione Mora
Firefox 69.0 MacOS 10.12.6 Yes Alcione Mora
Chrome 86.0 MacOS 10.14.6 Yes Hector Canovas
Safari 12.1.2 MacOS 10.14.6 No Hector Canovas
Firefox 81.0.1 MacOS 10.14.6 No Hector Canovas
Edge 86.0 Windows 10.0 Yes Mark Taylor
Chrome 86.0.4240.80 MacOS 10.13.6 Yes Tom Donaldson
Firefox 81.0.2 MacOS 10.13.6 Yes Tom Donaldson
Safari 13.1.2 MacOS 10.13.6 No Tom Donaldson
Luakit 2.0.0 Debian buster Yes Markus
Internet Explorer 11.0.9600.19867 Windows Server 2012 R2 Standard No Yan Grange
Internet Explorer 11.1198.18362.0 Windows 10 1909 Yes Yan Grange
Edge 87.0.664.47 Windows 10 1909 Yes Yan Grange
Internet Explorer 11.630.19041.0 Windows 10 19041 No? Mark Taylor

For more discussion on this topic, see the apps-samp mailing list.

-- MarkTaylor - 2020-10-13

Revision 152020-11-30 - MarkTaylor

 
META TOPICPARENT name="SampInfo"

Web SAMP and HTTPS

Problem

The SAMP Web Profile allows web applications to talk to other SAMP clients, communicating with the Hub using an XMLHttpRequest to a well-known port (21012) on the local host. There are problems with doing this if the web page hosting the web application is served from HTTPS rather than HTTP, since access to the hub URL http://localhost:21012/ counts (at least in some interpretations) as mixed active content, which is generally blocked by browsers. This issue has been known since 2014, but is becoming more pressing as more data providers use HTTPS for service delivery. See Presentation at Sydney Interop (2015) for more details.

Bad solution

A possible solution was proposed that defines a new Profile involving use of an external Relay service and abuse of mixed passive content to bootstrap communications, as described in Taylor presentation at Cape Town Interop (2016). This has been shown to work, e.g. it is currently deployed at ASI-SSDC based on a custom/prototype JSAMP hub, see Verrecchia presentation at Paris Interop (2019). This solution however is not elegant, efficient, robust or nice. There is some more discussion of this as well as alternative bad solutions in https://arxiv.org/abs/1912.00917 (presented by Taylor at ADASS 2019; this paper is now mostly obsolete).

Good solution?

Following discussion at Groningen Interop (2019), some more progress was made that could get HTTPS-based web applications to use the Web Profile as it stands:

  • Felix Stoehr pointed out that in recent tests, this just works in some browsers anyway, i.e. the problem has just gone away. This was a surprise, that arises from changes to the various w3c security standards over the last few years (see analysis).
  • Sonia Zorba prepared a browser extension samp-browser-extension for browsers that still have problems with this
These two developments may provide a good-enough solution to this problem; some (hopefully increasingly many) browsers will work anyway, and for others users can be encouraged to install a browser extension that will make them work.

Current status

We are assessing which browsers now support Web SAMP over HTTPS without making any special arrangements. Thanks to those who have tried out browser/OS combinations following the instructions below. The headline results seem to be:

Changed:
<
<
  • Recent versions of Firefox and Chrome: SAMP over HTTPS works with no problems
>
>
  • Recent versions of Firefox, Chrome, Edge: SAMP over HTTPS works with no problems
 
  • Safari: SAMP over HTTPS doesn't work
Changed:
<
<
  • Others: Vivaldi works
>
>
  • Others: Vivaldi works. Luakit works. Internet Explorer: not sure.
 
  • ... but there are apparently exceptions; I've highlighted these in the table
The OS doesn't seem to make a difference (Linux, MacOS, Windows 10 all tried).

This looks quite positive; services may decide on that basis that it's worth providing Web SAMP in HTTPS-based services on the basis that they will work for many/most users. Optionally, they could provide the browser extensions for others.

If you use a browser not in the above list, please consider following the instructions below to try it out and add your results into the table (or if you have trouble editing the wiki you can mail m.b.taylor@bristol.ac.uk and I'll add them).

You can try this out using your browser/OS combination(s):

To work out the status of HTTPS+SAMP on your browser/OS, follow these easy instructions:

  1. Start a SAMP Hub+client on your machine (e.g. run TOPCAT)
  2. Visit this HTTP page. Click the button.
    • A popup should appear asking you to allow SAMP registration from a web application (with an http://... Origin). Accept, and a table should be loaded in TOPCAT. (If this doesn't happen, your problems are not related to HTTPS)
  3. Visit this HTTPS page. Click the button.
    • Either as before, you are prompted to allow registration (for a web app with an https://... Origin) and a table is loaded in TOPCAT as before - this means SAMP+HTTPS does work on your browser
    • Or nothing happens - this means SAMP+HTTPS does not work on your browser.
  4. Record in the table below whether it did or didn't work ("yes" or "no" in the Works out of the box? column)
If you've done that but don't have easy write access to the wiki, you can mail your results to either m.b.taylor@bristol.ac.uk or apps-samp@ivoa.net.

(If you want to try some more interesting examples, including 2-way communications, others are available: HTTP / HTTPS. I'm expecting that if HTTPS works/fails for one SAMP example it will be the same for all, but if you find different, please report it).

Results: some anomalous outcomes are highlighted

HTTPS + SAMP Survey
Browser Version OS Works out of the box? Reporter
Chrome 77 Ubuntu yes Felix Stoehr
Chromium 78.0 Ubuntu yes Mark Taylor
Chromium 85.0 Ubuntu yes Mark Taylor
Firefox 70.0.1 OSX Mojave yes Felix Stoehr
Firefox 70.0 Ubuntu no Felix Stoehr
Firefox 59 RHEL6 no Mark Taylor
Firefox 70.0.1 Ubuntu no Mark Taylor
Firefox 81.0 Ubuntu yes Mark Taylor
Firefox Nightly 75.0 (64-bit) GUIX yes Hugo Buddelmeijer
Chrome 85.0 MacOS 10.13.6 yes Thomas Boch
Firefox 81.0 MacOS 10.13.6 yes Thomas Boch
Safari 13.1.2 MacOS 10.13.6 no Thomas Boch
Chrome 85.0 Fedora 31 yes Marco Molinaro
Firefox 80.0 Fedora 31 yes Marco Molinaro
Chrome 85.0. MacOS 10.11.3 yes Susana Sánchez Expósito
Firefox 78.2 MacOS 10.11.3 yes Susana Sánchez Expósito
Safari 9.0.3 MacOS 10.11.3 No Susana Sánchez Expósito
Firefox 81.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Chrome 85.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Safari 13.1 MacOS 10.14.6 No Susana Sánchez Expósito
Firefox 81.0(64 bits) Ubuntu 20.04.1 LTS yes Regis Haigron
Firefox 80 Windows 10 yes Regis Haigron
Firefox 81.0(64 bits) Ubuntu 18.04.1 LTS yes Pierre Le Sidaner
Chrome 86.0.4240.75 Ubuntu 18.04.1 LTS Yes Pierre Le Sidaner
Vivaldi 3.3.2022.47 Ubuntu 18.04.1 LTS Yes Pierre Le Sidaner
Chrome 84.0.4147.125 MacOS 10.12.5 Yes Juan Carlos Segovia
Safari 10.1.1 MacOS 10.12.5 No Juan Carlos Segovia
Firefox 75.0 MacOS 10.12.5 Yes Juan Carlos Segovia
Chrome 57.0 MacOS 10.12.6 Yes Alcione Mora
Safari 11.0.2 MacOS 10.12.6 Yes Alcione Mora
Firefox 69.0 MacOS 10.12.6 Yes Alcione Mora
Chrome 86.0 MacOS 10.14.6 Yes Hector Canovas
Safari 12.1.2 MacOS 10.14.6 No Hector Canovas
Firefox 81.0.1 MacOS 10.14.6 No Hector Canovas
Edge 86.0 Windows 10.0 Yes Mark Taylor
Chrome 86.0.4240.80 MacOS 10.13.6 Yes Tom Donaldson
Firefox 81.0.2 MacOS 10.13.6 Yes Tom Donaldson
Safari 13.1.2 MacOS 10.13.6 No Tom Donaldson
Luakit 2.0.0 Debian buster Yes Markus
Internet Explorer 11.0.9600.19867 Windows Server 2012 R2 Standard No Yan Grange
Internet Explorer 11.1198.18362.0 Windows 10 1909 Yes Yan Grange
Edge 87.0.664.47 Windows 10 1909 Yes Yan Grange
Added:
>
>
Internet Explorer 11.630.19041.0 Windows 10 19041 No? Mark Taylor
  For more discussion on this topic, see the apps-samp mailing list.

-- MarkTaylor - 2020-10-13

Revision 142020-11-30 - YanGrange

 
META TOPICPARENT name="SampInfo"

Web SAMP and HTTPS

Problem

The SAMP Web Profile allows web applications to talk to other SAMP clients, communicating with the Hub using an XMLHttpRequest to a well-known port (21012) on the local host. There are problems with doing this if the web page hosting the web application is served from HTTPS rather than HTTP, since access to the hub URL http://localhost:21012/ counts (at least in some interpretations) as mixed active content, which is generally blocked by browsers. This issue has been known since 2014, but is becoming more pressing as more data providers use HTTPS for service delivery. See Presentation at Sydney Interop (2015) for more details.

Bad solution

A possible solution was proposed that defines a new Profile involving use of an external Relay service and abuse of mixed passive content to bootstrap communications, as described in Taylor presentation at Cape Town Interop (2016). This has been shown to work, e.g. it is currently deployed at ASI-SSDC based on a custom/prototype JSAMP hub, see Verrecchia presentation at Paris Interop (2019). This solution however is not elegant, efficient, robust or nice. There is some more discussion of this as well as alternative bad solutions in https://arxiv.org/abs/1912.00917 (presented by Taylor at ADASS 2019; this paper is now mostly obsolete).

Good solution?

Following discussion at Groningen Interop (2019), some more progress was made that could get HTTPS-based web applications to use the Web Profile as it stands:

  • Felix Stoehr pointed out that in recent tests, this just works in some browsers anyway, i.e. the problem has just gone away. This was a surprise, that arises from changes to the various w3c security standards over the last few years (see analysis).
  • Sonia Zorba prepared a browser extension samp-browser-extension for browsers that still have problems with this
These two developments may provide a good-enough solution to this problem; some (hopefully increasingly many) browsers will work anyway, and for others users can be encouraged to install a browser extension that will make them work.

Current status

We are assessing which browsers now support Web SAMP over HTTPS without making any special arrangements. Thanks to those who have tried out browser/OS combinations following the instructions below. The headline results seem to be:

  • Recent versions of Firefox and Chrome: SAMP over HTTPS works with no problems
  • Safari: SAMP over HTTPS doesn't work
  • Others: Vivaldi works
  • ... but there are apparently exceptions; I've highlighted these in the table
The OS doesn't seem to make a difference (Linux, MacOS, Windows 10 all tried).

This looks quite positive; services may decide on that basis that it's worth providing Web SAMP in HTTPS-based services on the basis that they will work for many/most users. Optionally, they could provide the browser extensions for others.

If you use a browser not in the above list, please consider following the instructions below to try it out and add your results into the table (or if you have trouble editing the wiki you can mail m.b.taylor@bristol.ac.uk and I'll add them).

You can try this out using your browser/OS combination(s):

To work out the status of HTTPS+SAMP on your browser/OS, follow these easy instructions:

  1. Start a SAMP Hub+client on your machine (e.g. run TOPCAT)
  2. Visit this HTTP page. Click the button.
    • A popup should appear asking you to allow SAMP registration from a web application (with an http://... Origin). Accept, and a table should be loaded in TOPCAT. (If this doesn't happen, your problems are not related to HTTPS)
  3. Visit this HTTPS page. Click the button.
    • Either as before, you are prompted to allow registration (for a web app with an https://... Origin) and a table is loaded in TOPCAT as before - this means SAMP+HTTPS does work on your browser
    • Or nothing happens - this means SAMP+HTTPS does not work on your browser.
  4. Record in the table below whether it did or didn't work ("yes" or "no" in the Works out of the box? column)
If you've done that but don't have easy write access to the wiki, you can mail your results to either m.b.taylor@bristol.ac.uk or apps-samp@ivoa.net.

(If you want to try some more interesting examples, including 2-way communications, others are available: HTTP / HTTPS. I'm expecting that if HTTPS works/fails for one SAMP example it will be the same for all, but if you find different, please report it).

Results: some anomalous outcomes are highlighted

HTTPS + SAMP Survey
Browser Version OS Works out of the box? Reporter
Chrome 77 Ubuntu yes Felix Stoehr
Chromium 78.0 Ubuntu yes Mark Taylor
Chromium 85.0 Ubuntu yes Mark Taylor
Firefox 70.0.1 OSX Mojave yes Felix Stoehr
Firefox 70.0 Ubuntu no Felix Stoehr
Firefox 59 RHEL6 no Mark Taylor
Firefox 70.0.1 Ubuntu no Mark Taylor
Firefox 81.0 Ubuntu yes Mark Taylor
Firefox Nightly 75.0 (64-bit) GUIX yes Hugo Buddelmeijer
Chrome 85.0 MacOS 10.13.6 yes Thomas Boch
Firefox 81.0 MacOS 10.13.6 yes Thomas Boch
Safari 13.1.2 MacOS 10.13.6 no Thomas Boch
Chrome 85.0 Fedora 31 yes Marco Molinaro
Firefox 80.0 Fedora 31 yes Marco Molinaro
Chrome 85.0. MacOS 10.11.3 yes Susana Sánchez Expósito
Firefox 78.2 MacOS 10.11.3 yes Susana Sánchez Expósito
Safari 9.0.3 MacOS 10.11.3 No Susana Sánchez Expósito
Firefox 81.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Chrome 85.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Safari 13.1 MacOS 10.14.6 No Susana Sánchez Expósito
Firefox 81.0(64 bits) Ubuntu 20.04.1 LTS yes Regis Haigron
Firefox 80 Windows 10 yes Regis Haigron
Firefox 81.0(64 bits) Ubuntu 18.04.1 LTS yes Pierre Le Sidaner
Chrome 86.0.4240.75 Ubuntu 18.04.1 LTS Yes Pierre Le Sidaner
Vivaldi 3.3.2022.47 Ubuntu 18.04.1 LTS Yes Pierre Le Sidaner
Chrome 84.0.4147.125 MacOS 10.12.5 Yes Juan Carlos Segovia
Safari 10.1.1 MacOS 10.12.5 No Juan Carlos Segovia
Firefox 75.0 MacOS 10.12.5 Yes Juan Carlos Segovia
Chrome 57.0 MacOS 10.12.6 Yes Alcione Mora
Safari 11.0.2 MacOS 10.12.6 Yes Alcione Mora
Firefox 69.0 MacOS 10.12.6 Yes Alcione Mora
Chrome 86.0 MacOS 10.14.6 Yes Hector Canovas
Safari 12.1.2 MacOS 10.14.6 No Hector Canovas
Firefox 81.0.1 MacOS 10.14.6 No Hector Canovas
Edge 86.0 Windows 10.0 Yes Mark Taylor
Chrome 86.0.4240.80 MacOS 10.13.6 Yes Tom Donaldson
Firefox 81.0.2 MacOS 10.13.6 Yes Tom Donaldson
Safari 13.1.2 MacOS 10.13.6 No Tom Donaldson
Luakit 2.0.0 Debian buster Yes Markus
Added:
>
>
Internet Explorer 11.0.9600.19867 Windows Server 2012 R2 Standard No Yan Grange
Internet Explorer 11.1198.18362.0 Windows 10 1909 Yes Yan Grange
Edge 87.0.664.47 Windows 10 1909 Yes Yan Grange
  For more discussion on this topic, see the apps-samp mailing list.

-- MarkTaylor - 2020-10-13

Revision 132020-11-18 - MarkusDemleitner

 
META TOPICPARENT name="SampInfo"

Web SAMP and HTTPS

Problem

The SAMP Web Profile allows web applications to talk to other SAMP clients, communicating with the Hub using an XMLHttpRequest to a well-known port (21012) on the local host. There are problems with doing this if the web page hosting the web application is served from HTTPS rather than HTTP, since access to the hub URL http://localhost:21012/ counts (at least in some interpretations) as mixed active content, which is generally blocked by browsers. This issue has been known since 2014, but is becoming more pressing as more data providers use HTTPS for service delivery. See Presentation at Sydney Interop (2015) for more details.

Bad solution

A possible solution was proposed that defines a new Profile involving use of an external Relay service and abuse of mixed passive content to bootstrap communications, as described in Taylor presentation at Cape Town Interop (2016). This has been shown to work, e.g. it is currently deployed at ASI-SSDC based on a custom/prototype JSAMP hub, see Verrecchia presentation at Paris Interop (2019). This solution however is not elegant, efficient, robust or nice. There is some more discussion of this as well as alternative bad solutions in https://arxiv.org/abs/1912.00917 (presented by Taylor at ADASS 2019; this paper is now mostly obsolete).

Good solution?

Following discussion at Groningen Interop (2019), some more progress was made that could get HTTPS-based web applications to use the Web Profile as it stands:

  • Felix Stoehr pointed out that in recent tests, this just works in some browsers anyway, i.e. the problem has just gone away. This was a surprise, that arises from changes to the various w3c security standards over the last few years (see analysis).
  • Sonia Zorba prepared a browser extension samp-browser-extension for browsers that still have problems with this
These two developments may provide a good-enough solution to this problem; some (hopefully increasingly many) browsers will work anyway, and for others users can be encouraged to install a browser extension that will make them work.

Current status

We are assessing which browsers now support Web SAMP over HTTPS without making any special arrangements. Thanks to those who have tried out browser/OS combinations following the instructions below. The headline results seem to be:

  • Recent versions of Firefox and Chrome: SAMP over HTTPS works with no problems
  • Safari: SAMP over HTTPS doesn't work
  • Others: Vivaldi works
  • ... but there are apparently exceptions; I've highlighted these in the table
The OS doesn't seem to make a difference (Linux, MacOS, Windows 10 all tried).

This looks quite positive; services may decide on that basis that it's worth providing Web SAMP in HTTPS-based services on the basis that they will work for many/most users. Optionally, they could provide the browser extensions for others.

If you use a browser not in the above list, please consider following the instructions below to try it out and add your results into the table (or if you have trouble editing the wiki you can mail m.b.taylor@bristol.ac.uk and I'll add them).

You can try this out using your browser/OS combination(s):

To work out the status of HTTPS+SAMP on your browser/OS, follow these easy instructions:

  1. Start a SAMP Hub+client on your machine (e.g. run TOPCAT)
  2. Visit this HTTP page. Click the button.
    • A popup should appear asking you to allow SAMP registration from a web application (with an http://... Origin). Accept, and a table should be loaded in TOPCAT. (If this doesn't happen, your problems are not related to HTTPS)
  3. Visit this HTTPS page. Click the button.
    • Either as before, you are prompted to allow registration (for a web app with an https://... Origin) and a table is loaded in TOPCAT as before - this means SAMP+HTTPS does work on your browser
    • Or nothing happens - this means SAMP+HTTPS does not work on your browser.
  4. Record in the table below whether it did or didn't work ("yes" or "no" in the Works out of the box? column)
If you've done that but don't have easy write access to the wiki, you can mail your results to either m.b.taylor@bristol.ac.uk or apps-samp@ivoa.net.

(If you want to try some more interesting examples, including 2-way communications, others are available: HTTP / HTTPS. I'm expecting that if HTTPS works/fails for one SAMP example it will be the same for all, but if you find different, please report it).

Results: some anomalous outcomes are highlighted

HTTPS + SAMP Survey
Browser Version OS Works out of the box? Reporter
Chrome 77 Ubuntu yes Felix Stoehr
Chromium 78.0 Ubuntu yes Mark Taylor
Chromium 85.0 Ubuntu yes Mark Taylor
Firefox 70.0.1 OSX Mojave yes Felix Stoehr
Firefox 70.0 Ubuntu no Felix Stoehr
Firefox 59 RHEL6 no Mark Taylor
Firefox 70.0.1 Ubuntu no Mark Taylor
Firefox 81.0 Ubuntu yes Mark Taylor
Firefox Nightly 75.0 (64-bit) GUIX yes Hugo Buddelmeijer
Chrome 85.0 MacOS 10.13.6 yes Thomas Boch
Firefox 81.0 MacOS 10.13.6 yes Thomas Boch
Safari 13.1.2 MacOS 10.13.6 no Thomas Boch
Chrome 85.0 Fedora 31 yes Marco Molinaro
Firefox 80.0 Fedora 31 yes Marco Molinaro
Chrome 85.0. MacOS 10.11.3 yes Susana Sánchez Expósito
Firefox 78.2 MacOS 10.11.3 yes Susana Sánchez Expósito
Safari 9.0.3 MacOS 10.11.3 No Susana Sánchez Expósito
Firefox 81.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Chrome 85.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Safari 13.1 MacOS 10.14.6 No Susana Sánchez Expósito
Firefox 81.0(64 bits) Ubuntu 20.04.1 LTS yes Regis Haigron
Firefox 80 Windows 10 yes Regis Haigron
Firefox 81.0(64 bits) Ubuntu 18.04.1 LTS yes Pierre Le Sidaner
Chrome 86.0.4240.75 Ubuntu 18.04.1 LTS Yes Pierre Le Sidaner
Vivaldi 3.3.2022.47 Ubuntu 18.04.1 LTS Yes Pierre Le Sidaner
Chrome 84.0.4147.125 MacOS 10.12.5 Yes Juan Carlos Segovia
Safari 10.1.1 MacOS 10.12.5 No Juan Carlos Segovia
Firefox 75.0 MacOS 10.12.5 Yes Juan Carlos Segovia
Chrome 57.0 MacOS 10.12.6 Yes Alcione Mora
Safari 11.0.2 MacOS 10.12.6 Yes Alcione Mora
Firefox 69.0 MacOS 10.12.6 Yes Alcione Mora
Chrome 86.0 MacOS 10.14.6 Yes Hector Canovas
Safari 12.1.2 MacOS 10.14.6 No Hector Canovas
Firefox 81.0.1 MacOS 10.14.6 No Hector Canovas
Edge 86.0 Windows 10.0 Yes Mark Taylor
Chrome 86.0.4240.80 MacOS 10.13.6 Yes Tom Donaldson
Firefox 81.0.2 MacOS 10.13.6 Yes Tom Donaldson
Safari 13.1.2 MacOS 10.13.6 No Tom Donaldson
Added:
>
>
Luakit 2.0.0 Debian buster Yes Markus
  For more discussion on this topic, see the apps-samp mailing list.

-- MarkTaylor - 2020-10-13

Revision 122020-10-23 - TomDonaldson

 
META TOPICPARENT name="SampInfo"

Web SAMP and HTTPS

Problem

Added:
>
>
 The SAMP Web Profile allows web applications to talk to other SAMP clients, communicating with the Hub using an XMLHttpRequest to a well-known port (21012) on the local host. There are problems with doing this if the web page hosting the web application is served from HTTPS rather than HTTP, since access to the hub URL http://localhost:21012/ counts (at least in some interpretations) as mixed active content, which is generally blocked by browsers. This issue has been known since 2014, but is becoming more pressing as more data providers use HTTPS for service delivery. See Presentation at Sydney Interop (2015) for more details.

Bad solution

Deleted:
<
<
A possible solution was proposed that defines a new Profile involving use of an external Relay service and abuse of mixed passive content to bootstrap communications, as described in Taylor presentation at Cape Town Interop (2016). This has been shown to work, e.g. it is currently deployed at ASI-SSDC based on a custom/prototype JSAMP hub, see Verrecchia presentation at Paris Interop (2019). This solution however is not elegant, efficient, robust or nice. There is some more discussion of this as well as alternative bad solutions in https://arxiv.org/abs/1912.00917 (presented by Taylor at ADASS 2019; this paper is now mostly obsolete).
 
Added:
>
>
A possible solution was proposed that defines a new Profile involving use of an external Relay service and abuse of mixed passive content to bootstrap communications, as described in Taylor presentation at Cape Town Interop (2016). This has been shown to work, e.g. it is currently deployed at ASI-SSDC based on a custom/prototype JSAMP hub, see Verrecchia presentation at Paris Interop (2019). This solution however is not elegant, efficient, robust or nice. There is some more discussion of this as well as alternative bad solutions in https://arxiv.org/abs/1912.00917 (presented by Taylor at ADASS 2019; this paper is now mostly obsolete).
 

Good solution?

Following discussion at Groningen Interop (2019), some more progress was made that could get HTTPS-based web applications to use the Web Profile as it stands:

Changed:
<
<
  • Felix Stoehr pointed out that in recent tests, this just works in some browsers anyway, i.e. the problem has just gone away. This was a surprise, that arises from changes to the various w3c security standards over the last few years (see analysis).
>
>
  • Felix Stoehr pointed out that in recent tests, this just works in some browsers anyway, i.e. the problem has just gone away. This was a surprise, that arises from changes to the various w3c security standards over the last few years (see analysis).
 
  • Sonia Zorba prepared a browser extension samp-browser-extension for browsers that still have problems with this
Deleted:
<
<
 These two developments may provide a good-enough solution to this problem; some (hopefully increasingly many) browsers will work anyway, and for others users can be encouraged to install a browser extension that will make them work.

Current status

Changed:
<
<
We are assessing which browsers now support Web SAMP over HTTPS without making any special arrangements. Thanks to those who have tried out browser/OS combinations following the instructions below. The headline results seem to be:
>
>
We are assessing which browsers now support Web SAMP over HTTPS without making any special arrangements. Thanks to those who have tried out browser/OS combinations following the instructions below. The headline results seem to be:
 
  • Recent versions of Firefox and Chrome: SAMP over HTTPS works with no problems
  • Safari: SAMP over HTTPS doesn't work
  • Others: Vivaldi works
  • ... but there are apparently exceptions; I've highlighted these in the table
Deleted:
<
<
 The OS doesn't seem to make a difference (Linux, MacOS, Windows 10 all tried).
Changed:
<
<
This looks quite positive; services may decide on that basis that it's worth providing Web SAMP in HTTPS-based services on the basis that they will work for many/most users. Optionally, they could provide the browser extensions for others.
>
>
This looks quite positive; services may decide on that basis that it's worth providing Web SAMP in HTTPS-based services on the basis that they will work for many/most users. Optionally, they could provide the browser extensions for others.
  If you use a browser not in the above list, please consider following the instructions below to try it out and add your results into the table (or if you have trouble editing the wiki you can mail m.b.taylor@bristol.ac.uk and I'll add them).

You can try this out using your browser/OS combination(s):

To work out the status of HTTPS+SAMP on your browser/OS, follow these easy instructions:

  1. Start a SAMP Hub+client on your machine (e.g. run TOPCAT)
  2. Visit this HTTP page. Click the button.
    • A popup should appear asking you to allow SAMP registration from a web application (with an http://... Origin). Accept, and a table should be loaded in TOPCAT. (If this doesn't happen, your problems are not related to HTTPS)
  3. Visit this HTTPS page. Click the button.
    • Either as before, you are prompted to allow registration (for a web app with an https://... Origin) and a table is loaded in TOPCAT as before - this means SAMP+HTTPS does work on your browser
    • Or nothing happens - this means SAMP+HTTPS does not work on your browser.
  4. Record in the table below whether it did or didn't work ("yes" or "no" in the Works out of the box? column)
If you've done that but don't have easy write access to the wiki, you can mail your results to either m.b.taylor@bristol.ac.uk or apps-samp@ivoa.net.

(If you want to try some more interesting examples, including 2-way communications, others are available: HTTP / HTTPS. I'm expecting that if HTTPS works/fails for one SAMP example it will be the same for all, but if you find different, please report it).

Results: some anomalous outcomes are highlighted

HTTPS + SAMP Survey
Browser Version OS Works out of the box? Reporter
Chrome 77 Ubuntu yes Felix Stoehr
Chromium 78.0 Ubuntu yes Mark Taylor
Chromium 85.0 Ubuntu yes Mark Taylor
Firefox 70.0.1 OSX Mojave yes Felix Stoehr
Firefox 70.0 Ubuntu no Felix Stoehr
Firefox 59 RHEL6 no Mark Taylor
Firefox 70.0.1 Ubuntu no Mark Taylor
Firefox 81.0 Ubuntu yes Mark Taylor
Firefox Nightly 75.0 (64-bit) GUIX yes Hugo Buddelmeijer
Chrome 85.0 MacOS 10.13.6 yes Thomas Boch
Firefox 81.0 MacOS 10.13.6 yes Thomas Boch
Safari 13.1.2 MacOS 10.13.6 no Thomas Boch
Chrome 85.0 Fedora 31 yes Marco Molinaro
Firefox 80.0 Fedora 31 yes Marco Molinaro
Chrome 85.0. MacOS 10.11.3 yes Susana Sánchez Expósito
Firefox 78.2 MacOS 10.11.3 yes Susana Sánchez Expósito
Safari 9.0.3 MacOS 10.11.3 No Susana Sánchez Expósito
Firefox 81.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Chrome 85.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Safari 13.1 MacOS 10.14.6 No Susana Sánchez Expósito
Firefox 81.0(64 bits) Ubuntu 20.04.1 LTS yes Regis Haigron
Firefox 80 Windows 10 yes Regis Haigron
Firefox 81.0(64 bits) Ubuntu 18.04.1 LTS yes Pierre Le Sidaner
Chrome 86.0.4240.75 Ubuntu 18.04.1 LTS Yes Pierre Le Sidaner
Vivaldi 3.3.2022.47 Ubuntu 18.04.1 LTS Yes Pierre Le Sidaner
Chrome 84.0.4147.125 MacOS 10.12.5 Yes Juan Carlos Segovia
Safari 10.1.1 MacOS 10.12.5 No Juan Carlos Segovia
Firefox 75.0 MacOS 10.12.5 Yes Juan Carlos Segovia
Chrome 57.0 MacOS 10.12.6 Yes Alcione Mora
Safari 11.0.2 MacOS 10.12.6 Yes Alcione Mora
Firefox 69.0 MacOS 10.12.6 Yes Alcione Mora
Chrome 86.0 MacOS 10.14.6 Yes Hector Canovas
Safari 12.1.2 MacOS 10.14.6 No Hector Canovas
Firefox 81.0.1 MacOS 10.14.6 No Hector Canovas
Edge 86.0 Windows 10.0 Yes Mark Taylor
Changed:
<
<
>
>
Chrome 86.0.4240.80 MacOS 10.13.6 Yes Tom Donaldson
Added:
>
>
Firefox 81.0.2 MacOS 10.13.6 Yes Tom Donaldson
Safari 13.1.2 MacOS 10.13.6 No Tom Donaldson
  For more discussion on this topic, see the apps-samp mailing list.

-- MarkTaylor - 2020-10-13

Revision 112020-10-15 - MarkTaylor

 
META TOPICPARENT name="SampInfo"

Web SAMP and HTTPS

Problem

The SAMP Web Profile allows web applications to talk to other SAMP clients, communicating with the Hub using an XMLHttpRequest to a well-known port (21012) on the local host. There are problems with doing this if the web page hosting the web application is served from HTTPS rather than HTTP, since access to the hub URL http://localhost:21012/ counts (at least in some interpretations) as mixed active content, which is generally blocked by browsers. This issue has been known since 2014, but is becoming more pressing as more data providers use HTTPS for service delivery. See Presentation at Sydney Interop (2015) for more details.

Bad solution

A possible solution was proposed that defines a new Profile involving use of an external Relay service and abuse of mixed passive content to bootstrap communications, as described in Taylor presentation at Cape Town Interop (2016). This has been shown to work, e.g. it is currently deployed at ASI-SSDC based on a custom/prototype JSAMP hub, see Verrecchia presentation at Paris Interop (2019). This solution however is not elegant, efficient, robust or nice. There is some more discussion of this as well as alternative bad solutions in https://arxiv.org/abs/1912.00917 (presented by Taylor at ADASS 2019; this paper is now mostly obsolete).

Good solution?

Following discussion at Groningen Interop (2019), some more progress was made that could get HTTPS-based web applications to use the Web Profile as it stands:

  • Felix Stoehr pointed out that in recent tests, this just works in some browsers anyway, i.e. the problem has just gone away. This was a surprise, that arises from changes to the various w3c security standards over the last few years (see analysis).
  • Sonia Zorba prepared a browser extension samp-browser-extension for browsers that still have problems with this

These two developments may provide a good-enough solution to this problem; some (hopefully increasingly many) browsers will work anyway, and for others users can be encouraged to install a browser extension that will make them work.

Current status

We are assessing which browsers now support Web SAMP over HTTPS without making any special arrangements. Thanks to those who have tried out browser/OS combinations following the instructions below. The headline results seem to be:

  • Recent versions of Firefox and Chrome: SAMP over HTTPS works with no problems
  • Safari: SAMP over HTTPS doesn't work
  • Others: Vivaldi works
  • ... but there are apparently exceptions; I've highlighted these in the table

The OS doesn't seem to make a difference (Linux, MacOS, Windows 10 all tried).

This looks quite positive; services may decide on that basis that it's worth providing Web SAMP in HTTPS-based services on the basis that they will work for many/most users. Optionally, they could provide the browser extensions for others.

If you use a browser not in the above list, please consider following the instructions below to try it out and add your results into the table (or if you have trouble editing the wiki you can mail m.b.taylor@bristol.ac.uk and I'll add them).

You can try this out using your browser/OS combination(s):

To work out the status of HTTPS+SAMP on your browser/OS, follow these easy instructions:

  1. Start a SAMP Hub+client on your machine (e.g. run TOPCAT)
  2. Visit this HTTP page. Click the button.
    • A popup should appear asking you to allow SAMP registration from a web application (with an http://... Origin). Accept, and a table should be loaded in TOPCAT. (If this doesn't happen, your problems are not related to HTTPS)
  3. Visit this HTTPS page. Click the button.
    • Either as before, you are prompted to allow registration (for a web app with an https://... Origin) and a table is loaded in TOPCAT as before - this means SAMP+HTTPS does work on your browser
    • Or nothing happens - this means SAMP+HTTPS does not work on your browser.
  4. Record in the table below whether it did or didn't work ("yes" or "no" in the Works out of the box? column)
If you've done that but don't have easy write access to the wiki, you can mail your results to either m.b.taylor@bristol.ac.uk or apps-samp@ivoa.net.

(If you want to try some more interesting examples, including 2-way communications, others are available: HTTP / HTTPS. I'm expecting that if HTTPS works/fails for one SAMP example it will be the same for all, but if you find different, please report it).

Results: some anomalous outcomes are highlighted

HTTPS + SAMP Survey
Browser Version OS Works out of the box? Reporter
Chrome 77 Ubuntu yes Felix Stoehr
Chromium 78.0 Ubuntu yes Mark Taylor
Chromium 85.0 Ubuntu yes Mark Taylor
Firefox 70.0.1 OSX Mojave yes Felix Stoehr
Firefox 70.0 Ubuntu no Felix Stoehr
Firefox 59 RHEL6 no Mark Taylor
Firefox 70.0.1 Ubuntu no Mark Taylor
Firefox 81.0 Ubuntu yes Mark Taylor
Firefox Nightly 75.0 (64-bit) GUIX yes Hugo Buddelmeijer
Chrome 85.0 MacOS 10.13.6 yes Thomas Boch
Firefox 81.0 MacOS 10.13.6 yes Thomas Boch
Safari 13.1.2 MacOS 10.13.6 no Thomas Boch
Chrome 85.0 Fedora 31 yes Marco Molinaro
Firefox 80.0 Fedora 31 yes Marco Molinaro
Chrome 85.0. MacOS 10.11.3 yes Susana Sánchez Expósito
Firefox 78.2 MacOS 10.11.3 yes Susana Sánchez Expósito
Safari 9.0.3 MacOS 10.11.3 No Susana Sánchez Expósito
Firefox 81.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Chrome 85.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Safari 13.1 MacOS 10.14.6 No Susana Sánchez Expósito
Firefox 81.0(64 bits) Ubuntu 20.04.1 LTS yes Regis Haigron
Firefox 80 Windows 10 yes Regis Haigron
Firefox 81.0(64 bits) Ubuntu 18.04.1 LTS yes Pierre Le Sidaner
Chrome 86.0.4240.75 Ubuntu 18.04.1 LTS Yes Pierre Le Sidaner
Vivaldi 3.3.2022.47 Ubuntu 18.04.1 LTS Yes Pierre Le Sidaner
Chrome 84.0.4147.125 MacOS 10.12.5 Yes Juan Carlos Segovia
Safari 10.1.1 MacOS 10.12.5 No Juan Carlos Segovia
Firefox 75.0 MacOS 10.12.5 Yes Juan Carlos Segovia
Chrome 57.0 MacOS 10.12.6 Yes Alcione Mora
Safari 11.0.2 MacOS 10.12.6 Yes Alcione Mora
Firefox 69.0 MacOS 10.12.6 Yes Alcione Mora
Chrome 86.0 MacOS 10.14.6 Yes Hector Canovas
Safari 12.1.2 MacOS 10.14.6 No Hector Canovas
Firefox 81.0.1 MacOS 10.14.6 No Hector Canovas
Changed:
<
<
Edge 86.0 Windows Yes Mark Taylor
>
>
Edge 86.0 Windows 10.0 Yes Mark Taylor
 

For more discussion on this topic, see the apps-samp mailing list.

-- MarkTaylor - 2020-10-13

Revision 102020-10-15 - MarkTaylor

 
META TOPICPARENT name="SampInfo"

Web SAMP and HTTPS

Problem

The SAMP Web Profile allows web applications to talk to other SAMP clients, communicating with the Hub using an XMLHttpRequest to a well-known port (21012) on the local host. There are problems with doing this if the web page hosting the web application is served from HTTPS rather than HTTP, since access to the hub URL http://localhost:21012/ counts (at least in some interpretations) as mixed active content, which is generally blocked by browsers. This issue has been known since 2014, but is becoming more pressing as more data providers use HTTPS for service delivery. See Presentation at Sydney Interop (2015) for more details.

Bad solution

A possible solution was proposed that defines a new Profile involving use of an external Relay service and abuse of mixed passive content to bootstrap communications, as described in Taylor presentation at Cape Town Interop (2016). This has been shown to work, e.g. it is currently deployed at ASI-SSDC based on a custom/prototype JSAMP hub, see Verrecchia presentation at Paris Interop (2019). This solution however is not elegant, efficient, robust or nice. There is some more discussion of this as well as alternative bad solutions in https://arxiv.org/abs/1912.00917 (presented by Taylor at ADASS 2019; this paper is now mostly obsolete).

Good solution?

Following discussion at Groningen Interop (2019), some more progress was made that could get HTTPS-based web applications to use the Web Profile as it stands:

  • Felix Stoehr pointed out that in recent tests, this just works in some browsers anyway, i.e. the problem has just gone away. This was a surprise, that arises from changes to the various w3c security standards over the last few years (see analysis).
  • Sonia Zorba prepared a browser extension samp-browser-extension for browsers that still have problems with this

These two developments may provide a good-enough solution to this problem; some (hopefully increasingly many) browsers will work anyway, and for others users can be encouraged to install a browser extension that will make them work.

Current status

We are assessing which browsers now support Web SAMP over HTTPS without making any special arrangements. Thanks to those who have tried out browser/OS combinations following the instructions below. The headline results seem to be:

  • Recent versions of Firefox and Chrome: SAMP over HTTPS works with no problems
  • Safari: SAMP over HTTPS doesn't work
  • Others: Vivaldi works
  • ... but there are apparently exceptions; I've highlighted these in the table

The OS doesn't seem to make a difference (Linux, MacOS, Windows 10 all tried).

This looks quite positive; services may decide on that basis that it's worth providing Web SAMP in HTTPS-based services on the basis that they will work for many/most users. Optionally, they could provide the browser extensions for others.

If you use a browser not in the above list, please consider following the instructions below to try it out and add your results into the table (or if you have trouble editing the wiki you can mail m.b.taylor@bristol.ac.uk and I'll add them).

You can try this out using your browser/OS combination(s):

To work out the status of HTTPS+SAMP on your browser/OS, follow these easy instructions:

  1. Start a SAMP Hub+client on your machine (e.g. run TOPCAT)
  2. Visit this HTTP page. Click the button.
    • A popup should appear asking you to allow SAMP registration from a web application (with an http://... Origin). Accept, and a table should be loaded in TOPCAT. (If this doesn't happen, your problems are not related to HTTPS)
  3. Visit this HTTPS page. Click the button.
    • Either as before, you are prompted to allow registration (for a web app with an https://... Origin) and a table is loaded in TOPCAT as before - this means SAMP+HTTPS does work on your browser
    • Or nothing happens - this means SAMP+HTTPS does not work on your browser.
  4. Record in the table below whether it did or didn't work ("yes" or "no" in the Works out of the box? column)
If you've done that but don't have easy write access to the wiki, you can mail your results to either m.b.taylor@bristol.ac.uk or apps-samp@ivoa.net.

(If you want to try some more interesting examples, including 2-way communications, others are available: HTTP / HTTPS. I'm expecting that if HTTPS works/fails for one SAMP example it will be the same for all, but if you find different, please report it).

Results: some anomalous outcomes are highlighted

HTTPS + SAMP Survey
Browser Version OS Works out of the box? Reporter
Chrome 77 Ubuntu yes Felix Stoehr
Chromium 78.0 Ubuntu yes Mark Taylor
Chromium 85.0 Ubuntu yes Mark Taylor
Firefox 70.0.1 OSX Mojave yes Felix Stoehr
Firefox 70.0 Ubuntu no Felix Stoehr
Firefox 59 RHEL6 no Mark Taylor
Firefox 70.0.1 Ubuntu no Mark Taylor
Firefox 81.0 Ubuntu yes Mark Taylor
Firefox Nightly 75.0 (64-bit) GUIX yes Hugo Buddelmeijer
Chrome 85.0 MacOS 10.13.6 yes Thomas Boch
Firefox 81.0 MacOS 10.13.6 yes Thomas Boch
Safari 13.1.2 MacOS 10.13.6 no Thomas Boch
Chrome 85.0 Fedora 31 yes Marco Molinaro
Firefox 80.0 Fedora 31 yes Marco Molinaro
Chrome 85.0. MacOS 10.11.3 yes Susana Sánchez Expósito
Firefox 78.2 MacOS 10.11.3 yes Susana Sánchez Expósito
Safari 9.0.3 MacOS 10.11.3 No Susana Sánchez Expósito
Firefox 81.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Chrome 85.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Safari 13.1 MacOS 10.14.6 No Susana Sánchez Expósito
Firefox 81.0(64 bits) Ubuntu 20.04.1 LTS yes Regis Haigron
Firefox 80 Windows 10 yes Regis Haigron
Firefox 81.0(64 bits) Ubuntu 18.04.1 LTS yes Pierre Le Sidaner
Chrome 86.0.4240.75 Ubuntu 18.04.1 LTS Yes Pierre Le Sidaner
Vivaldi 3.3.2022.47 Ubuntu 18.04.1 LTS Yes Pierre Le Sidaner
Chrome 84.0.4147.125 MacOS 10.12.5 Yes Juan Carlos Segovia
Safari 10.1.1 MacOS 10.12.5 No Juan Carlos Segovia
Firefox 75.0 MacOS 10.12.5 Yes Juan Carlos Segovia
Chrome 57.0 MacOS 10.12.6 Yes Alcione Mora
Safari 11.0.2 MacOS 10.12.6 Yes Alcione Mora
Firefox 69.0 MacOS 10.12.6 Yes Alcione Mora
Chrome 86.0 MacOS 10.14.6 Yes Hector Canovas
Safari 12.1.2 MacOS 10.14.6 No Hector Canovas
Firefox 81.0.1 MacOS 10.14.6 No Hector Canovas
Added:
>
>
Edge 86.0 Windows Yes Mark Taylor
 

For more discussion on this topic, see the apps-samp mailing list.

-- MarkTaylor - 2020-10-13

Revision 92020-10-13 - MarkTaylor

 
META TOPICPARENT name="SampInfo"

Web SAMP and HTTPS

Problem

The SAMP Web Profile allows web applications to talk to other SAMP clients, communicating with the Hub using an XMLHttpRequest to a well-known port (21012) on the local host. There are problems with doing this if the web page hosting the web application is served from HTTPS rather than HTTP, since access to the hub URL http://localhost:21012/ counts (at least in some interpretations) as mixed active content, which is generally blocked by browsers. This issue has been known since 2014, but is becoming more pressing as more data providers use HTTPS for service delivery. See Presentation at Sydney Interop (2015) for more details.

Bad solution

A possible solution was proposed that defines a new Profile involving use of an external Relay service and abuse of mixed passive content to bootstrap communications, as described in Taylor presentation at Cape Town Interop (2016). This has been shown to work, e.g. it is currently deployed at ASI-SSDC based on a custom/prototype JSAMP hub, see Verrecchia presentation at Paris Interop (2019). This solution however is not elegant, efficient, robust or nice. There is some more discussion of this as well as alternative bad solutions in https://arxiv.org/abs/1912.00917 (presented by Taylor at ADASS 2019; this paper is now mostly obsolete).

Good solution?

Following discussion at Groningen Interop (2019), some more progress was made that could get HTTPS-based web applications to use the Web Profile as it stands:

  • Felix Stoehr pointed out that in recent tests, this just works in some browsers anyway, i.e. the problem has just gone away. This was a surprise, that arises from changes to the various w3c security standards over the last few years (see analysis).
  • Sonia Zorba prepared a browser extension samp-browser-extension for browsers that still have problems with this

These two developments may provide a good-enough solution to this problem; some (hopefully increasingly many) browsers will work anyway, and for others users can be encouraged to install a browser extension that will make them work.

Current status

Changed:
<
<
We are assessing which browsers now support Web SAMP over HTTPS without making any special arrangements. Thanks to those who have tried out browser/OS combinations following the instructions below. The headline result seems to be:
>
>
We are assessing which browsers now support Web SAMP over HTTPS without making any special arrangements. Thanks to those who have tried out browser/OS combinations following the instructions below. The headline results seem to be:
 
  • Recent versions of Firefox and Chrome: SAMP over HTTPS works with no problems
  • Safari: SAMP over HTTPS doesn't work
  • Others: Vivaldi works
Added:
>
>
  • ... but there are apparently exceptions; I've highlighted these in the table
  The OS doesn't seem to make a difference (Linux, MacOS, Windows 10 all tried).

This looks quite positive; services may decide on that basis that it's worth providing Web SAMP in HTTPS-based services on the basis that they will work for many/most users. Optionally, they could provide the browser extensions for others.

If you use a browser not in the above list, please consider following the instructions below to try it out and add your results into the table (or if you have trouble editing the wiki you can mail m.b.taylor@bristol.ac.uk and I'll add them).

You can try this out using your browser/OS combination(s):

To work out the status of HTTPS+SAMP on your browser/OS, follow these easy instructions:

  1. Start a SAMP Hub+client on your machine (e.g. run TOPCAT)
  2. Visit this HTTP page. Click the button.
    • A popup should appear asking you to allow SAMP registration from a web application (with an http://... Origin). Accept, and a table should be loaded in TOPCAT. (If this doesn't happen, your problems are not related to HTTPS)
  3. Visit this HTTPS page. Click the button.
    • Either as before, you are prompted to allow registration (for a web app with an https://... Origin) and a table is loaded in TOPCAT as before - this means SAMP+HTTPS does work on your browser
    • Or nothing happens - this means SAMP+HTTPS does not work on your browser.
  4. Record in the table below whether it did or didn't work ("yes" or "no" in the Works out of the box? column)
If you've done that but don't have easy write access to the wiki, you can mail your results to either m.b.taylor@bristol.ac.uk or apps-samp@ivoa.net.

(If you want to try some more interesting examples, including 2-way communications, others are available: HTTP / HTTPS. I'm expecting that if HTTPS works/fails for one SAMP example it will be the same for all, but if you find different, please report it).

Changed:
<
<
-- MarkTaylor - 2019-10-05
>
>
Results: some anomalous outcomes are highlighted
 
HTTPS + SAMP Survey
Browser Version OS Works out of the box? Reporter
Chrome 77 Ubuntu yes Felix Stoehr
Chromium 78.0 Ubuntu yes Mark Taylor
Chromium 85.0 Ubuntu yes Mark Taylor
Firefox 70.0.1 OSX Mojave yes Felix Stoehr
Firefox 70.0 Ubuntu no Felix Stoehr
Firefox 59 RHEL6 no Mark Taylor
Firefox 70.0.1 Ubuntu no Mark Taylor
Firefox 81.0 Ubuntu yes Mark Taylor
Firefox Nightly 75.0 (64-bit) GUIX yes Hugo Buddelmeijer
Chrome 85.0 MacOS 10.13.6 yes Thomas Boch
Firefox 81.0 MacOS 10.13.6 yes Thomas Boch
Safari 13.1.2 MacOS 10.13.6 no Thomas Boch
Chrome 85.0 Fedora 31 yes Marco Molinaro
Firefox 80.0 Fedora 31 yes Marco Molinaro
Chrome 85.0. MacOS 10.11.3 yes Susana Sánchez Expósito
Firefox 78.2 MacOS 10.11.3 yes Susana Sánchez Expósito
Safari 9.0.3 MacOS 10.11.3 No Susana Sánchez Expósito
Firefox 81.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Chrome 85.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Safari 13.1 MacOS 10.14.6 No Susana Sánchez Expósito
Firefox 81.0(64 bits) Ubuntu 20.04.1 LTS yes Regis Haigron
Firefox 80 Windows 10 yes Regis Haigron
Firefox 81.0(64 bits) Ubuntu 18.04.1 LTS yes Pierre Le Sidaner
Chrome 86.0.4240.75 Ubuntu 18.04.1 LTS Yes Pierre Le Sidaner
Vivaldi 3.3.2022.47 Ubuntu 18.04.1 LTS Yes Pierre Le Sidaner
Chrome 84.0.4147.125 MacOS 10.12.5 Yes Juan Carlos Segovia
Safari 10.1.1 MacOS 10.12.5 No Juan Carlos Segovia
Firefox 75.0 MacOS 10.12.5 Yes Juan Carlos Segovia
Added:
>
>
Chrome 57.0 MacOS 10.12.6 Yes Alcione Mora
Safari 11.0.2 MacOS 10.12.6 Yes Alcione Mora
Firefox 69.0 MacOS 10.12.6 Yes Alcione Mora
Chrome 86.0 MacOS 10.14.6 Yes Hector Canovas
Safari 12.1.2 MacOS 10.14.6 No Hector Canovas
Firefox 81.0.1 MacOS 10.14.6 No Hector Canovas
 

For more discussion on this topic, see the apps-samp mailing list.

Added:
>
>
-- MarkTaylor - 2020-10-13

Revision 82020-10-13 - MarkTaylor

 
META TOPICPARENT name="SampInfo"

Web SAMP and HTTPS

Changed:
<
<
The SAMP Web Profile allows web applications to talk to other SAMP clients, communicating with the Hub using an XMLHttpRequest to a well-known port (21012) on the local host. There are problems with doing this if the web page hosting the web application is served from HTTPS rather than HTTP, since access to the hub URL http://localhost:21012/ constitutes mixed active content, which is generally blocked by browsers. This issue has been known since 2014, but is becoming more pressing as more data providers use HTTPS for service delivery. See Presentation at Sydney Interop (2015) for more details.
>
>

Problem

Added:
>
>
The SAMP Web Profile allows web applications to talk to other SAMP clients, communicating with the Hub using an XMLHttpRequest to a well-known port (21012) on the local host. There are problems with doing this if the web page hosting the web application is served from HTTPS rather than HTTP, since access to the hub URL http://localhost:21012/ counts (at least in some interpretations) as mixed active content, which is generally blocked by browsers. This issue has been known since 2014, but is becoming more pressing as more data providers use HTTPS for service delivery. See Presentation at Sydney Interop (2015) for more details.
 
Changed:
<
<
A possible solution was proposed that defines a new Profile involving use of an external Relay service and abuse of mixed passive content to bootstrap communications, as described in Taylor presentation at Cape Town Interop (2016). This has been shown to work, e.g. it is currently deployed at ASI-SSDC based on a custom/prototype JSAMP hub, see Verrecchia presentation at Paris Interop (2019). This solution however is not elegant, efficient, robust or nice.
>
>

Bad solution

Added:
>
>
A possible solution was proposed that defines a new Profile involving use of an external Relay service and abuse of mixed passive content to bootstrap communications, as described in Taylor presentation at Cape Town Interop (2016). This has been shown to work, e.g. it is currently deployed at ASI-SSDC based on a custom/prototype JSAMP hub, see Verrecchia presentation at Paris Interop (2019). This solution however is not elegant, efficient, robust or nice. There is some more discussion of this as well as alternative bad solutions in https://arxiv.org/abs/1912.00917 (presented by Taylor at ADASS 2019; this paper is now mostly obsolete).
 
Added:
>
>

Good solution?

 Following discussion at Groningen Interop (2019), some more progress was made that could get HTTPS-based web applications to use the Web Profile as it stands:
Changed:
<
<
  • Sonia Zorba prepared a browser extension samp-browser-extension that lets browsers do this
  • Felix Stoehr pointed out that this just works in some browsers anyway. This was a surprise, that arises from changes to the various w3c security standards over the last few years (see analysis).
>
>
  • Felix Stoehr pointed out that in recent tests, this just works in some browsers anyway, i.e. the problem has just gone away. This was a surprise, that arises from changes to the various w3c security standards over the last few years (see analysis).
  • Sonia Zorba prepared a browser extension samp-browser-extension for browsers that still have problems with this
Deleted:
<
<
These two developments may provide a good-enough solution to this problem; some (hopefully increasingly many) browsers will work anyway, and for others users can be encouraged to install a browser extension that will make them work. However it's not currently clear which browsers are in which category. A table below summarises reports to date: if you can add to this information by trying it out on your browser/OS platform, please do:
 
Changed:
<
<

Please help by trying this out using your browser/OS combination(s):

>
>
These two developments may provide a good-enough solution to this problem; some (hopefully increasingly many) browsers will work anyway, and for others users can be encouraged to install a browser extension that will make them work.
 
Changed:
<
<
To work out the status of HTTPS+SAMP on your browser/OS, follow these very easy instructions:
>
>

Current status

Added:
>
>
We are assessing which browsers now support Web SAMP over HTTPS without making any special arrangements. Thanks to those who have tried out browser/OS combinations following the instructions below. The headline result seems to be:

  • Recent versions of Firefox and Chrome: SAMP over HTTPS works with no problems
  • Safari: SAMP over HTTPS doesn't work
  • Others: Vivaldi works

The OS doesn't seem to make a difference (Linux, MacOS, Windows 10 all tried).

This looks quite positive; services may decide on that basis that it's worth providing Web SAMP in HTTPS-based services on the basis that they will work for many/most users. Optionally, they could provide the browser extensions for others.

If you use a browser not in the above list, please consider following the instructions below to try it out and add your results into the table (or if you have trouble editing the wiki you can mail m.b.taylor@bristol.ac.uk and I'll add them).

You can try this out using your browser/OS combination(s):

To work out the status of HTTPS+SAMP on your browser/OS, follow these easy instructions:

 
  1. Start a SAMP Hub+client on your machine (e.g. run TOPCAT)
  2. Visit this HTTP page. Click the button.
    • A popup should appear asking you to allow SAMP registration from a web application (with an http://... Origin). Accept, and a table should be loaded in TOPCAT. (If this doesn't happen, your problems are not related to HTTPS)
  3. Visit this HTTPS page. Click the button.
    • Either as before, you are prompted to allow registration (for a web app with an https://... Origin) and a table is loaded in TOPCAT as before - this means SAMP+HTTPS does work on your browser
    • Or nothing happens - this means SAMP+HTTPS does not work on your browser.
  4. Record in the table below whether it did or didn't work ("yes" or "no" in the Works out of the box? column)
If you've done that but don't have easy write access to the wiki, you can mail your results to either m.b.taylor@bristol.ac.uk or apps-samp@ivoa.net.

(If you want to try some more interesting examples, including 2-way communications, others are available: HTTP / HTTPS. I'm expecting that if HTTPS works/fails for one SAMP example it will be the same for all, but if you find different, please report it).

-- MarkTaylor - 2019-10-05

HTTPS + SAMP Survey
Browser Version OS Works out of the box? Reporter
Chrome 77 Ubuntu yes Felix Stoehr
Chromium 78.0 Ubuntu yes Mark Taylor
Chromium 85.0 Ubuntu yes Mark Taylor
Firefox 70.0.1 OSX Mojave yes Felix Stoehr
Firefox 70.0 Ubuntu no Felix Stoehr
Firefox 59 RHEL6 no Mark Taylor
Firefox 70.0.1 Ubuntu no Mark Taylor
Firefox 81.0 Ubuntu yes Mark Taylor
Firefox Nightly 75.0 (64-bit) GUIX yes Hugo Buddelmeijer
Chrome 85.0 MacOS 10.13.6 yes Thomas Boch
Firefox 81.0 MacOS 10.13.6 yes Thomas Boch
Safari 13.1.2 MacOS 10.13.6 no Thomas Boch
Chrome 85.0 Fedora 31 yes Marco Molinaro
Firefox 80.0 Fedora 31 yes Marco Molinaro
Changed:
<
<
Chrome 85.0. MacOS 10.11.3 yes Susana Sánchez Expósito
Firefox 78.2 MacOS 10.11.3 yes Susana Sánchez Expósito
Safari 9.0.3 MacOS 10.11.3 No Susana Sánchez Expósito
Firefox 81.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Chrome 85.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Safari 13.1 MacOS 10.14.6 No Susana Sánchez Expósito
>
>
Chrome 85.0. MacOS 10.11.3 yes Susana Sánchez Expósito
Firefox 78.2 MacOS 10.11.3 yes Susana Sánchez Expósito
Safari 9.0.3 MacOS 10.11.3 No Susana Sánchez Expósito
Firefox 81.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Chrome 85.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Safari 13.1 MacOS 10.14.6 No Susana Sánchez Expósito
 
Firefox 81.0(64 bits) Ubuntu 20.04.1 LTS yes Regis Haigron
Firefox 80 Windows 10 yes Regis Haigron
Firefox 81.0(64 bits) Ubuntu 18.04.1 LTS yes Pierre Le Sidaner
Chrome 86.0.4240.75 Ubuntu 18.04.1 LTS Yes Pierre Le Sidaner
Vivaldi 3.3.2022.47 Ubuntu 18.04.1 LTS Yes Pierre Le Sidaner
Added:
>
>
Chrome 84.0.4147.125 MacOS 10.12.5 Yes Juan Carlos Segovia
Safari 10.1.1 MacOS 10.12.5 No Juan Carlos Segovia
Firefox 75.0 MacOS 10.12.5 Yes Juan Carlos Segovia
  For more discussion on this topic, see the apps-samp mailing list.

Revision 72020-10-09 - PierreLeSidaner

 
META TOPICPARENT name="SampInfo"

Web SAMP and HTTPS

The SAMP Web Profile allows web applications to talk to other SAMP clients, communicating with the Hub using an XMLHttpRequest to a well-known port (21012) on the local host. There are problems with doing this if the web page hosting the web application is served from HTTPS rather than HTTP, since access to the hub URL http://localhost:21012/ constitutes mixed active content, which is generally blocked by browsers. This issue has been known since 2014, but is becoming more pressing as more data providers use HTTPS for service delivery. See Presentation at Sydney Interop (2015) for more details.

A possible solution was proposed that defines a new Profile involving use of an external Relay service and abuse of mixed passive content to bootstrap communications, as described in Taylor presentation at Cape Town Interop (2016). This has been shown to work, e.g. it is currently deployed at ASI-SSDC based on a custom/prototype JSAMP hub, see Verrecchia presentation at Paris Interop (2019). This solution however is not elegant, efficient, robust or nice.

Following discussion at Groningen Interop (2019), some more progress was made that could get HTTPS-based web applications to use the Web Profile as it stands:

  • Sonia Zorba prepared a browser extension samp-browser-extension that lets browsers do this
  • Felix Stoehr pointed out that this just works in some browsers anyway. This was a surprise, that arises from changes to the various w3c security standards over the last few years (see analysis).
These two developments may provide a good-enough solution to this problem; some (hopefully increasingly many) browsers will work anyway, and for others users can be encouraged to install a browser extension that will make them work. However it's not currently clear which browsers are in which category. A table below summarises reports to date: if you can add to this information by trying it out on your browser/OS platform, please do:

Please help by trying this out using your browser/OS combination(s):

To work out the status of HTTPS+SAMP on your browser/OS, follow these very easy instructions:

  1. Start a SAMP Hub+client on your machine (e.g. run TOPCAT)
  2. Visit this HTTP page. Click the button.
    • A popup should appear asking you to allow SAMP registration from a web application (with an http://... Origin). Accept, and a table should be loaded in TOPCAT. (If this doesn't happen, your problems are not related to HTTPS)
  3. Visit this HTTPS page. Click the button.
    • Either as before, you are prompted to allow registration (for a web app with an https://... Origin) and a table is loaded in TOPCAT as before - this means SAMP+HTTPS does work on your browser
    • Or nothing happens - this means SAMP+HTTPS does not work on your browser.
  4. Record in the table below whether it did or didn't work ("yes" or "no" in the Works out of the box? column)
If you've done that but don't have easy write access to the wiki, you can mail your results to either m.b.taylor@bristol.ac.uk or apps-samp@ivoa.net.

(If you want to try some more interesting examples, including 2-way communications, others are available: HTTP / HTTPS. I'm expecting that if HTTPS works/fails for one SAMP example it will be the same for all, but if you find different, please report it).

-- MarkTaylor - 2019-10-05

Changed:
<
<
HTTPS + SAMP Survey
Browser Version OS Works out of the box? Reporter
Chrome 77 Ubuntu yes Felix Stoehr
Chromium 78.0 Ubuntu yes Mark Taylor
Chromium 85.0 Ubuntu yes Mark Taylor
Firefox 70.0.1 OSX Mojave yes Felix Stoehr
Firefox 70.0 Ubuntu no Felix Stoehr
Firefox 59 RHEL6 no Mark Taylor
Firefox 70.0.1 Ubuntu no Mark Taylor
Firefox 81.0 Ubuntu yes Mark Taylor
Firefox Nightly 75.0 (64-bit) GUIX yes Hugo Buddelmeijer
Chrome 85.0 MacOS 10.13.6 yes Thomas Boch
Firefox 81.0 MacOS 10.13.6 yes Thomas Boch
Safari 13.1.2 MacOS 10.13.6 no Thomas Boch
Chrome 85.0 Fedora 31 yes Marco Molinaro
Firefox 80.0 Fedora 31 yes Marco Molinaro
Chrome 85.0. MacOS 10.11.3 yes Susana Sánchez Expósito
Firefox 78.2 MacOS 10.11.3 yes Susana Sánchez Expósito
Safari 9.0.3 MacOS 10.11.3 No Susana Sánchez Expósito
Firefox 81.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Chrome 85.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Safari 13.1 MacOS 10.14.6 No Susana Sánchez Expósito
>
>
HTTPS + SAMP Survey
Browser Version OS Works out of the box? Reporter
Chrome 77 Ubuntu yes Felix Stoehr
Chromium 78.0 Ubuntu yes Mark Taylor
Chromium 85.0 Ubuntu yes Mark Taylor
Firefox 70.0.1 OSX Mojave yes Felix Stoehr
Firefox 70.0 Ubuntu no Felix Stoehr
Firefox 59 RHEL6 no Mark Taylor
Firefox 70.0.1 Ubuntu no Mark Taylor
Firefox 81.0 Ubuntu yes Mark Taylor
Firefox Nightly 75.0 (64-bit) GUIX yes Hugo Buddelmeijer
Chrome 85.0 MacOS 10.13.6 yes Thomas Boch
Firefox 81.0 MacOS 10.13.6 yes Thomas Boch
Safari 13.1.2 MacOS 10.13.6 no Thomas Boch
Chrome 85.0 Fedora 31 yes Marco Molinaro
Firefox 80.0 Fedora 31 yes Marco Molinaro
Chrome 85.0. MacOS 10.11.3 yes Susana Sánchez Expósito
Firefox 78.2 MacOS 10.11.3 yes Susana Sánchez Expósito
Safari 9.0.3 MacOS 10.11.3 No Susana Sánchez Expósito
Firefox 81.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Chrome 85.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Safari 13.1 MacOS 10.14.6 No Susana Sánchez Expósito
Added:
>
>
Firefox 81.0(64 bits) Ubuntu 20.04.1 LTS yes Regis Haigron
Firefox 80 Windows 10 yes Regis Haigron
Firefox 81.0(64 bits) Ubuntu 18.04.1 LTS yes Pierre Le Sidaner
Chrome 86.0.4240.75 Ubuntu 18.04.1 LTS Yes Pierre Le Sidaner
Vivaldi 3.3.2022.47 Ubuntu 18.04.1 LTS Yes Pierre Le Sidaner
  For more discussion on this topic, see the apps-samp mailing list.

Revision 62020-10-07 - SusanaSanchezExposito

 
META TOPICPARENT name="SampInfo"

Web SAMP and HTTPS

The SAMP Web Profile allows web applications to talk to other SAMP clients, communicating with the Hub using an XMLHttpRequest to a well-known port (21012) on the local host. There are problems with doing this if the web page hosting the web application is served from HTTPS rather than HTTP, since access to the hub URL http://localhost:21012/ constitutes mixed active content, which is generally blocked by browsers. This issue has been known since 2014, but is becoming more pressing as more data providers use HTTPS for service delivery. See Presentation at Sydney Interop (2015) for more details.

A possible solution was proposed that defines a new Profile involving use of an external Relay service and abuse of mixed passive content to bootstrap communications, as described in Taylor presentation at Cape Town Interop (2016). This has been shown to work, e.g. it is currently deployed at ASI-SSDC based on a custom/prototype JSAMP hub, see Verrecchia presentation at Paris Interop (2019). This solution however is not elegant, efficient, robust or nice.

Following discussion at Groningen Interop (2019), some more progress was made that could get HTTPS-based web applications to use the Web Profile as it stands:

  • Sonia Zorba prepared a browser extension samp-browser-extension that lets browsers do this
  • Felix Stoehr pointed out that this just works in some browsers anyway. This was a surprise, that arises from changes to the various w3c security standards over the last few years (see analysis).
These two developments may provide a good-enough solution to this problem; some (hopefully increasingly many) browsers will work anyway, and for others users can be encouraged to install a browser extension that will make them work. However it's not currently clear which browsers are in which category. A table below summarises reports to date: if you can add to this information by trying it out on your browser/OS platform, please do:

Please help by trying this out using your browser/OS combination(s):

To work out the status of HTTPS+SAMP on your browser/OS, follow these very easy instructions:

  1. Start a SAMP Hub+client on your machine (e.g. run TOPCAT)
  2. Visit this HTTP page. Click the button.
    • A popup should appear asking you to allow SAMP registration from a web application (with an http://... Origin). Accept, and a table should be loaded in TOPCAT. (If this doesn't happen, your problems are not related to HTTPS)
  3. Visit this HTTPS page. Click the button.
    • Either as before, you are prompted to allow registration (for a web app with an https://... Origin) and a table is loaded in TOPCAT as before - this means SAMP+HTTPS does work on your browser
    • Or nothing happens - this means SAMP+HTTPS does not work on your browser.
  4. Record in the table below whether it did or didn't work ("yes" or "no" in the Works out of the box? column)
If you've done that but don't have easy write access to the wiki, you can mail your results to either m.b.taylor@bristol.ac.uk or apps-samp@ivoa.net.

(If you want to try some more interesting examples, including 2-way communications, others are available: HTTP / HTTPS. I'm expecting that if HTTPS works/fails for one SAMP example it will be the same for all, but if you find different, please report it).

-- MarkTaylor - 2019-10-05

HTTPS + SAMP Survey
Browser Version OS Works out of the box? Reporter
Chrome 77 Ubuntu yes Felix Stoehr
Chromium 78.0 Ubuntu yes Mark Taylor
Chromium 85.0 Ubuntu yes Mark Taylor
Firefox 70.0.1 OSX Mojave yes Felix Stoehr
Firefox 70.0 Ubuntu no Felix Stoehr
Firefox 59 RHEL6 no Mark Taylor
Firefox 70.0.1 Ubuntu no Mark Taylor
Firefox 81.0 Ubuntu yes Mark Taylor
Firefox Nightly 75.0 (64-bit) GUIX yes Hugo Buddelmeijer
Chrome 85.0 MacOS 10.13.6 yes Thomas Boch
Firefox 81.0 MacOS 10.13.6 yes Thomas Boch
Safari 13.1.2 MacOS 10.13.6 no Thomas Boch
Chrome 85.0 Fedora 31 yes Marco Molinaro
Firefox 80.0 Fedora 31 yes Marco Molinaro
Changed:
<
<
>
>
Chrome 85.0. MacOS 10.11.3 yes Susana Sánchez Expósito
Added:
>
>
Firefox 78.2 MacOS 10.11.3 yes Susana Sánchez Expósito
Safari 9.0.3 MacOS 10.11.3 No Susana Sánchez Expósito
Firefox 81.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Chrome 85.0 MacOS 10.14.6 Yes Susana Sánchez Expósito
Safari 13.1 MacOS 10.14.6 No Susana Sánchez Expósito
  For more discussion on this topic, see the apps-samp mailing list.

Revision 52020-10-06 - MarcoMolinaro

 
META TOPICPARENT name="SampInfo"

Web SAMP and HTTPS

The SAMP Web Profile allows web applications to talk to other SAMP clients, communicating with the Hub using an XMLHttpRequest to a well-known port (21012) on the local host. There are problems with doing this if the web page hosting the web application is served from HTTPS rather than HTTP, since access to the hub URL http://localhost:21012/ constitutes mixed active content, which is generally blocked by browsers. This issue has been known since 2014, but is becoming more pressing as more data providers use HTTPS for service delivery. See Presentation at Sydney Interop (2015) for more details.

A possible solution was proposed that defines a new Profile involving use of an external Relay service and abuse of mixed passive content to bootstrap communications, as described in Taylor presentation at Cape Town Interop (2016). This has been shown to work, e.g. it is currently deployed at ASI-SSDC based on a custom/prototype JSAMP hub, see Verrecchia presentation at Paris Interop (2019). This solution however is not elegant, efficient, robust or nice.

Following discussion at Groningen Interop (2019), some more progress was made that could get HTTPS-based web applications to use the Web Profile as it stands:

  • Sonia Zorba prepared a browser extension samp-browser-extension that lets browsers do this
  • Felix Stoehr pointed out that this just works in some browsers anyway. This was a surprise, that arises from changes to the various w3c security standards over the last few years (see analysis).
These two developments may provide a good-enough solution to this problem; some (hopefully increasingly many) browsers will work anyway, and for others users can be encouraged to install a browser extension that will make them work. However it's not currently clear which browsers are in which category. A table below summarises reports to date: if you can add to this information by trying it out on your browser/OS platform, please do:

Please help by trying this out using your browser/OS combination(s):

To work out the status of HTTPS+SAMP on your browser/OS, follow these very easy instructions:

  1. Start a SAMP Hub+client on your machine (e.g. run TOPCAT)
  2. Visit this HTTP page. Click the button.
    • A popup should appear asking you to allow SAMP registration from a web application (with an http://... Origin). Accept, and a table should be loaded in TOPCAT. (If this doesn't happen, your problems are not related to HTTPS)
  3. Visit this HTTPS page. Click the button.
    • Either as before, you are prompted to allow registration (for a web app with an https://... Origin) and a table is loaded in TOPCAT as before - this means SAMP+HTTPS does work on your browser
    • Or nothing happens - this means SAMP+HTTPS does not work on your browser.
  4. Record in the table below whether it did or didn't work ("yes" or "no" in the Works out of the box? column)
If you've done that but don't have easy write access to the wiki, you can mail your results to either m.b.taylor@bristol.ac.uk or apps-samp@ivoa.net.

(If you want to try some more interesting examples, including 2-way communications, others are available: HTTP / HTTPS. I'm expecting that if HTTPS works/fails for one SAMP example it will be the same for all, but if you find different, please report it).

-- MarkTaylor - 2019-10-05

HTTPS + SAMP Survey
Browser Version OS Works out of the box? Reporter
Chrome 77 Ubuntu yes Felix Stoehr
Chromium 78.0 Ubuntu yes Mark Taylor
Chromium 85.0 Ubuntu yes Mark Taylor
Firefox 70.0.1 OSX Mojave yes Felix Stoehr
Firefox 70.0 Ubuntu no Felix Stoehr
Firefox 59 RHEL6 no Mark Taylor
Firefox 70.0.1 Ubuntu no Mark Taylor
Firefox 81.0 Ubuntu yes Mark Taylor
Firefox Nightly 75.0 (64-bit) GUIX yes Hugo Buddelmeijer
Chrome 85.0 MacOS 10.13.6 yes Thomas Boch
Firefox 81.0 MacOS 10.13.6 yes Thomas Boch
Safari 13.1.2 MacOS 10.13.6 no Thomas Boch
Changed:
<
<
>
>
Chrome 85.0 Fedora 31 yes Marco Molinaro
Added:
>
>
Firefox 80.0 Fedora 31 yes Marco Molinaro
 

For more discussion on this topic, see the apps-samp mailing list.

Revision 42020-10-06 - ThomasBoch

 
META TOPICPARENT name="SampInfo"

Web SAMP and HTTPS

The SAMP Web Profile allows web applications to talk to other SAMP clients, communicating with the Hub using an XMLHttpRequest to a well-known port (21012) on the local host. There are problems with doing this if the web page hosting the web application is served from HTTPS rather than HTTP, since access to the hub URL http://localhost:21012/ constitutes mixed active content, which is generally blocked by browsers. This issue has been known since 2014, but is becoming more pressing as more data providers use HTTPS for service delivery. See Presentation at Sydney Interop (2015) for more details.

A possible solution was proposed that defines a new Profile involving use of an external Relay service and abuse of mixed passive content to bootstrap communications, as described in Taylor presentation at Cape Town Interop (2016). This has been shown to work, e.g. it is currently deployed at ASI-SSDC based on a custom/prototype JSAMP hub, see Verrecchia presentation at Paris Interop (2019). This solution however is not elegant, efficient, robust or nice.

Following discussion at Groningen Interop (2019), some more progress was made that could get HTTPS-based web applications to use the Web Profile as it stands:

  • Sonia Zorba prepared a browser extension samp-browser-extension that lets browsers do this
  • Felix Stoehr pointed out that this just works in some browsers anyway. This was a surprise, that arises from changes to the various w3c security standards over the last few years (see analysis).
These two developments may provide a good-enough solution to this problem; some (hopefully increasingly many) browsers will work anyway, and for others users can be encouraged to install a browser extension that will make them work. However it's not currently clear which browsers are in which category. A table below summarises reports to date: if you can add to this information by trying it out on your browser/OS platform, please do:

Please help by trying this out using your browser/OS combination(s):

To work out the status of HTTPS+SAMP on your browser/OS, follow these very easy instructions:

  1. Start a SAMP Hub+client on your machine (e.g. run TOPCAT)
  2. Visit this HTTP page. Click the button.
    • A popup should appear asking you to allow SAMP registration from a web application (with an http://... Origin). Accept, and a table should be loaded in TOPCAT. (If this doesn't happen, your problems are not related to HTTPS)
  3. Visit this HTTPS page. Click the button.
    • Either as before, you are prompted to allow registration (for a web app with an https://... Origin) and a table is loaded in TOPCAT as before - this means SAMP+HTTPS does work on your browser
    • Or nothing happens - this means SAMP+HTTPS does not work on your browser.
  4. Record in the table below whether it did or didn't work ("yes" or "no" in the Works out of the box? column)
If you've done that but don't have easy write access to the wiki, you can mail your results to either m.b.taylor@bristol.ac.uk or apps-samp@ivoa.net.

(If you want to try some more interesting examples, including 2-way communications, others are available: HTTP / HTTPS. I'm expecting that if HTTPS works/fails for one SAMP example it will be the same for all, but if you find different, please report it).

-- MarkTaylor - 2019-10-05

HTTPS + SAMP Survey
Browser Version OS Works out of the box? Reporter
Chrome 77 Ubuntu yes Felix Stoehr
Chromium 78.0 Ubuntu yes Mark Taylor
Chromium 85.0 Ubuntu yes Mark Taylor
Firefox 70.0.1 OSX Mojave yes Felix Stoehr
Firefox 70.0 Ubuntu no Felix Stoehr
Firefox 59 RHEL6 no Mark Taylor
Firefox 70.0.1 Ubuntu no Mark Taylor
Firefox 81.0 Ubuntu yes Mark Taylor
Firefox Nightly 75.0 (64-bit) GUIX yes Hugo Buddelmeijer
Added:
>
>
Chrome 85.0 MacOS 10.13.6 yes Thomas Boch
Firefox 81.0 MacOS 10.13.6 yes Thomas Boch
Safari 13.1.2 MacOS 10.13.6 no Thomas Boch
  For more discussion on this topic, see the apps-samp mailing list.

Revision 32020-10-05 - HugoBuddelmeijer

 
META TOPICPARENT name="SampInfo"

Web SAMP and HTTPS

Changed:
<
<
The SAMP Web Profile allows web applications to talk to other SAMP clients, communicating with the Hub using an XMLHttpRequest to a well-known port (21012) on the local host.
>
>
The SAMP Web Profile allows web applications to talk to other SAMP clients, communicating with the Hub using an XMLHttpRequest to a well-known port (21012) on the local host. There are problems with doing this if the web page hosting the web application is served from HTTPS rather than HTTP, since access to the hub URL http://localhost:21012/ constitutes mixed active content, which is generally blocked by browsers. This issue has been known since 2014, but is becoming more pressing as more data providers use HTTPS for service delivery. See Presentation at Sydney Interop (2015) for more details.
Deleted:
<
<
There are problems with doing this if the web page hosting the web application is served from HTTPS rather than HTTP, since access to the hub URL http://localhost:21012/ constitutes mixed active content, which is generally blocked by browsers. This issue has been known since 2014, but is becoming more pressing as more data providers use HTTPS for service delivery. See Presentation at Sydney Interop (2015) for more details.
 
Changed:
<
<
A possible solution was proposed that defines a new Profile involving use of an external Relay service and abuse of mixed passive content to bootstrap communications, as described in Taylor presentation at Cape Town Interop (2016). This has been shown to work, e.g. it is currently deployed at ASI-SSDC based on a custom/prototype JSAMP hub, see Verrecchia presentation at Paris Interop (2019). This solution however is not elegant, efficient, robust or nice.
>
>
A possible solution was proposed that defines a new Profile involving use of an external Relay service and abuse of mixed passive content to bootstrap communications, as described in Taylor presentation at Cape Town Interop (2016). This has been shown to work, e.g. it is currently deployed at ASI-SSDC based on a custom/prototype JSAMP hub, see Verrecchia presentation at Paris Interop (2019). This solution however is not elegant, efficient, robust or nice.
  Following discussion at Groningen Interop (2019), some more progress was made that could get HTTPS-based web applications to use the Web Profile as it stands:
Changed:
<
<
  • Felix Stoehr pointed out that this just works in some browsers anyway. This was a surprise, that arises from changes to the various w3c security standards over the last few years (see analysis).
>
>
  • Felix Stoehr pointed out that this just works in some browsers anyway. This was a surprise, that arises from changes to the various w3c security standards over the last few years (see analysis).
Added:
>
>
These two developments may provide a good-enough solution to this problem; some (hopefully increasingly many) browsers will work anyway, and for others users can be encouraged to install a browser extension that will make them work. However it's not currently clear which browsers are in which category. A table below summarises reports to date: if you can add to this information by trying it out on your browser/OS platform, please do:
 
Deleted:
<
<
These two developments may provide a good-enough solution to this problem; some (hopefully increasingly many) browsers will work anyway, and for others users can be encouraged to install a browser extension that will make them work. However it's not currently clear which browsers are in which category. A table below summarises reports to date: if you can add to this information by trying it out on your browser/OS platform, please do:
 

Please help by trying this out using your browser/OS combination(s):

To work out the status of HTTPS+SAMP on your browser/OS, follow these very easy instructions:

  1. Start a SAMP Hub+client on your machine (e.g. run TOPCAT)
Changed:
<
<
  1. Visit this HTTP page. Click the button.
    • A popup should appear asking you to allow SAMP registration from a web application (with an http://... Origin). Accept, and a table should be loaded in TOPCAT. (If this doesn't happen, your problems are not related to HTTPS)
  2. Visit this HTTPS page. Click the button.
>
>
  1. Visit this HTTP page. Click the button.
    • A popup should appear asking you to allow SAMP registration from a web application (with an http://... Origin). Accept, and a table should be loaded in TOPCAT. (If this doesn't happen, your problems are not related to HTTPS)
  2. Visit this HTTPS page. Click the button.
 
    • Either as before, you are prompted to allow registration (for a web app with an https://... Origin) and a table is loaded in TOPCAT as before - this means SAMP+HTTPS does work on your browser
Changed:
<
<
    • Or nothing happens - this means SAMP+HTTPS does not work on your browser.
  1. Record in the table below whether it did or didn't work ("yes" or "no" in the Works out of the box? column)
>
>
    • Or nothing happens - this means SAMP+HTTPS does not work on your browser.
  1. Record in the table below whether it did or didn't work ("yes" or "no" in the Works out of the box? column)
Deleted:
<
<
 If you've done that but don't have easy write access to the wiki, you can mail your results to either m.b.taylor@bristol.ac.uk or apps-samp@ivoa.net.
Changed:
<
<
(If you want to try some more interesting examples, including 2-way communications, others are available: HTTP / HTTPS. I'm expecting that if HTTPS works/fails for one SAMP example it will be the same for all, but if you find different, please report it).
>
>
(If you want to try some more interesting examples, including 2-way communications, others are available: HTTP / HTTPS. I'm expecting that if HTTPS works/fails for one SAMP example it will be the same for all, but if you find different, please report it).
  -- MarkTaylor - 2019-10-05

HTTPS + SAMP Survey
Changed:
<
<
Browser Version OS Works out of the box? Reporter
Chrome 77 Ubuntu yes Felix Stoehr
Chromium 78.0 Ubuntu yes Mark Taylor
Chromium 85.0 Ubuntu yes Mark Taylor
Firefox 70.0.1 OSX Mojave yes Felix Stoehr
Firefox 70.0 Ubuntu no Felix Stoehr
Firefox 59 RHEL6 no Mark Taylor
Firefox 70.0.1 Ubuntu no Mark Taylor
Firefox 81.0 Ubuntu yes Mark Taylor
>
>
Browser Version OS Works out of the box? Reporter
Chrome 77 Ubuntu yes Felix Stoehr
Chromium 78.0 Ubuntu yes Mark Taylor
Chromium 85.0 Ubuntu yes Mark Taylor
Firefox 70.0.1 OSX Mojave yes Felix Stoehr
Firefox 70.0 Ubuntu no Felix Stoehr
Firefox 59 RHEL6 no Mark Taylor
Firefox 70.0.1 Ubuntu no Mark Taylor
Firefox 81.0 Ubuntu yes Mark Taylor
Added:
>
>
Firefox Nightly 75.0 (64-bit) GUIX yes Hugo Buddelmeijer
  For more discussion on this topic, see the apps-samp mailing list.

Revision 22020-10-05 - MarkTaylor

 
META TOPICPARENT name="SampInfo"

Web SAMP and HTTPS

The SAMP Web Profile allows web applications to talk to other SAMP clients, communicating with the Hub using an XMLHttpRequest to a well-known port (21012) on the local host. There are problems with doing this if the web page hosting the web application is served from HTTPS rather than HTTP, since access to the hub URL http://localhost:21012/ constitutes mixed active content, which is generally blocked by browsers. This issue has been known since 2014, but is becoming more pressing as more data providers use HTTPS for service delivery. See Presentation at Sydney Interop (2015) for more details.

A possible solution was proposed that defines a new Profile involving use of an external Relay service and abuse of mixed passive content to bootstrap communications, as described in Taylor presentation at Cape Town Interop (2016). This has been shown to work, e.g. it is currently deployed at ASI-SSDC based on a custom/prototype JSAMP hub, see Verrecchia presentation at Paris Interop (2019). This solution however is not elegant, efficient, robust or nice.

Following discussion at Groningen Interop (2019), some more progress was made that could get HTTPS-based web applications to use the Web Profile as it stands:

  • Sonia Zorba prepared a browser extension samp-browser-extension that lets browsers do this
  • Felix Stoehr pointed out that this just works in some browsers anyway. This was a surprise, that arises from changes to the various w3c security standards over the last few years (see analysis).
Changed:
<
<
These two developments may provide a good-enough solution to this problem; some (hopefully increasingly many) browsers will work anyway, and for others users can be encouraged to install a browser extension that will make them work. However it's not currently clear which browsers are in which category. A table below summarises reports to date: if you can add to this information by trying it out on your browser/OS platform, please do.
>
>
These two developments may provide a good-enough solution to this problem; some (hopefully increasingly many) browsers will work anyway, and for others users can be encouraged to install a browser extension that will make them work. However it's not currently clear which browsers are in which category. A table below summarises reports to date: if you can add to this information by trying it out on your browser/OS platform, please do:
 
Changed:
<
<
Note: I'm trying to get an HTTPS service set up on my machine so that I can give clear instructions how to make these tests. I will publicise this survey better when I've done that.
>
>

Please help by trying this out using your browser/OS combination(s):

 
Changed:
<
<
-- MarkTaylor - 2019-11-22
>
>
To work out the status of HTTPS+SAMP on your browser/OS, follow these very easy instructions:
Added:
>
>
  1. Start a SAMP Hub+client on your machine (e.g. run TOPCAT)
  2. Visit this HTTP page. Click the button.
    • A popup should appear asking you to allow SAMP registration from a web application (with an http://... Origin). Accept, and a table should be loaded in TOPCAT. (If this doesn't happen, your problems are not related to HTTPS)
  3. Visit this HTTPS page. Click the button.
    • Either as before, you are prompted to allow registration (for a web app with an https://... Origin) and a table is loaded in TOPCAT as before - this means SAMP+HTTPS does work on your browser
    • Or nothing happens - this means SAMP+HTTPS does not work on your browser.
  4. Record in the table below whether it did or didn't work ("yes" or "no" in the Works out of the box? column)
 
Changed:
<
<
Survey
Browser Version OS Works out of the box? Works with samp-browser-extension Reporter
Chrome 77 Ubuntu yes   Felix Stoehr
Chromium 78.0 Ubuntu yes   Mark Taylor
Firefox 70.0.1 OSX Mojave yes   Felix Stoehr
Firefox 70.0 Ubuntu no   Felix Stoehr
Firefox 59 RHEL6 no   Mark Taylor
Firefox 70.0.1 Ubuntu no   Mark Taylor
>
>
If you've done that but don't have easy write access to the wiki, you can mail your results to either m.b.taylor@bristol.ac.uk or apps-samp@ivoa.net.

(If you want to try some more interesting examples, including 2-way communications, others are available: HTTP / HTTPS. I'm expecting that if HTTPS works/fails for one SAMP example it will be the same for all, but if you find different, please report it).

-- MarkTaylor - 2019-10-05

HTTPS + SAMP Survey
Browser Version OS Works out of the box? Reporter
Added:
>
>
Chrome 77 Ubuntu yes Felix Stoehr
Chromium 78.0 Ubuntu yes Mark Taylor
Chromium 85.0 Ubuntu yes Mark Taylor
Firefox 70.0.1 OSX Mojave yes Felix Stoehr
Firefox 70.0 Ubuntu no Felix Stoehr
Firefox 59 RHEL6 no Mark Taylor
Firefox 70.0.1 Ubuntu no Mark Taylor
Firefox 81.0 Ubuntu yes Mark Taylor
  For more discussion on this topic, see the apps-samp mailing list.

Revision 12019-11-22 - MarkTaylor

 
META TOPICPARENT name="SampInfo"

Web SAMP and HTTPS

The SAMP Web Profile allows web applications to talk to other SAMP clients, communicating with the Hub using an XMLHttpRequest to a well-known port (21012) on the local host. There are problems with doing this if the web page hosting the web application is served from HTTPS rather than HTTP, since access to the hub URL http://localhost:21012/ constitutes mixed active content, which is generally blocked by browsers. This issue has been known since 2014, but is becoming more pressing as more data providers use HTTPS for service delivery. See Presentation at Sydney Interop (2015) for more details.

A possible solution was proposed that defines a new Profile involving use of an external Relay service and abuse of mixed passive content to bootstrap communications, as described in Taylor presentation at Cape Town Interop (2016). This has been shown to work, e.g. it is currently deployed at ASI-SSDC based on a custom/prototype JSAMP hub, see Verrecchia presentation at Paris Interop (2019). This solution however is not elegant, efficient, robust or nice.

Following discussion at Groningen Interop (2019), some more progress was made that could get HTTPS-based web applications to use the Web Profile as it stands:

  • Sonia Zorba prepared a browser extension samp-browser-extension that lets browsers do this
  • Felix Stoehr pointed out that this just works in some browsers anyway. This was a surprise, that arises from changes to the various w3c security standards over the last few years (see analysis).

These two developments may provide a good-enough solution to this problem; some (hopefully increasingly many) browsers will work anyway, and for others users can be encouraged to install a browser extension that will make them work. However it's not currently clear which browsers are in which category. A table below summarises reports to date: if you can add to this information by trying it out on your browser/OS platform, please do.

Note: I'm trying to get an HTTPS service set up on my machine so that I can give clear instructions how to make these tests. I will publicise this survey better when I've done that.

-- MarkTaylor - 2019-11-22

Survey
Browser Version OS Works out of the box? Works with samp-browser-extension Reporter
Chrome 77 Ubuntu yes   Felix Stoehr
Chromium 78.0 Ubuntu yes   Mark Taylor
Firefox 70.0.1 OSX Mojave yes   Felix Stoehr
Firefox 70.0 Ubuntu no   Felix Stoehr
Firefox 59 RHEL6 no   Mark Taylor
Firefox 70.0.1 Ubuntu no   Mark Taylor

For more discussion on this topic, see the apps-samp mailing list.

 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback