LorenzoNey is seeking guidance on isolating a Discourse plugin’s secrets file or sensitive data to prevent access by other plugins in the same environment. Specifically, he wants to securely store and access encryption keys within his plugin.
Merefield responded by referencing a technique employed in the Discourse Encrypt plugin, but noted a caveat. He emphasized that, as a Ruby on Rails (RoR) app, Discourse manages user authorization properly, but a plugin has administrative scope, making it possible for one plugin to access data from another. He suggested that the onus is on the installer to vet all code added to an instance and recommended exercising caution when installing third-party plugins.
LorenzoNey thanked Merefield for his thorough response and expressed gratitude for the help.
I am currently developing a plugin for Discourse and have encountered a specific challenge related to security. My plugin requires storing and accessing sensitive data, and I am exploring ways to ensure this data remains secure, particularly from access by other plugins in the same Discourse environment.
Could you provide insights or recommendations on the following question:
Is it possible to isolate a Discourse plugin so that the secrets file or sensitive data used by my plugin cannot be read or accessed by other plugins installed on the same Discourse instance? If so, what are the best practices or recommended approaches to achieve this level of security?
I am particularly interested in methods allowing me to securely store and access encryption keys or similar sensitive data within my plugin, without exposing them to other plugins or parts of the Discourse system.
Thank you in advance for your assistance and suggestions!
Of course, as a RoR app, Discourse manages user authorization properly, so, for example, you cannot access admin resources as a normal user.
But a plugin has administrative scope (beyond the core initialisation stage), so your base assumption must be it is possible for a plugin to access data from another plugin (even if very unlikely - is a reactions plugin going to broadcast your data to Facebook?! I doubt it!! )
The onus is on the installer (ie the human administrator) to vet all the code that is added to an instance so it doesn’t abuse any data.
If you are risk averse, simply do not install 3rd party plugins you don’t fully understand - keep to the core install only.
But in the end of the day, make sure you have a senior RoR dev on staff to review everything that is being added to an instance?
)
I will take into consideration what you’ve posted, I’m very grateful for your help.