Update anonymous user permissions on AEM as a Cloud Service | Community
Skip to main content
A
anubhav1988
October 18, 2021
Solved

Update anonymous user permissions on AEM as a Cloud Service

  • October 18, 2021
  • 3 replies
  • 3134 views

Hi folks,

I need to give jcr:read access on certain nodes in /apps directory to anonymous user on AEM publish instance.

In AEM as a Cloud Service, I don't have the permissions to access user management console and unable to give permissions manually.

I tried repoinit to grant the permissions.

 

set ACL on /apps allow jcr:read for anonymous end

 

However, the code pipeline gives error during deployment as below.

 

DD.MM.YYYY 04:00:04.307 *ERROR* [Apache Sling Repository Startup Thread #1] com.adobe.granite.repository.impl.SlingRepositoryManager Exception in a SlingRepositoryInitializer, SlingRepository service registration aborted java.lang.RuntimeException: Failed to set ACL (javax.jcr.PathNotFoundException: Cannot set ACL on non-existent path /apps) AclLine ALLOW {principals=[anonymous], privileges=[jcr:read]}

 


Can you please suggest a resolution for this?


Note - I am able to give these permissions on my local which fixes the actual issue we are facing.

 

Regards,
Anubhav

 

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by rampai

Hi @anubhav1988,

 

The problem would be because the repo init statements mention mutable content in the documentation.

 

/apps and /libs are immutable at runtime and ACLs are stored under the respective nodes that need the permission in. AEM. 

 

Did you try packaging rep:policy nodes in ui.apps package?

 

https://experienceleague.adobe.com/docs/experience-manager-cloud-service/implementing/developing/aem-project-content-package-structure.html

 

The ui.apps package contains all the code to be deployed and only deploys to /apps. Common elements of the ui.apps package include, but are not limited to:

  • Component definitions and HTL scripts
    • /apps/my-app/components
  • JavaScript and CSS (via Client Libraries)
    • /apps/my-app/clientlibs
  • Overlays of /libs
    • /apps/cq, /apps/dam/, etc.
  • Fallback context-aware configurations
    • /apps/settings
  • ACLs (permissions)
    • Any rep:policy for any path under /apps

 

Thanks,

Ram

3 replies

Sanjay_Bangar
Community Advisor
Sanjay_BangarCommunity Advisor
Community Advisor
October 18, 2021

Hi @anubhav1988 ,

                                you can give the permission through dispatcher in the filter. Any file.

 

 

Regards,

Sanjay

    Ankur_Khare
    Community Advisor
    Ankur_KhareCommunity Advisor
    Community Advisor
    October 18, 2021

    Refer this one-

     

    https://experienceleague.adobe.com/docs/experience-manager-learn/cloud-service/accessing/walk-through.html?lang=en

      rampai
      Community Advisor
      rampaiCommunity AdvisorAccepted solution
      Community Advisor
      October 18, 2021

      Hi @anubhav1988,

       

      The problem would be because the repo init statements mention mutable content in the documentation.

       

      /apps and /libs are immutable at runtime and ACLs are stored under the respective nodes that need the permission in. AEM. 

       

      Did you try packaging rep:policy nodes in ui.apps package?

       

      https://experienceleague.adobe.com/docs/experience-manager-cloud-service/implementing/developing/aem-project-content-package-structure.html

       

      The ui.apps package contains all the code to be deployed and only deploys to /apps. Common elements of the ui.apps package include, but are not limited to:

      • Component definitions and HTL scripts
        • /apps/my-app/components
      • JavaScript and CSS (via Client Libraries)
        • /apps/my-app/clientlibs
      • Overlays of /libs
        • /apps/cq, /apps/dam/, etc.
      • Fallback context-aware configurations
        • /apps/settings
      • ACLs (permissions)
        • Any rep:policy for any path under /apps

       

      Thanks,

      Ram

        Terms & ConditionsAccessibility statement

        Loading footer...