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