SAMP browser plugin? Re: SAMP and HTTPS workaround?

Mark Taylor M.B.Taylor at bristol.ac.uk
Wed Oct 30 14:52:16 CET 2019 

Sonia,

this looks very promising.  I know almost nothing about browser
extensions, and I've forgotten most of the javascript I learned
in order to write samp.js, so I've got no technical comments on
the details of the approach or implementation.  But as a general
approach to solving the Web SAMP/HTTPS problem I like it a lot,
since it requires no change to hub software or the SAMP standard.

Whether it solves the problem is dependent on whether this works
in practice for most users: will they actually install a browser
extension, and will it operate correctly in the browsers they are using.
Apart from any technical points that other people might make
about this extension code, what's needed in due course is tests on some
different browsers, test deployments by service providers who want
Web SAMP to work over HTTPS, and ideally feedback on actual usage.

For testing, it would also be nice to check whether two-way
communication works using this extension as well as simple
send-only SAMP messages.  You could use the examples
pingee.html, monitor.html or tdisplay.html in
https://github.com/astrojs/sampjs/tree/gh-pages/examples
as a basis for such tests.

Mark

On Wed, 30 Oct 2019, Zorba, Sonia wrote:

> Dear all,
> I prototyped an extension able to perform SAMP requests from its
> background script.
> It requires also a small addition to the samp.js library, but the
> change doesn't break the existing applications, so this solution could
> coexist with the other ones.
> Basically, inside samp.js, facades for XMLHttpRequests are created. I
> added a new facade type that forwards the requests to the extension.
> However, in order to work with the extension, it is necessary to adapt
> a bit the applications, because the samp application code should be
> executed after the extension has been loaded (there is an event to
> wait).
> 
> This is the extension code: https://github.com/zonia3000/samp-browser-extension
> And this the modified samp.js code: https://github.com/zonia3000/sampjs
> 
> Let me know if you think that this solution could make sense for you
> or if it is too hacky or you see other problems.
> 
> Cheers,
> Sonia
> 
> 
> 
> Il giorno gio 17 ott 2019 alle ore 23:47 Mark Taylor
> <M.B.Taylor at bristol.ac.uk> ha scritto:
> >
> > OK, using the Web Profile is probably a good thing - it means
> > that the security measures, such as they are, implemented by
> > the Web Profile (SAMP 1.3 sec 5.4) will be in force for this
> > access method, rather than the less restricted access provided
> > by the Standard Profile.
> >
> >  On Thu, 17 Oct 2019, Zorba, Sonia wrote:
> >
> > > Hi Mark, thank you.
> > > From the tests I've made it seems easier to continue using the Web
> > > Profile also in the extension.
> > > The hardest part for implementing the Standard Profile is handling the
> > > inward communications (Chrome provides and API called chrome.sockets
> > > but it acts at TCP level).
> > >
> > > Cheers,
> > > Sonia
> > >
> > > Il giorno gio 17 ott 2019 alle ore 15:28 Mark Taylor
> > > <M.B.Taylor at bristol.ac.uk> ha scritto:
> > > >
> > > > Sonia,
> > > >
> > > > I haven't attempted to follow the details, but this sounds really hopeful.
> > > > Thanks for the trials so far, and I look forward to hearing more.
> > > > One question for now: do you expect the extension communication with
> > > > the hub to be using the Web Profile or Standard Profile?
> > > >
> > > > Regarding the mailing lists: apps-samp is archived at
> > > >
> > > >    http://mail.ivoa.net/pipermail/apps-samp/
> > > >
> > > > though that link doesn't appear on the main mailing lists page.
> > > > I think it makes sense to continue the discussion on this list:
> > > > I will post a message on the apps list to make it clear that's
> > > > happening, in case anybody is subscribed to that list but not
> > > > this one and wants to follow.
> > > >
> > > > Mark
> > > >
> > > >
> > > > On Thu, 17 Oct 2019, Zorba, Sonia wrote:
> > > >
> > > > > Dear all,
> > > > > I'm not completely sure you received my previous mail (I wasn't in the
> > > > > apps-samp list yet). Anyway, I would just like to share some results
> > > > > I've found.
> > > > >
> > > > > I did a couple of experiments and I was able to perform an http call
> > > > > from an https page using a Browser Extension (same code for Firefox
> > > > > and Chrome).
> > > > > Indeed the docs specify that extensions can obtain extra permissions:
> > > > > «XMLHttpRequest and fetch access to those origins without cross-origin
> > > > > restrictions» (https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions)
> > > > >
> > > > > To achieve this it is necessary to add the specific permission in the
> > > > > manifest.json:
> > > > > "permissions": [
> > > > >   "*://localhost/*"
> > > > > ]
> > > > >
> > > > > Browser Extensions have 2 kinds of scripts: content script and
> > > > > background script.
> > > > > Firefox allows the cross-origin call from both the scripts, Chrome
> > > > > only from the background script (solvable passing from the content
> > > > > script to the background script: https://stackoverflow.com/a/55215898)
> > > > > Trying to do the call from the content script Chrome blocks the
> > > > > request due to CORB (another recent thing to consider together with
> > > > > CORS, https://www.chromium.org/Home/chromium-security/corb-for-developers)
> > > > > I didn't receive any "mixed content" error.
> > > > >
> > > > > A custom event can be used to call the extension content script from a
> > > > > page script:
> > > > > document.dispatchEvent(new CustomEvent('eventToSampExtension', {
> > > > > detail: data }));
> > > > >
> > > > > So, the flow could be something like: page script --(event)->
> > > > > extension content script --(extension API)-> extension background
> > > > > script --(http)-> SAMP hub
> > > > >
> > > > > I hope to be able to share some working code in the next weeks.
> > > > >
> > > > > Cheers,
> > > > > Sonia
> > > > >
> > > > >
> > > > > Il giorno gio 17 ott 2019 alle ore 11:07 Thomas Boch
> > > > > <thomas.boch at astro.unistra.fr> ha scritto:
> > > > > >
> > > > > > Mark,
> > > > > >
> > > > > > Le 14/10/2019 à 18:33, Mark Taylor a écrit :
> > > > > > > I think the only way to take this forward is to experiment and
> > > > > > > try it out, so we'd need some volunteers to try to write plugins
> > > > > > > for different browsers.  Writing browser plugins is far from
> > > > > > > my area of expertise, so I'm not volunteering.  Sonia Zorba
> > > > > > > suggested in Groningen that she might be willing to have a go,
> > > > > > > and Thomas's "quite like the idea of developing a plugin" sounds
> > > > > > > like it could be an offer too...
> > > > > >
> > > > > > Yes indeed, that's something I'm willing to experiment with.
> > > > > >
> > > > > > Thomas
> > > > >
> > > >
> > > > --
> > > > Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
> > > > m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/
> > >
> >
> > --
> > Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
> > m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/
> 

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/

More information about the apps-samp mailing list