- Issue created by @attiks
- 🇧🇪Belgium attiks
MR created
For
settings.php
you can use the following$settings['drd.trusted_modules'] = [ 'ocha_drd', ];
Only problem left is how and where to display the output
- Status changed to Needs review
about 1 year ago 10:35am 13 November 2023 - 🇩🇪Germany jurgenhaas Gottmadingen
I'm not sure what the problem should be, that this is trying to solve. Can you please explain in more detail? What is that about a class vs a script and why do we need a setting for trusted modules?
- 🇧🇪Belgium attiks
The idea is to disable passing PHP code from the DRD site to the remote sites, so only code on disk (on the remote site) can be executed.
In the case the DRD site get hacked, it will be able to pass and execute any PHP code on the client sites, OPS people don't like it.
About the name "trusted_modules", it can be changed, but that was the best I could come up with
- Status changed to Closed: won't fix
about 1 year ago 2:26pm 13 November 2023 - 🇩🇪Germany jurgenhaas Gottmadingen
If there is any reason to believe that a DRD site could have been hacked, then there is everything at risk. The DRD site should not be publicly available, as it has full control over remote sites. That's what you accept when you grant admin access to DRD while adding a new remote site.
There had been security considerations in the past and also a couple of issue about this topic. There is no intention to change the approach on this.