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.
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.
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.
Hi @arunpatidar
I need to update the user.mapping value for the below path. Kindly share the best approach to do the same.
/apps/groovyconsole/osgiconfig/config/org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.amended-groovy-console
current
aem-groovy-console-bundle=groovy-console-system-user
Expected
aem-groovy-console-bundle=[groovy-console-system-user]
Hi @Lakshmi99
You can try to update the same config file or create a new one?
In Adobe Experience Manager (AEM), the preference order for OSGi configuration file types is as follows:
Hi @arunpatidar thank you for the reply.
Its not a custom config file. The below path is under groovyconsole and its a package created through pom.xml.
/apps/groovyconsole/osgiconfig/config/org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.amended-groovy-console
And there is a need to update the user.mapping value to this.
current
aem-groovy-console-bundle=groovy-console-system-user
Expected
aem-groovy-console-bundle=[groovy-console-system-user]
Kindly suggest how to handle it.
Thank you
Hi @Lakshmi99
You can raise a issue here
https://github.com/CID15/aem-groovy-console/issues
will raise the issue @arunpatidar
Meantime, I was trying to updating it through groovy script itself. But not its not returning the properties. But the issue here is its still showing as node instead of config file. Any help to resolve it please? Can't change it to config in higher environments as I don't have access.
import org.osgi.service.cm.ConfigurationAdmin
def admin = getService(ConfigurationAdmin)
def config = admin.getConfiguration("org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.amended-groovy-console")
def properties = config.properties
def String[] mappings =(String[])properties.get("user.mapping") as List
mappings.add("aem-groovy-console-bundle=[groovy-console-system-user]")
properties.put("user.mapping", mappings.toArray(new String[0]))
config.update(properties)
Hi @Lakshmi99
You can update the node's property at /apps/groovyconsole/osgiconfig/config using jcr/sling api
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.
Hi ,
I am trying to setup groovy console on my local AEM
Following steps : https://lucanerlich.com/docs/aem/groovy-console/
My build is failing . Kindly help me.
Error:
[INFO] Using 9 validators for package of type CONTAINER: jackrabbit-accesscontrol (org.apache.jackrabbit.vault.validation.spi.impl.AccessControlValidator), jackrabbit-filter (org.apache.jackrabbit.vault.validation.spi.impl.AdvancedFilterValidator), jackrabbit-properties (org.apache.jackrabbit.vault.validation.spi.impl.AdvancedPropertiesValidator), jackrabbit-docviewparser (org.apache.jackrabbit.vault.validation.spi.impl.DocumentViewParserValidator), jackrabbit-dependencies (org.apache.jackrabbit.vault.validation.spi.impl.DependencyValidator), jackrabbit-emptyelements (org.apache.jackrabbit.vault.validation.spi.impl.EmptyElementsValidator), jackrabbit-mergelimitations (org.apache.jackrabbit.vault.validation.spi.impl.MergeLimitationsValidator), jackrabbit-packagetype (org.apache.jackrabbit.vault.validation.spi.impl.PackageTypeValidator), jackrabbit-nodetypes (org.apache.jackrabbit.vault.validation.spi.impl.nodetype.NodeTypeValidator)
[ERROR] ValidationViolation: "jackrabbit-filter: Node '/apps/c4c-vendor-packages/container/install/aem-groovy-console-all-17.0.0.zip' is not contained in any of the filter rules", filePath=jcr_root\apps\c4c-vendor-packages\container\install\aem-groovy-console-all-17.0.0.zip
Kindly help me
Views
Replies
Total Likes