From sylvain.lafrasse at obs.ujf-grenoble.fr Wed Jan 18 00:55:21 2012 From: sylvain.lafrasse at obs.ujf-grenoble.fr (Sylvain LAFRASSE) Date: Wed, 18 Jan 2012 09:55:21 +0100 Subject: Announcing JMMC SAMP Application Launcher Message-ID: Dear all, We are please to announce our first beta release of AppLauncher : http://www.jmmc.fr/AppLauncher/ AppLauncher is a Java software, able to automatically launch JNLP applications when solicited through SAMP. This way, known SAMP applications appear already available in your 'Interop' menu, even though none is yet running ! The end user can then discover and use applications she even does not know yet, based on their sole interoperable capacities. This first release is mainly dedicated to you application developers. By trying AppLauncher and playing with your own SAMP application, AppLauncher will propose to report us your application meta-data, for later integration in our SAMP application registry. The goal is to provide scientists with a one-stop Dock dedicated to astronomical software, offering as much choice as possible. AppLauncher already offers JMMC software and 2 essentials that are Aladin and TOPCAT. More details and contact informations are available on AppLauncher web page. As usual, feedback and comments are welcome ! On the behalf of the JMMC technical team, Best regards, ------------------------------------------------------------------------------------------------------------------------ Sylvain LAFRASSE Tel : +33 (0)4 76 63 55 30 Fax : +33 (0)4 76 44 88 21 IPAG 414, rue de la Piscine Domaine Universitaire de Saint-Martin-d'H?res BP 53 France 38041 Grenoble cedex 9 ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain.lafrasse at obs.ujf-grenoble.fr Wed Jan 18 06:20:50 2012 From: sylvain.lafrasse at obs.ujf-grenoble.fr (Sylvain LAFRASSE) Date: Wed, 18 Jan 2012 15:20:50 +0100 Subject: [jmmc-tech-group] Internal SAMP Hub ? In-Reply-To: References: <4919208E-3FB5-4D30-A30F-DAC260ABE2B6@obs.ujf-grenoble.fr> <91E51C4F-D6C7-4BFB-8DDA-FF5DC0DB49A0@obs.ujf-grenoble.fr> <25A2522C-0A67-4155-8C2E-D9BD72AF5BE9@obs.ujf-grenoble.fr> <4EE75328.60701@obs.ujf-grenoble.fr> <846D6F0F-DDDD-4094-8860-B4A8200E1CF1@obs.ujf-grenoble.fr> <848E1C20-38CB-4804-80F7-D9789CC9D3C0@obs.ujf-grenoble.fr> Message-ID: <8F62C266-ADB6-4985-B388-EC25CA573CE3@obs.ujf-grenoble.fr> Hello, Following our previous discussions around internal hubs tracking and shutdown problems, our patch do: - add a new HubTracker singleton to track all hubs, then being able to check if any hub is still currently running inside the executing JVM; - properly handle shutdown hooks (only one central hook for the whole jSAMP stack, that ensure ordered clients cleanup first, then hubs shutdown at last, and should avoid zombie client/hub issues - maybe WeakReferences would be one step beyond). Best regards, ------------------------------------------------------------------------------------------------------------------------ Sylvain LAFRASSE Tel : +33 (0)4 76 63 55 30 Fax : +33 (0)4 76 44 88 21 IPAG 414, rue de la Piscine Domaine Universitaire de Saint-Martin-d'H?res BP 53 France 38041 Grenoble cedex 9 ------------------------------------------------------------------------------------------------------------------------ On 16 janv. 2012, at 16:44, Mark Taylor wrote: > Sylvain, > > I took a quick look, but I'm not thinking much about JSAMP at the moment. > Can you remind me what problems these fixes are solving for you, and how > important it is to you to get them included? > > Mark > > On Mon, 16 Jan 2012, Sylvain LAFRASSE wrote: > >> Helo Mark, >> >> First the JMMC team would like to wish you a happy new year, as we are not that late in january :) >> Did you have the time to take a look at our 2 late-2011 SAMP patches by the way ? >> >> Amicalement, >> Sylvain >> >> >> On 20 d?c. 2011, at 11:52, Sylvain LAFRASSE wrote: >> >>> And in the same way, a new snowy patch on an idea of Laurent (also containing the former one), to only have one shutdown hook doing the cleanup in a predictable order (i.e shutting down clients first, hubs last). >>> >>> And Merry Christmass ! >>> Sylvain >>> >>> >>> >>> >>> On 16 d?c. 2011, at 14:57, Sylvain LAFRASSE wrote: >>> >>>> Dear Mark, >>>> >>>> Here is a patch we developed to come over multiple hubs situation, while still fulfilling our primary need. >>>> I hope it will make its way in your next release... >>>> In the mean time, we wish you a pleasing year end ! >>>> >>>> >>>> >>>> Amicalement, >>>> Sylvain LAFRASSE >>>> >>>> >>>> On 13 d?c. 2011, at 15:01, Mark Taylor wrote: >>>> >>>>> Hi Laurent, >>>>> >>>>> although I think that in the large majority of practical cases there will >>>>> not be a requirement for multiple hubs to run simultaneously, singleton >>>>> doesn't sound quite right to me. For one thing, the singleton pattern >>>>> suggests that only one instance of a class ever exists >>>>> in the runtime environment, whereas here you might have different >>>>> instances at different times. Also it is conceivable that you might >>>>> want to run multiple hubs simultaneously with different profiles. >>>>> I agree that it is rather a specialised requirement, but I think that >>>>> enforcing it at the API level would be unnecessary and suggest >>>>> an architectural constraint which does not exist. >>>>> >>>>> Mark >>>>> >>>>> On Tue, 13 Dec 2011, Laurent Bourges wrote: >>>>> >>>>>> Dear mark, >>>>>> >>>>>> I started to do it yesterday and I gave up as Sylvain was arguing that it >>>>>> should be done in JSamp directly. >>>>>> >>>>>> I will now code a new patch on your latest code 1.3.2 to provide: >>>>>> - Hub singleton pattern: runHub methods return a new Hub instance without >>>>>> keeping any reference on created Hub instances: I think "we" should use the >>>>>> singleton pattern here >>>>>> - HubAction already uses Hub.runHub() methods so using the singleton pattern >>>>>> should solve our issue >>>>>> >>>>>> What's your opinion ? Is there any reason not to apply the singleton pattern >>>>>> i.e. is it possible to have two Hub instances running at the same time >>>>>> (profiles ...) ? >>>>>> >>>>>> Laurent >>>>>> >>>>>> Le 13/12/2011 11:17, Mark Taylor a ?crit : >>>>>>> I see what you mean, but I don't want to make another release >>>>>>> straight away. To solve this problem I suggest you copy the >>>>>>> source code from the GuiHubConnector class to make a suitable >>>>>>> action, and keep track of any hubs it creates in your code. >>>>>>> >>>>>>> Mark >>>>>>> >>>>>>> On Mon, 12 Dec 2011, Sylvain LAFRASSE wrote: >>>>>>> >>>>>>>> ?.but ! Something is still missing :-/ >>>>>>>> >>>>>>>> If I use the action provided by GuiHubConnector::createHubAction(false, ?) >>>>>>>> to start a new hub from within my JNLP application, I am still not able to >>>>>>>> retrieve whether the current hub is running internally or not? >>>>>>>> A static boolean (with its public getter) in the Hub class is definitly >>>>>>>> missing. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Sylvain >>>>>>>> >>>>>>>> >>>>>>>> On 12 d?c. 2011, at 14:28, Sylvain LAFRASSE wrote: >>>>>>>> >>>>>>>>> On 12 d?c. 2011, at 13:59, Mark Taylor wrote: >>>>>>>>> >>>>>>>>>> On Tue, 22 Nov 2011, Sylvain LAFRASSE wrote: >>>>>>>>>> >>>>>>>>>>> On 22 nov. 2011, at 13:43, Mark Taylor wrote: >>>>>>>>>>> >>>>>>>>>>>> On Tue, 22 Nov 2011, Sylvain LAFRASSE wrote: >>>>>>>>>>>> >>>>>>>>>>>>>>>>> Do you have any idea when we can reasonably expect a >>>>>>>>>>>>>>>>> final release for distribution ? >>>>>>>>>>>>>>>> what are your constraints/requirements/wishes? >>>>>>>>>>>>>>> As always with bug fixes, the sooner the better! >>>>>>>>>>>>>>> But we surely could live without it for a few weeks... >>>>>>>>>>>>>>> What were your initial plan release-wise ? >>>>>>>>>>>>>> Depends how it goes, but probably I was going to wait and see >>>>>>>>>>>>>> what >>>>>>>>>>>>>> issues came up with the current release once people start to >>>>>>>>>>>>>> test >>>>>>>>>>>>>> and deploy a few Web Profile clients, and perhaps make a >>>>>>>>>>>>>> release >>>>>>>>>>>>>> when SAMP 1.3 makes RECOMMENDATION, hopefully about March. >>>>>>>>>>>>>> If you're keen though I might be persuaded to release >>>>>>>>>>>>>> something >>>>>>>>>>>>>> earlier. >>>>>>>>>>>>> March seems a bit (too) far from now for us, as we are eager to >>>>>>>>>>>>> push a first beta of AppLauncher to IVOA mailing lists... >>>>>>>>>>>>> Maybe a little 1.3.2 with Laurent's fix and the 2 new methods >>>>>>>>>>>>> could make its way earlier ? >>>>>>>>>>>>> >>>>>>>>>>>>> Anyway I know all this is on best effort mode, so keep up the >>>>>>>>>>>>> good work for us ;) >>>>>>>>>>>>> Sylvain >>>>>>>>>>>> OK I can probably do something, I'll try to get back to you in the >>>>>>>>>>>> next week or two with an update. If you don't hear by the end of >>>>>>>>>>>> the year, you can remind me. >>>>>>>>>>> Yeah !!! >>>>>>>>>> voila! >>>>>>>>>> >>>>>>>>>> http://software.astrogrid.org/doc/jsamp/ >>>>>>>>> :) :) :) >>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> 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/ >>>>>>>> >>>>>>> -- >>>>>>> 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/ >>>>>> >>>>>> >>>>>> -- >>>>>> Laurent Bourg?s >>>>>> Software engineer >>>>>> (Short-term Contract) >>>>>> +33 4 76 63 55 19 >>>>>> JMMC, IPAG - CNRS >>>>>> France >>>>>> >>>>>> >>>>> >>>>> -- >>>>> 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/ >>>> >>> >> >> > > -- > 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Archive.zip Type: application/zip Size: 26691 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From buddel at astro.rug.nl Tue Jan 24 03:29:16 2012 From: buddel at astro.rug.nl (Hugo Buddelmeijer) Date: Tue, 24 Jan 2012 12:29:16 +0100 Subject: Connecting a tablet to a SAMP environment on the desktop Message-ID: <4F1E960C.4030302@astro.rug.nl> Dear SAMP users, Tablets with a touch screen could be a valuable addition in the interactive exploration of our data. Therefore, it would be nice to be able to connect a tablet (iPad, android) to an existing SAMP setup. That is, to have the SAMP HUB and most applications running on the desktop, and run only a simple interactive visualization tool on the tablet. However, this seems not to be possible with either the default profile or the proposed web profile. What are your ideas on this? - The default profile requires the tablet application to setup an XML-RPC server. In practice this would often be impossible, for example due to inbound-blocking firewalls or restrictions in the device itself. - The web profile could remove these restrictions. Running a SAMP application on a tablet would then simply become loading a web page. However, this does not work either because the spec recommends to block connections from another device (sec. 5.2.3 and 5.4.2.1). My ideas to remedy this would be one of the following: - (Optionally) allow external connections in the SAMP web profile? - Add the long-polling option also to the default SAMP profile? - A third profile? At the moment I'm not in the position to work on such a tablet application myself, although I would like to do so in the future. However, I thought the web profile standardization would be a good opportunity to discuss this scenario. Greetings, Hugo Buddelmeijer From m.b.taylor at bristol.ac.uk Wed Jan 25 02:56:15 2012 From: m.b.taylor at bristol.ac.uk (Mark Taylor) Date: Wed, 25 Jan 2012 10:56:15 +0000 (GMT) Subject: Connecting a tablet to a SAMP environment on the desktop In-Reply-To: <4F1E960C.4030302@astro.rug.nl> References: <4F1E960C.4030302@astro.rug.nl> Message-ID: Hugo, On Tue, 24 Jan 2012, Hugo Buddelmeijer wrote: > Tablets with a touch screen could be a valuable addition in the interactive > exploration of our data. Therefore, it would be nice to be able to connect a > tablet (iPad, android) to an existing SAMP setup. That is, to have the SAMP > HUB and most applications running on the desktop, and run only a simple > interactive visualization tool on the tablet. I think this is a very interesting idea, and certainly something it would be good to facilitate rather than preclude in the standard. > However, this seems not to be possible with either the default profile or the > proposed web profile. What are your ideas on this? > > - The default profile requires the tablet application to setup an XML-RPC > server. In practice this would often be impossible, for example due to > inbound-blocking firewalls or restrictions in the device itself. I don't know enough about tablet-like devices to understand the restrictions that a tablet-based application is likely to be operating under, but if as you say they are unable to run an XML-RPC server on a port of their choice then yes the Standard Profile is not suitable for data-consuming clients. > - The web profile could remove these restrictions. Running a SAMP application > on a tablet would then simply become loading a web page. However, this does > not work either because the spec recommends to block connections from another > device (sec. 5.2.3 and 5.4.2.1). Done like this (web profile hub connection from an external host) hub discovery is still an issue (as you noted before), each web app would need to know what host the hub resides on. It could get the user to type it in or something, which would work but be a bit clunky. To get round the hub discovery issue, the nicest way for tablet SAMP connection to a desktop to work might be for the tablet to run a hub which talks to the desktop hub, and then web apps on the tablet can talk to the tablet hub using the web profile, while the tablet hub bridges connections to the desktop hub. Then tablet applications can do hub discovery in the usual way, and they also don't need to know whether they are talking cross-host or just locally. It would require a native application on the tablet (hub + hub-hub bridge) but this only needs to be written once, not for each app. If the tablet-desktop hub bridging is done using the Standard Profile, this whole scheme could work with the Standard and Web profiles exactly as they stand. If running an XML-RPC server on an application-chosen port is impossible then it would have to use the Web Profile (or possibly some new profile) with the local-host restriction relaxed as you suggest. > My ideas to remedy this would be one of the following: > - (Optionally) allow external connections in the SAMP web profile? > - Add the long-polling option also to the default SAMP profile? > - A third profile? Since it's not clear (to me at least) what would be the best way to implement this kind of connection, I agree that it would be good to adjust the standard so as not to preclude the scenario you're talking about, if it can be done without too much disruption. I think the best thing would be to revise the text slightly to admit your first suggestion. In fact external connections are not forbidden at the moment, but they are strongly RECOMMENDED against. I suggest addding the following text to the end of section 5.4.2.1: There may be circumstances under which it is appropriate to relax this local host restriction, for instance to enable collaboration with a known external host not capable of Standard Profile communication, such as a mobile device operated by the hub user. However, it is RECOMMENDED that Web Profile implementations at least restrict access to the local host in their default configuration, and if access is permitted to external hosts it is only by explicit user request, and to a named host or list of hosts. Opening the well-known Web Profile hub server port to the internet at large would invite denial of service and perhaps phishing attacks in which the user is bombarded with unwanted SAMP registration requests. plus a couple of extra "under normal circumstances" clauses elsewhere in sections 5.4.2.1 and 5.2.3. Do you think that's a good way forward? Anyone else have comments? 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/ From thomas.boch at astro.unistra.fr Thu Jan 26 02:56:02 2012 From: thomas.boch at astro.unistra.fr (Thomas Boch) Date: Thu, 26 Jan 2012 11:56:02 +0100 Subject: Storing connection info when using SAMP Web profile Message-ID: <4F213142.303@astro.unistra.fr> 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 From luigi at lambrate.inaf.it Thu Jan 26 03:14:39 2012 From: luigi at lambrate.inaf.it (Luigi Paioro) Date: Thu, 26 Jan 2012 12:14:39 +0100 Subject: Storing connection info when using SAMP Web profile In-Reply-To: <4F213142.303@astro.unistra.fr> References: <4F213142.303@astro.unistra.fr> Message-ID: <4F21359F.50605@lambrate.inaf.it> 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/ From m.b.taylor at bristol.ac.uk Thu Jan 26 03:56:22 2012 From: m.b.taylor at bristol.ac.uk (Mark Taylor) Date: Thu, 26 Jan 2012 11:56:22 +0000 (GMT) Subject: Storing connection info when using SAMP Web profile In-Reply-To: <4F213142.303@astro.unistra.fr> References: <4F213142.303@astro.unistra.fr> Message-ID: 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/ From thomas.boch at astro.unistra.fr Thu Jan 26 04:24:54 2012 From: thomas.boch at astro.unistra.fr (Thomas Boch) Date: Thu, 26 Jan 2012 13:24:54 +0100 Subject: Storing connection info when using SAMP Web profile In-Reply-To: <4F21359F.50605@lambrate.inaf.it> References: <4F213142.303@astro.unistra.fr> <4F21359F.50605@lambrate.inaf.it> Message-ID: <4F214616.10800@astro.unistra.fr> 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 From bourges.laurent at gmail.com Fri Jan 27 09:08:01 2012 From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=) Date: Fri, 27 Jan 2012 18:08:01 +0100 Subject: [jmmc-tech-group] Internal SAMP Hub ? In-Reply-To: <8F62C266-ADB6-4985-B388-EC25CA573CE3@obs.ujf-grenoble.fr> References: <4919208E-3FB5-4D30-A30F-DAC260ABE2B6@obs.ujf-grenoble.fr> <91E51C4F-D6C7-4BFB-8DDA-FF5DC0DB49A0@obs.ujf-grenoble.fr> <25A2522C-0A67-4155-8C2E-D9BD72AF5BE9@obs.ujf-grenoble.fr> <4EE75328.60701@obs.ujf-grenoble.fr> <846D6F0F-DDDD-4094-8860-B4A8200E1CF1@obs.ujf-grenoble.fr> <848E1C20-38CB-4804-80F7-D9789CC9D3C0@obs.ujf-grenoble.fr> <8F62C266-ADB6-4985-B388-EC25CA573CE3@obs.ujf-grenoble.fr> Message-ID: Mark and all samp users, Here again I submit you a patch for JSamp 1.3.2 that fixes definitely both shutdown hook issues (client and hub shutdown ordering i.e. leaking zombie clients) and fixes a lot of memory leaks related to client register / unregister : - Shutdown hook Threads were disabling garbage collection for Hub / XmlHubConnection - java.util.Timer Threads never stopped: HubConnector.regTimer related to setAutoConnect(), ClientTracker.tidyTimer - ResultHandler timeout watcher thread never stopped: HubConnector.CallHandler.timeouter - leaking InternalServer instances related to every client started / stopped and also HttpServer.Handler instances ... I provide also in the patch my test class which loops over [setActive(true / false] 10 000 times. With standard 1.3.2 release and JVM settings set to "-Xms8m -Xmx8m -XX:+HeapDumpOnOutOfMemoryError -verbose:gc"; I get an OutOfMemoryError after 200 iterations. With my patched JSAMP, the test succeeds i.e. 10 000 iterations are OK. Mark, could you look at the code (modifications indicated by // LAURENT) ? If you updated JSAMP code, I could contribute to test / update the patch or help you to understand / fix such problems. FYI, I am not really sure how to properly clean up CallableClientServer / InternalServer / HttpServer leaks. Hope that these problems will one day be fixed in JSAMP release and it will help all of us enjoy JSAMP; In particular it could help WebProfile use cases as it requires many client register / unregister operations ... Best regards, Laurent -------------- next part -------------- A non-text attachment was scrubbed... Name: Capture-XmlRpcHubConnection-ShutdownThreadLEAK.png Type: image/png Size: 207068 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: jsamp_1.3.2_patch.tar.gz Type: application/x-gzip Size: 41034 bytes Desc: not available URL: From buddel at astro.rug.nl Mon Jan 30 03:10:27 2012 From: buddel at astro.rug.nl (Hugo Buddelmeijer) Date: Mon, 30 Jan 2012 12:10:27 +0100 Subject: Connecting a tablet to a SAMP environment on the desktop In-Reply-To: References: <4F1E960C.4030302@astro.rug.nl> Message-ID: <4F267AA3.1020804@astro.rug.nl> Hi Mark et al., Thanks for your reply. With HUB-HUB communication it would probably be possible to create tablet SAMP clients with the current version of the profiles. However, your suggested change of the web profile would make tablet clients much more feasible. Therefore, I do think the proposed paragraph would be valuable addition to the web profile. How it could be done now: - Create one HUB-application using the standard profile. - This has to be a native application, because it needs to be a server. - This costs money for a developer license. However, this only has to be paid for the development/distribution of the HUB. - Leave it to the tablet owner to ensure that inbound connections to the tablet are possible. This can be prohibitively hard. - In my case this would require setting up an SSH tunnel, since I do not control the firewalls that 'protect' my tablet. - Allow webapplications to connect to this HUB. With the proposed changes: - Allow the HUB to accept external connections on the web profile. - Create a tablet web application that connects to the main HUB through the web profile. Opening the port to the world by default would indeed be a security risk. However, making it possible for the user to do so temporarily would be very valuable. A final note from a more general perspective. It seems that tablet world (and computing in general) moves to the paradigm where inbound connections should be prevented when at all possible. There is to true need for inbound connections to SAMP clients, as the web profile demonstrates. It would therefore be useful to take this development into account, irrespective of whether we consider this change to be good or bad. Greetings, Hugo On 01/25/2012 11:56 AM, Mark Taylor wrote: > Hugo, > > On Tue, 24 Jan 2012, Hugo Buddelmeijer wrote: > >> Tablets with a touch screen could be a valuable addition in the interactive >> exploration of our data. Therefore, it would be nice to be able to connect a >> tablet (iPad, android) to an existing SAMP setup. That is, to have the SAMP >> HUB and most applications running on the desktop, and run only a simple >> interactive visualization tool on the tablet. > > I think this is a very interesting idea, and certainly something it > would be good to facilitate rather than preclude in the standard. > >> However, this seems not to be possible with either the default profile or the >> proposed web profile. What are your ideas on this? >> >> - The default profile requires the tablet application to setup an XML-RPC >> server. In practice this would often be impossible, for example due to >> inbound-blocking firewalls or restrictions in the device itself. > > I don't know enough about tablet-like devices to understand the > restrictions that a tablet-based application is likely to be > operating under, but if as you say they are unable to run an XML-RPC > server on a port of their choice then yes the Standard Profile > is not suitable for data-consuming clients. > >> - The web profile could remove these restrictions. Running a SAMP application >> on a tablet would then simply become loading a web page. However, this does >> not work either because the spec recommends to block connections from another >> device (sec. 5.2.3 and 5.4.2.1). > > Done like this (web profile hub connection from an external host) > hub discovery is still an issue (as you noted before), each web app > would need to know what host the hub resides on. It could get the > user to type it in or something, which would work but be a bit clunky. > > To get round the hub discovery issue, the nicest way > for tablet SAMP connection to a desktop to work might > be for the tablet to run a hub which talks to the desktop hub, > and then web apps on the tablet can talk to the tablet hub > using the web profile, while the tablet hub bridges connections to > the desktop hub. Then tablet applications can do hub discovery in > the usual way, and they also don't need to know whether they are > talking cross-host or just locally. It would require a native > application on the tablet (hub + hub-hub bridge) but this only > needs to be written once, not for each app. If the tablet-desktop > hub bridging is done using the Standard Profile, this whole scheme > could work with the Standard and Web profiles exactly as they stand. > If running an XML-RPC server on an application-chosen port is impossible > then it would have to use the Web Profile (or possibly some new profile) > with the local-host restriction relaxed as you suggest. > >> My ideas to remedy this would be one of the following: >> - (Optionally) allow external connections in the SAMP web profile? >> - Add the long-polling option also to the default SAMP profile? >> - A third profile? > > Since it's not clear (to me at least) what would be the best way > to implement this kind of connection, I agree that it would be > good to adjust the standard so as not to preclude the scenario > you're talking about, if it can be done without too much disruption. > > I think the best thing would be to revise the text slightly to admit > your first suggestion. In fact external connections are not > forbidden at the moment, but they are strongly RECOMMENDED against. > I suggest addding the following text to the end of section 5.4.2.1: > > There may be circumstances under which it is appropriate to relax this > local host restriction, for instance to enable collaboration with > a known external host not capable of Standard Profile communication, > such as a mobile device operated by the hub user. > However, it is RECOMMENDED that Web Profile implementations at > least restrict access to the local host in their default > configuration, and if access is permitted to external hosts > it is only by explicit user request, and to a named host or > list of hosts. > Opening the well-known Web Profile hub server port to the internet at > large would invite denial of service and perhaps phishing attacks > in which the user is bombarded with unwanted SAMP registration > requests. > > plus a couple of extra "under normal circumstances" clauses elsewhere > in sections 5.4.2.1 and 5.2.3. > > Do you think that's a good way forward? Anyone else have comments? > > 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/ From m.b.taylor at bristol.ac.uk Mon Jan 30 04:15:07 2012 From: m.b.taylor at bristol.ac.uk (Mark Taylor) Date: Mon, 30 Jan 2012 12:15:07 +0000 (GMT) Subject: Connecting a tablet to a SAMP environment on the desktop In-Reply-To: <4F267AA3.1020804@astro.rug.nl> References: <4F1E960C.4030302@astro.rug.nl> <4F267AA3.1020804@astro.rug.nl> Message-ID: Hugo, thanks, I've made the change to the document. As far as the JSAMP implementation goes, it currently does not permit the non-local host access you suggest, but I'll consider adding an option for it in the future, especially if anybody wants to try to develop a tablet client along these lines. I take your point about the mobile device view of the world (web-like clients running in browser-like environments, rather than traditional style clients, are becoming more common, even outside browsers as such). Being a bit of an old-technology guy, it's something I hadn't thought much about, but I expect you're right it is something we're going to have to keep in mind. Mark On Mon, 30 Jan 2012, Hugo Buddelmeijer wrote: > Hi Mark et al., > > Thanks for your reply. With HUB-HUB communication it would probably be > possible to create tablet SAMP clients with the current version of the > profiles. However, your suggested change of the web profile would make tablet > clients much more feasible. Therefore, I do think the proposed paragraph would > be valuable addition to the web profile. > > > How it could be done now: > - Create one HUB-application using the standard profile. > - This has to be a native application, because it needs to be a server. > - This costs money for a developer license. However, this only has to be paid > for the development/distribution of the HUB. > - Leave it to the tablet owner to ensure that inbound connections to the > tablet are possible. This can be prohibitively hard. > - In my case this would require setting up an SSH tunnel, since I do not > control the firewalls that 'protect' my tablet. > - Allow webapplications to connect to this HUB. > > With the proposed changes: > - Allow the HUB to accept external connections on the web profile. > - Create a tablet web application that connects to the main HUB through the > web profile. > > > Opening the port to the world by default would indeed be a security risk. > However, making it possible for the user to do so temporarily would be very > valuable. > > > A final note from a more general perspective. It seems that tablet world (and > computing in general) moves to the paradigm where inbound connections should > be prevented when at all possible. There is to true need for inbound > connections to SAMP clients, as the web profile demonstrates. It would > therefore be useful to take this development into account, irrespective of > whether we consider this change to be good or bad. > > Greetings, > Hugo > > > On 01/25/2012 11:56 AM, Mark Taylor wrote: > > Hugo, > > > > On Tue, 24 Jan 2012, Hugo Buddelmeijer wrote: > > > > > Tablets with a touch screen could be a valuable addition in the > > > interactive > > > exploration of our data. Therefore, it would be nice to be able to connect > > > a > > > tablet (iPad, android) to an existing SAMP setup. That is, to have the > > > SAMP > > > HUB and most applications running on the desktop, and run only a simple > > > interactive visualization tool on the tablet. > > > > I think this is a very interesting idea, and certainly something it > > would be good to facilitate rather than preclude in the standard. > > > > > However, this seems not to be possible with either the default profile or > > > the > > > proposed web profile. What are your ideas on this? > > > > > > - The default profile requires the tablet application to setup an XML-RPC > > > server. In practice this would often be impossible, for example due to > > > inbound-blocking firewalls or restrictions in the device itself. > > > > I don't know enough about tablet-like devices to understand the > > restrictions that a tablet-based application is likely to be > > operating under, but if as you say they are unable to run an XML-RPC > > server on a port of their choice then yes the Standard Profile > > is not suitable for data-consuming clients. > > > > > - The web profile could remove these restrictions. Running a SAMP > > > application > > > on a tablet would then simply become loading a web page. However, this > > > does > > > not work either because the spec recommends to block connections from > > > another > > > device (sec. 5.2.3 and 5.4.2.1). > > > > Done like this (web profile hub connection from an external host) > > hub discovery is still an issue (as you noted before), each web app > > would need to know what host the hub resides on. It could get the > > user to type it in or something, which would work but be a bit clunky. > > > > To get round the hub discovery issue, the nicest way > > for tablet SAMP connection to a desktop to work might > > be for the tablet to run a hub which talks to the desktop hub, > > and then web apps on the tablet can talk to the tablet hub > > using the web profile, while the tablet hub bridges connections to > > the desktop hub. Then tablet applications can do hub discovery in > > the usual way, and they also don't need to know whether they are > > talking cross-host or just locally. It would require a native > > application on the tablet (hub + hub-hub bridge) but this only > > needs to be written once, not for each app. If the tablet-desktop > > hub bridging is done using the Standard Profile, this whole scheme > > could work with the Standard and Web profiles exactly as they stand. > > If running an XML-RPC server on an application-chosen port is impossible > > then it would have to use the Web Profile (or possibly some new profile) > > with the local-host restriction relaxed as you suggest. > > > > > My ideas to remedy this would be one of the following: > > > - (Optionally) allow external connections in the SAMP web profile? > > > - Add the long-polling option also to the default SAMP profile? > > > - A third profile? > > > > Since it's not clear (to me at least) what would be the best way > > to implement this kind of connection, I agree that it would be > > good to adjust the standard so as not to preclude the scenario > > you're talking about, if it can be done without too much disruption. > > > > I think the best thing would be to revise the text slightly to admit > > your first suggestion. In fact external connections are not > > forbidden at the moment, but they are strongly RECOMMENDED against. > > I suggest addding the following text to the end of section 5.4.2.1: > > > > There may be circumstances under which it is appropriate to relax this > > local host restriction, for instance to enable collaboration with > > a known external host not capable of Standard Profile communication, > > such as a mobile device operated by the hub user. > > However, it is RECOMMENDED that Web Profile implementations at > > least restrict access to the local host in their default > > configuration, and if access is permitted to external hosts > > it is only by explicit user request, and to a named host or > > list of hosts. > > Opening the well-known Web Profile hub server port to the internet at > > large would invite denial of service and perhaps phishing attacks > > in which the user is bombarded with unwanted SAMP registration > > requests. > > > > plus a couple of extra "under normal circumstances" clauses elsewhere > > in sections 5.4.2.1 and 5.2.3. > > > > Do you think that's a good way forward? Anyone else have comments? > > > > 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/ > > -- 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/