SAMP browser plugin? Re: SAMP and HTTPS workaround?

[Thomas Boch]

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/