Storing connection info when using SAMP Web profile

Luigi Paioro luigi at lambrate.inaf.it
Thu Jan 26 03:14:39 PST 2012


Dear Thomas,

   I haven't tested your code yet, but this is what I think:

 > - potential security threats due to storing the connection in a cookie

cookies always raise security issues, unless you simply don't put a 
session id in the cookie, and store the SAMP Hub connecting information 
in a server side persistent object instance joined with the session id. 
However I didn't read your code, so maybe you found a way to hide the 
connection parameters (basically the private client ID).

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

If you never unregister the client, zombie clients might remain 
registered with the hub, unless we don't put an activity timeout hub 
side, that automatically unregister the Web Profile clients once the 
timeout expires.

My two cents.

Cheers,

   Luigi



On 01/26/12 11:56, 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.
> 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
>
> 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 ?
>
>
> 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 ?
>
> Cheers,
>
> Thomas&  Grégory


-- 

Luigi Paioro

INAF - IASF Milano
Via Bassini 15, I-20133 Milano, Italy

Phone  (+39) 02 23 699 470
Fax    (+39) 02 26 660 17
Site   http://cosmos.iasf-milano.inaf.it/luigi/


More information about the apps-samp mailing list