Storing connection info when using SAMP Web profile

Thomas Boch thomas.boch at astro.unistra.fr
Thu Jan 26 04:24:54 PST 2012


Hi Luigi,

Luigi Paioro wrote:
> 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).
So far, we did nothing that sophisticated, so yes, the private client id 
is stored in the cookie.
I wonder if the storage capability (IndexedDB) offered by HTML5 would 
help and be more secure than using 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 ?
>
> 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.
That is true. I was thinking of reusing the same connection on all 
Simbad pages for instance, so the number of zombie clients should be 
limited, and I am ready to pay this price for better usability :)

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


-- 
Thomas Boch
Ingénieur de Recherche

  CDS/Observatoire Astronomique   Phone  : 33 (0)3 68 85 24 42
  11, rue de l'Universite         Fax    : 33 (0)3 68 85 24 17
  F-67000 Strasbourg              Email  : thomas.boch at astro.unistra.fr
  France                          http://cdsweb.u-strasbg.fr/~boch 



More information about the apps-samp mailing list