SAMP environment variables

Luigi Paioro luigi at lambrate.inaf.it
Thu Jun 25 02:40:50 PDT 2009


Hi Mark,

>>>    MType:
>>>       client.env.get
>>>    Arguments:
>>>       name (string) - environment variable name
>>>    Return values:
>>>       value (string) - value of env variable "name" in receiver's
>>> environment

-- omission --

> I hadn't thought of that.  Anybody with a SAMP connection to a hub
> which you're connected to already has the potential to do harmful
> things (for instance load unwanted images into your image viewer),
> so the scenarios I've been thinking of assume that connected clients
> are reasonably trusted (it's why the samp.secret is present in a 
> user-only-read file in the lockfile).  However I know that you've
> been thinking of more distributed scenarios, so there may be some
> important issues here.  Restricting accessible variables by namespace
> would be possible in any case (though the MType definition gets
> a bit more messy).


I've thought to a possible compromise. The MType could be left as you 
have proposed without special restrictions. Locally it can be assumed 
that the connected clients are trusted, since it is reasonably true for 
the Standard Profile. In those cases where a more distributed scenario 
is involved, it is responsibility of the "distributed profile" 
developers to guarantee the security of the system, for example allowing 
to connect with the Hub only authorised applications (e.g. through Basic 
Authentication over a TCL channel or through certificates). Does it 
sound good?


Luigi



More information about the apps-samp mailing list