Expand my Community achievements bar.

Dive into Adobe Summit 2024! Explore curated list of AEM sessions & labs, register, connect with experts, ask questions, engage, and share insights. Don't miss the excitement.
SOLVED

Dispatcher Permission Sensitive Caching - example servlets buggy ?

Avatar

Level 2

Hi,

We're setting up permission sensitive caching with the dispatcher (version 4.1.7) and AEM 6.0. There are several examples of the servlet to use to do the actual permission check, but as far as I can see they all have the same issue. (After asking for clarification we have been directed by Adobe to use the example at http://docs.adobe.com/docs/en/dispatcher/permissions-cache.html.)

The underlying issue is that the dispatcher sends the full URI to the CQ instance for the permission check, as the docs say it does. For example, our access logs show

127.0.0.1 - subscriber 06/Feb/2015:17:09:18 +0000 "HEAD /bin/permissioncheck?uri=/content/geometrixx/en/secret/banking.html HTTP/1.0" 200 - "-" "ApacheBench/2.3"

In the example servlet in the link above the URI is checked by the JCR session, effectively 

session.checkPermission("/content/geometrixx/en/secret/banking.html", Session.ACTION_READ);

This will always throw an exception, as that path doesn't exist in the JCR - what does exist is the resource node at "/content/geometrixx/en/secret/banking".

I think the code should do this

Resource found = request.getResourceResolver().resolve(uri); if (found.getResourceType().equals(NonExistingResource.RESOURCE_TYPE_NON_EXISTING)) { // Hard to say of access is denied, or the resource genuinely doesn't exist. // Assume permission is denied. LOG.trace("Non existent resource returned"); response.setStatus(SlingHttpServletResponse.SC_FORBIDDEN); } else { LOG.trace("authchecker says OK"); response.setStatus(SlingHttpServletResponse.SC_OK); }

Note that I'm using the resolve(uri) method, and not the getResource(uri) method that other examples use, as that has the same flaw.

Is this correct ? Am I completely wrong ?

Thanks.

1 Accepted Solution

Avatar

Correct answer by
Employee Advisor

Hi,

I guess, you are doing at it correctly. If you get the extension attached to the query parameter "uri", you need to use "resolve", which is capable to deal with extensions.

I would assume, that this is a dispatcher related issue. Can you please raise a Daycare issue about this?

thanks,
Jörg

View solution in original post

4 Replies

Avatar

Correct answer by
Employee Advisor

Hi,

I guess, you are doing at it correctly. If you get the extension attached to the query parameter "uri", you need to use "resolve", which is capable to deal with extensions.

I would assume, that this is a dispatcher related issue. Can you please raise a Daycare issue about this?

thanks,
Jörg

Avatar

Level 2

Hi,

That's not the issue I'm facing, however the servlet code in that thread has the same issues as I outline above.