- Issue created by @w01f
- πΊπΈUnited States pookmish
Any security concerns are handled by the security advisory process β . Also, as mentioned on the module information "This module is definitely not a replacement for full-fledged theming" and standard theme development is recommended for long term stability.
That being said, any concerns with storing the CSS/JS in the database is arguably minimal compared to any other data stored, such as user data, privileged content data, etc. If a user has access to manipulate data in the database, they have greater access to obtain more sensitive information. The permissions to edit via the UI is configured to be "restricted" and therefore there is a warning when granting permissions that there is a security concern with the message "Warning: Give to trusted roles only; this permission has security implications", therefore, any risk is assumed by the site administrator granting such a permission.
Can you encrypt the data that is stored in the DB, sure. You can implement your own hooks such as hook_entity_presave and hook_entity_load and encrypt/decrypt the data stored in the DB. If you are concerned about the risk of the generated CSS/JS files, I will refer back to my first point and suggest standard theme practices. Drupal's CSS/JS aggregation as well as browser loading requires a static file to be available, so there's no other option than to have these saved to the file system upon page load.
- πΊπΈUnited States w01f
Thank you very much! That is extremely helpful and I will continue to dive more into this in the coming weeks. As I said, I'm already using and enjoy this on a few sites already in cases where the content editors want an easy way to add some of their own CSS/JS and understand the general implications - risks and best practices.
- π©πͺGermany Anybody Porta Westfalica
@pookmish unclear how to proceed here. Should we close this works as designed?
- Status changed to Closed: works as designed
7 months ago 6:46pm 25 June 2024