Storing connection info when using SAMP Web profile

[Mark Taylor]

Hi T&G,

On Thu, 26 Jan 2012, Thomas Boch wrote:

> Dear SAMP enthusiasts,
> 
> We are starting to test and study how we will implement (Web) SAMP on the
> various CDS web pages.
> While experimenting, we found out that having to re-register on each new web
> page we open was not very user-friendly.

Yes, I can see that's true.

> Thus, we developed some prototype code which stores the connection information
> in a dedicated cookie. When the user browses in the same session on a new web
> page, he doesn't have to register again, but instead we re-use the existing
> connection.
> A small demo should make this clearer :
> - launch latest version of TOPCAT or any other tool supporting the Web SAMP
> profile
> - load in your browser (with cookies enabled)
> http://cdsweb.u-strasbg.fr/~boch/websamp/samp1.html
> - click on Connect to SAMP
> - click on Broadcast result table
> - point now to http://cdsweb.u-strasbg.fr/~boch/websamp/samp2.html
> You'll notice that the page is already connected to the hub, reusing the
> existing connection, whose settings are stored in a cookie

this doesn't seem to work for me.  Clicking the "Connect to SAMP" button
has no apparent effect, and I don't see any connection attempts to
the hub.  I'm using firefox 3.6 with JSAMP hub 1.3-2, and the
client at http://www.star.bristol.ac.uk/~mbt/websamp/monitor.html
does work.

I don't know if this is related (presumably you've had it working
yourselves), but I don't think I would expect your scheme to work
over CORS (not sure about the Flash x-domain policy).
CORS has special measures for permitting use of user credentials
(including cookies), and it looks to me like the browser must refuse 
to set cookies unless the CORS server (the hub httpd) includes the
"Access-Control-Allow-Credentials: true" header in its responses,
which the JSAMP hub does not.  However, I really haven't played with
cookies, so it's possible I'm misinterpreting that.

> We would like to gather your comments, and in particular your thoughts on:
> - potential security threats due to storing the connection in a cookie
> - section 5.3 of the SAMP document states that [a client must] "unregister
> when no further SAMP activity is required, either because the user requests
> disconnection or on page unload or a similar event." In our prototype, we do
> not unregister when we leave a page, so that we can reuse the same connection
> to the hub. Is that a problem ?

As Luigi says the possibility of zombie clients is a bit of a pain,
but I suspect that several web clients will end up failing to unregister,
because it can be difficult to know when the page is unloaded
(at least, I couldn't seem to do it reliably in the samp.js code).
So, if it's the price of significant improvements in usability
it's probably OK.

For security reasons (though I don't have a clear idea of how serious
the issues are) and because of the additional complication of
handling cookies over CORS, it would seem like a good idea to avoid
use of cookies if another reasonable solution can be found.
Is there any reason you can't just store the client IDs server side?
The data volume wouldn't be very great, and expiring them after a
day or so would be a reasonable thing to do.  Hmm, security issues
from different users on the same machine maybe.

> On the technical side, we used the samp.js class provided by Mark Taylor, and
> made a small change to make visible the Connection field.
> The storage of the connection info could also be integrated directly in the
> samp.js code.
> Mark : if you find this idea interesting, what would you think about directly
> integrating this capability into samp.js ?

I'll make a general comment about that, which is that I'm very emotionally 
unattached to the samp.js code.  It was really intended as a proof
of concept rather than a library for wide use, and if anybody 
who's a better javascript programmer than me (which doesn't narrow
it down much) would like to take it on and make whatever adaptations
they'd like to, I'd be quite happy.  It would make sense for it to 
be developed/maintained by somebody who is actually deploying
web SAMP clients, and that's not something I'm doing in the forseeable
future.

Another general comment - nice to see people trying to use web samp
in a non-trivial way.  I'm sure it will continue to throw up things
like this usability issue which we haven't thought of.

Mark

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