We have just discovered the groovy console, which is very powerful but also dangerous (from malicious or accidental use)
Thanks for any tips!
Solved! Go to Solution.
Views
Replies
Total Likes
I will share some of my experiences with groovy console.
We are using groovy console mostly for tasks, which can be automated. For example you want to migrate one component into another, you want to perform some content clean ups, you want to regenerate renditions for specific assets, when they don't have a specific rendition generated, and so on and so on. In some cases (like component migration) you will want to do it also on Publish instance, as this will eliminate the need of page activations (which goes in thousands from time to time).
Regarding securit, only specified users/groups can run groovy scripts, which minimizes the risk of being hacked. I would suggest to keep that list as short as possible.
Also, there is a tool called AEM Easy Content Upgrade tool, which adds a feature of running scripts automatically when they are placed in proper structure in your package (and there are other features as well).
This way you don't need to give access to groovy console to anyone, as only admin and AECU service user will be able to run scripts by default through groovy console. Also, you don't need direct access to publishers, as AECU will run the scripts for you.
I've never used it on AEM as a Cloud, but I saw that this tool is compatibile with it, so I would suggest to give it a try.
You cannot access a publish instance directly on AEM as a Cloud Service, so it does not make any sense to deploy it there.
On author you can directly access it, and you should restrict access to it by access control.
Thanks Jorg. Access control is not something we have managed to figure out or get working with cloud AEM managed by admin console. we just use the two profiles AEM provides out of the box (user and admin for each env). We gave up because of the known issues with groups set in admin console not replicating properly, and our inability to set permissions or groups via build and deployment.
Luckily, groovyConsole does have a way to manage access by setting the group in the admin console, which works when AEM replicates the group set in the admin console (works 95% of the time). However, this method of controlling access to groovy console isnt used by the easy updater unfortunately.
Views
Replies
Total Likes
You can restricted groovy for certain users via https://github.com/icfnext/aem-groovy-console#osgi-configuration
To enable access to the Groovy Console from /groovyconsole
, update the Groovy Console Configuration Service via the OSGi console configuration page to enable the vanity path.
Script Execution Allowed Groups | List of group names that are authorized to use the console. By default, only the 'admin' user has permission to execute scripts. | [] |
the osgi config defining which groups can run console scripts is great, but unfortunately it doesn't stop anyone running scripts via the "AEM Easy Content Upgrade tool". The easy updater doesn't seem to have any security options.
Views
Replies
Total Likes
The access to this tool can also be restricted using ACL
The scripts and audit stored inside /var/groovyconsole , this can also be restricted using ACL.
I will share some of my experiences with groovy console.
We are using groovy console mostly for tasks, which can be automated. For example you want to migrate one component into another, you want to perform some content clean ups, you want to regenerate renditions for specific assets, when they don't have a specific rendition generated, and so on and so on. In some cases (like component migration) you will want to do it also on Publish instance, as this will eliminate the need of page activations (which goes in thousands from time to time).
Regarding securit, only specified users/groups can run groovy scripts, which minimizes the risk of being hacked. I would suggest to keep that list as short as possible.
Also, there is a tool called AEM Easy Content Upgrade tool, which adds a feature of running scripts automatically when they are placed in proper structure in your package (and there are other features as well).
This way you don't need to give access to groovy console to anyone, as only admin and AECU service user will be able to run scripts by default through groovy console. Also, you don't need direct access to publishers, as AECU will run the scripts for you.
I've never used it on AEM as a Cloud, but I saw that this tool is compatibile with it, so I would suggest to give it a try.