Adobe Experience Manager Sites & More

Kamal_Kishor · 12/3/25

We are using session based check to determine if a request should have access to a resource. This is causing massive performance hit on our instance when the load becomes slightly higher (it is relative as we have many sites hosted and have adequate infra for on-prem instance).

We are referring - https://experienceleague.adobe.com/en/docs/experience-manager-dispatcher/using/configuring/permissio...

Performance hit seems to be coming when requests are higher to check the permission and we are using session to check the permission -

session.checkPermission(uri, Session.ACTION_READ);

Is there a better alternative to this approach without breaking it functionally?

thanks.

Srinath_A · 12/3/25

Background Job (Scheduler or Event-Driven):
- Periodically or upon ACL/user changes, calculates which URIs each user (or group) can access.
- Stores this permission map under "/conf/myapp/permissions/<userId>" as JCR nodes/properties.
AuthChecker Servlet:
- On HEAD requests (from Dispatcher), reads the user’s precomputed allowed URIs from JCR for the requested URI.
- Approves access if allowed, denies otherwise.
Fallback:
- If no precomputed data exists, optionally fallback to live session.checkPermission to avoid lockout, and rebuild permissions as necessary.

Kamal_Kishor · 12/3/25

@Srinath_A - Thanks for your response.
We have pages which may have CUGs applied to them and we have multiple sites (100s at-least) and there could be different scenarios with CUGs applied to them.

I don't see the approach you have suggested to work very well for us.

thanks.

giuseppebaglio · 12/4/25

hi @Kamal_Kishor,

The dispatcher only calls your servlet for paths matching the auth_checker filter configuration, you could minimize unnecessary permission checks and restrict its usage to onlu htmls:

/auth_checker {
    /url "/bin/permissioncheck"
    /filter {
        /0000 { /glob "*" /type "deny" }
        # Only check items of interest
        /0001 { /glob "/content/mysite/secure/*.html" /type "allow" }
    }
}

I think this is the best solution since the servlet code is shrinked to very bare minimum of code leveraging already the fastest API possible.

Don't waste time rewriting the servlet, imho you should focus on reducing the number of permission checks via dispatcher filters and start Profiling analysis to find what the actual bottleneck could be.

Kamal_Kishor · 12/4/25

@giuseppebaglio - thanks for your response.

We are already filtering the requests to bare minimum.

We have use-cases where some set of pages would be requested about 10k times in span of few minutes. These are all legitimate requests and need permission check before being served from cache.

For that reason, we are hoping if there is a way to improve the permission check servlet.

thanks.