SAMP browser plugin? Re: SAMP and HTTPS workaround?

Mark Taylor M.B.Taylor at bristol.ac.uk
Mon Oct 14 18:33:59 CEST 2019 

Thomas et al.,

the browser plugin seems to be a popular suggestion, so maybe
I've just been asking the wrong question or making the wrong
assumptions about what a solution would look like.  If a plugin-based
approach can be made to work (which I'd define as, maybe,
allowing >=80% of users to interact with SAMP from HTTPS pages?)
I'd be very happy to see it in use and chuck away all the
relay/nudge business I was talking about in Groningen.
I have been a bit scared of the amount of effort required to
develop and maintain multi-platform browser-specific code to 
support this functionality, but maybe it's not as bad as I feared.

I am pretty ignorant about plugin capabilities.  If they operate
entirely outside of the browser sandbox then they can interact
with the Hub using the existing Standard Profile, which I presume
is what Sebastien's 2010ASPC..434..159D implementation did 
(or maybe Web Profile would be better? because of the different 
security assumptions that the Web Profile makes).  
Either way, hub implementations wouldn't need any change.
But there would need to be some browser-independent interface:
a "Plugin Profile" (which I think means a JavaScript API?)
defining how web applications can communicate with these plugins 
in an browser-independent way.

One possibility for specifying that would be to use the same API
that the sampjs library currently exposes (though maybe under a
different namespace to avoid confusion, e.g. samp_plugin.Connector
rather than samp.Connector).  That would make it easy for web
applications to migrate from current practice
(HTTP-only Web SAMP using sampjs library) to use of a future
HTTPS-capable Plugin Profile.  However, if there's some good
reason to prefer different methods or names than the ones I chose
for sampjs, that's fine by me.  The sampjs API is not very explicitly
documented right now, you have to look at the code and examples
(http://astrojs.github.io/sampjs/), but I could write it up
better if required.

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...

Mark


On Mon, 14 Oct 2019, Thomas Boch wrote:

> 
> 
> Le 14/10/2019 à 14:37, Mark Taylor a écrit :
> > Hi Hugo,
> > 
> > thanks for the input.  I didn't go through all the possibilities
> > in my talk, but yes a browser plugin of some sort might be able to
> > solve the problem (and historically I think that some SAMP browser
> > plugins existed before the Web Profile was introduced as an alternative
> > solution to that problem, but I don't think they got much beyond
> > the experimental stage).  A couple of other people mentioned this
> > at the meeting too.
> 
> I think Sebastien Derriere demonstrated the concept at an earlier ADASS
> meeting in Japan, in a talk entitled '’SAMP’ling Your Browser for the Semantic
> Web' (http://adsabs.harvard.edu/abs/2010ASPC..434..159D ).
> 
> I think I quite like the idea of developing a plugin to overcome Web SAMP
> issues raised by HTTPS pages.
> 
> Thomas
> > I have two main reservations about this option.  First, will users
> > actually install a browser extension?  And second, the amount of
> > work involved in writing and maintaining the extension code for
> > multiple versions of multiple browsers.  I don't have much grasp
> > of how big a drawback either of those things is though.
> > If anybody wants to experiment with implementation and report back,
> > that would be great.
> > 
> > Mark
> > 
> > 
> > On Mon, 14 Oct 2019, Hugo Buddelmeijer wrote:
> > 
> > > Hi all,
> > > 
> > > Would a SAMP browser plugin be a solution to the https problem?
> > > 
> > > That is, users install a samp-plugin, the websites connect to the plugin,
> > > and the plugin connects to the samp-hub. This seems possible:
> > > https://developer.chrome.com/extensions/nativeMessaging
> > > https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Native_messaging
> > > 
> > > Maybe it would be feasible to have this browser plugin to be effectively
> > > another SAMP hub (that talks to the desktop hub); that is, adding a new
> > > browser-plugin profile to standard. That way anyone could make a compliant
> > > plugin so we would not be at the merci of this hypothetical plugin author.
> > > 
> > > There are only a few browsers (chrome, firefox, safari), so it might be
> > > less work than the relay-solution.
> > > 
> > > My experience with browser plugins is very limited (a single experiment
> > > years ago), so maybe it is not as simple. And maybe installing
> > > yet-another-browser-plugin for just a single use case is too much overhead
> > > for some people.
> > > 
> > > Any thoughts?
> > > 
> > > Hugo
> > > 
> > > 
> > > 
> > > On Thu, 22 Aug 2019 at 15:05, Mark Taylor <M.B.Taylor at bristol.ac.uk>
> > > wrote:
> > > 
> > > > Dear SAMP users,
> > > > 
> > > > the problem of Web SAMP and HTTPS has been under discussion
> > > > for a while now - basically the Web Profile works fine with HTTP
> > > > but won't work from pages served using HTTPS.  A possible HTTPS-capable
> > > > profile has been prototyped, but it's pretty nasty.  There is much
> > > > more information on the topic here:
> > > > 
> > > >     http://andromeda.star.bristol.ac.uk/websamp/
> > > > 
> > > > As an alternative to the HTTPS profile, I'm thinking about more
> > > > lightweight workarounds.  One is just to provide a simple helper
> > > > application that takes a suitable filename on the command line
> > > > (VOTable table or FITS image) and sends it to a running SAMP
> > > > client.  Such an application could be associated in the
> > > > browser with suitable MIME types (application/x-votable+xml,
> > > > image/fits), or you could just choose it when the browser
> > > > asks you what application you want to open a downloaded file with.
> > > > 
> > > > This is much less flexible than allowing the web page (web application)
> > > > to interact with the SAMP hub itself, which is what you can do
> > > > with SAMP+Web Profile.  However, in practice, nearly(?) all Web SAMP
> > > > pages that I'm aware of just use Web SAMP to allow the user to
> > > > send a samp.load.votable or image.load.fits message, and that's
> > > > done nearly as well by the helper application.  It works with
> > > > rather than against normal browser operations, which makes it
> > > > much less painful to implement than the HTTPS profile;
> > > > it works equally with HTTPS or HTTP, and no additional
> > > > infrastructure is required.  The main downside is that the user has
> > > > to configure it somehow (install script, tell browser to use it
> > > > to handle relevant files).
> > > > 
> > > > I have written such a helper application, and I'd be interested
> > > > to know if anyone wants to try it out: especially data providers
> > > > who are using HTTPS and want to allow users to load tables/images
> > > > using SAMP.  Would this be an acceptable solution?
> > > > 
> > > > You can find the application here:
> > > > 
> > > >     http://andromeda.star.bris.ac.uk/websamp/sampload.jar
> > > > 
> > > > If you run, e.g. "java -jar sampload.jar /tmp/tmpfile.vot"
> > > > then it will pop up a window asking which VOTable-capable
> > > > SAMP client you want to send tmpfile.vot to.
> > > > (It works out what kind of file it is by looking at the content).
> > > > 
> > > > Unless your OS/browser can execute jar files directly, to use it with
> > > > a browser you'll need to accompany it with a small shell script or
> > > > equivalent like
> > > > 
> > > >     #!/bin/sh
> > > >     java -jar /path/to/sampload.jar "$@"
> > > > 
> > > > Any feedback, comments, ideas welcome.
> > > > 
> > > > Mark
> > > > 
> > > > --
> > > > 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