User cannot persist changes via Assets API | Community
Skip to main content
J
jlanssie-tme
Level 2
March 13, 2025
Solved

User cannot persist changes via Assets API

  • March 13, 2025
  • 4 replies
  • 928 views

I have a user that can perform CRUD operations via the UI.

He is inside the OOTB Contributors group and has permissions for a specific dam path: `/content/dam/data`, where he can create, read, update and delete Content Fragments. 

 

When this same user tries to perform CRUD operations over the Assets API, AEM throws an error

13.03.2025 09:10:36.149 *WARN* [141.135.37.92 [1741857036142] POST /api/assets/data/retailers/postman/postman-team-member HTTP/1.1] com.adobe.granite.rest.impl.servlet.PostRequest Exception during request processing. org.apache.sling.api.resource.PersistenceException: Unable to commit changes to session. at org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.commit(JcrResourceProvider.java:519) [org.apache.sling.jcr.resource:3.0.18] at org.apache.sling.resourceresolver.impl.providers.stateful.AuthenticatedResourceProvider.commit(AuthenticatedResourceProvider.java:240) [org.apache.sling.resourceresolver:1.10.0] at org.apache.sling.resourceresolver.impl.helper.ResourceResolverControl.commit(ResourceResolverControl.java:531) [org.apache.sling.resourceresolver:1.10.0] at org.apache.sling.resourceresolver.impl.ResourceResolverImpl.commit(ResourceResolverImpl.java:1031) [org.apache.sling.resourceresolver:1.10.0]

 

The HTTP Request gets a response

{ "class": [ "core/response" ], "properties": { "path": "/api/assets/data/postman-test", "parentLocation": "/api/assets/data.json", "referer": "", "changes": [], "location": "/api/assets/data/postman/postman-test.json", "status.message": "Unable to commit changes to session.", "status.code": 500 } }

 
The issue is not authentication. Adobe Experience Manager gets the request fine. It is not the payload or the Content Fragment either, or I would get a different kind of error. 

 

The Assets API also works fine on lower environments, Development & Staging. 

 

So, I am left wondering what the issue could be. I assume it is permissions as it is the ResourceResolver that fails to commit the changes, as it is mentioned in the logs. But I cannot wrap my head around why this works perfectly fine in the UI, but fails over the API.

Best answer by jlanssie-tme

As it turned out, the Granite Assets REST API bundle was not active. There was a dependency issue on a certain Adobe-bundle.

4 replies

giuseppebaglio
giuseppebaglio
Level 10
March 13, 2025

Please verify if the user and/or their corresponding user group (http://instance:port/security/groups.html) has write permissions for that folder. From the messages I can assume there is a resourceResolver.commit()/sessions.save() function that fails due to insufficient write permissions.

    J
    jlanssie-tmeAuthor
    Level 2
    March 18, 2025

    As I mentioned in the description, the user can do it via the UI. It only fails on the Assets API, so your suggestion is not relevant.

    AmitVishwakarma
    Community Advisor
    AmitVishwakarmaCommunity Advisor
    Community Advisor
    March 14, 2025

    Hi @jlanssie-tme ,

    It does sound like a permission issue, but since the user can perform CRUD operations via the UI, the problem might be related to API-specific permissions or missing system user mappings. Here are a few things you can check:

    1. Check ACLs for API Requests
         - Ensure the user explicitly has jcr:write and replicate permissions on /content/dam/data for API access.
         - Check permissions via Useradmin Console (/useradmin) or CRXDE (/crx/de).
          - Verify that the group’s permissions propagate to the API requests.

    2. Validate API-Specific User Permissions

        - API calls might be executed under a different context than UI interactions.
        - Check if the service user mappings (used by Assets API) have the necessary access.
        - Try assigning the user to the dam-users or dam-api-access groups and test again.

    3. Check for Overlays or Custom Code Restrictions

        - Custom Sling filters, servlets, or workflows could be interfering with API write operations.
        - Look for any custom error handling that could prevent resourceResolver.commit().|

    4. Compare Configuration Between Environments

    Since this works in Development & Staging, compare OSGi configurations, ACLs, and user permissions in Production.
    Specifically, check:

          - Apache Sling Resource Resolver Factory (/system/console/configMgr)
          - Granite Operations Settings
          - Any API request restrictions (Apache Sling Authentication Service)

    5. Try Debugging with a Different User

        - If possible, test the API using an admin user (to rule out permission issues).
        - If it works, then it’s definitely a permission issue with the original user.

    If the issue still persists, enabling debug logging for org.apache.sling.jcr.resource might give more insight into why commit() fails.

    Best Regards,
    Amit Vishwakarma

      J
      jlanssie-tmeAuthor
      Level 2
      March 21, 2025

      As it turns out, it is also failing when we give our user "Administrators" permissions. This issue is being followed up at Adobe Case #E-001575531.

      Uppari_Ramesh
      Uppari_Ramesh
      Level 5
      March 16, 2025

      Hi @jlanssie-tme , before saving the changes can you try refreshing the session and also check if node is not in checked in state.

        J
        jlanssie-tmeAuthorAccepted solution
        Level 2
        April 17, 2025

        As it turned out, the Granite Assets REST API bundle was not active. There was a dependency issue on a certain Adobe-bundle.

          Terms & ConditionsAccessibility statement

          Loading footer...