troubles with VO apps in multiuser environment

[Mark Taylor]

Petr,

On Fri, 24 Apr 2015, Petr Skoda wrote:

> I have just finished several courses teaching VO technology and at one
> university (in Brno) the students were using central server with terminals
> under individual accounts.
> 
> We had  immediately seen that so far no one tried to use VO tool sin such
> environment as it did not work or behaved chaoticaly ....
> 
> I am addressing this to all VO apps developer in order to revise their
> soultion and identify the potential issues....

   ...

> 2) Case SAMP
> 
> 
> we tried to  activate web samp on Vizier web page (the sattelite dish that
> runs SAMP hub) and send table to TOPCAT.
> 
> Complete mess ....   some students were able to run it (I gues about first 2
> or 3) those who were late not - even with closing all windows and restarting
> ....

The Web Profile of SAMP (web pages like the Vizier one communicating
with SAMP applications) will not work when multiple users are
running their desktop applications (strictly, their hubs)
on the same host.  This is a basic architectural limitation of
the way that Web SAMP works, and there's no way round it.

Briefly: the well-known hub communication endpoint is at a fixed
port number on the local host, and there is, by design constraints
imposed by browsers for security reasons, no way for the hub to
know which user on the local machine is sending communications,
so it just assumes it's the right one, i.e. the sole user of the machine.
If there is no sole user, there's trouble.  This is noted in
sec 5.1.1 of the SAMP standard (http://www.ivoa.net/documents/SAMP/):

   Note that since this well-known port number is fixed, it is not
   possible for more than one Web Profile hub to run on the same host.
   The Web Profile Hub and corresponding web browser MUST run on the
   same host, and SHOULD always be run by the same user.

and the security implications are worked through in section 5.4,
especially 5.4.2.1.
 
> When clicking on dish it did not ask for authorization (famous SAMP window)
> and it did not show in hub registered apps.
> 
> Even worse when all 8 students tried to randomly close all windows with to
> tools and restart again and broadcast tables ....
> it appeared that in fact some were sending their tables to other users - we
> did not find logic behind this ....
> Some did not see Aladin web registered in their SAMP hub but were able
> seamlessly (withou noticing) to send tables to some other students - but the
> broadcasting did not work to all - only about 2 or 3...

What I expect actually happened is that the first student to start
a SAMP hub (Student A) actually received all the SAMP communications.
So in fact the authorisation window did pop up each time,
but instead of popping up on the screen of the person who
hit the SAMP button on the Vizier web page (Student X),
it popped up on Student A's screen.  No doubt Student A was
just hitting either Accept or Deny each time to get the damn
thing to go away.  When Student A hits Accept, whatever the web
page was trying to do (send a table) happened to Student A's
desktop and to Student X it looked like nothing happened.

So much for the technical analysis.  The basic effect was that you,
a fairly well-informed VO enthusiast, tried something in a tutorial
that you thought would work, and it failed miserably.

Although we did think very carefully about the security
implications of potentially hostile users on the same machine
having access to the same hub, I didn't give as much consideration
to multiple users on the same machine as a matter of course.
My thinking was that in nearly all cases these days users will be
running with one desktop/laptop computer per user rather than
terminals logged into a single host.  Obviously not the case here.
You said:

> Can someone try other VO tools in multi user environment ?
> IMHO it is crucial for success of VO education (in schools) but not only there

is multi-user logins to a single server really a common setup
in schools?

The problem was exacerbated by the fact in a tutorial scenario
everybody is doing similar things at the same time, so you're
expecting to see the confirmation dialogue at some point, and if
it pops up at not exactly the right time (when another user
hits a web page button rather than when you do) you'll probably
figure it's all part of your own interaction.

What do we do about it?

Obviously, one lesson for anybody who's reading this is: don't try
and do Web SAMP with multiple people running desktop applications
on the same host.  But most potential users won't read this
thread or the details of the SAMP standard.
A generalisation of that rule (which I observe when giving 
demos or tutorials) is: if you're using SAMP or any
inter-process communication in a demo, tutorial, or other
unfamiliar context, be ready for the possibility that it's going to
fail in unpredictable ways and have backup plans in place.

More specifically, can we advertise this failing so that
users will be aware of it before it happens?
If you start topcat and somebody else on the same machine is
already running the web profile, you'll get a message to the
console:

   WARNING: Failed to start SAMP hub profile Web

The students, if they were running from the command line, would have
seen (and most likely ignored) this.  If they ran it by clicking
something, the message is probably not seen.  It would be possible
to present this instead as a big popup at application start
"DANGER: DON'T USE WEB-BASED SAMP APPLICATIONS THEY WON'T WORK".
That might have solved your problem, but would in most cases
just be annoying and irrelevant noise; my feeling is it's not
a good idea.

So, I'm sorry it didn't go well, but I don't have any great ideas
for preventing this kind of thing in future.  Does anyone else?

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/