Decide on Subset of Environmental Variables to Expose about rocket.chat.apps-engine HOT 5 CLOSED

Can it access the main process.env e.g. for Heroku environments, there might be a lot of useful stuff in there. Another key one would be local/dev/staging/live environment switches.

from rocket.chat.apps-engine.

Making the list of enabled Rocketlets available as an env var would also be handy for any tricky workarounds once the inevitable conflicts between extensions start to surface.

from rocket.chat.apps-engine.

No, the Rocketlets are going to be in a restricted environment which only has access to provided variables and global properties. Honestly, I'm debating whether or not to even allow environmental variables 🤔

from rocket.chat.apps-engine.

Well as long as they can access mongo and manage their own settings, I think that would cover most use cases where the Rocketlet's logic might need some wider context about the state of the RC instance. I'm sure there'll be unforeseen uses but its not worth trying to predict and over-engineer, just have to deal with it as they evolve.

Maybe a permissions layer (which could be quite simple for now) should be considered for this type of thing, to keep instance owners informed of security risks when installing Rocketlets, then we don't have to be overly protective and limiting. Similar to permissions for users, but implemented like adding a facebook app, e.g.

This Rockelet can

• modify user roles
• modify messages

The above could have some correlation to the internal API endpoints used in the Rocketlet source.

I've probably gone off-topic for this issue. 🤷‍♂️

from rocket.chat.apps-engine.

Closing as so far the allowed ones are: 'NODE_ENV', 'ROOT_URL', 'INSTANCE_IP'

from rocket.chat.apps-engine.