Apply JCR Mappings to Asset Details URLs

[DigiLiviu]

It seems as though the logic to build a result card's URL simply involves pulling the raw value of the Asset Details page from the Config:

From ConfigImpl.java

public String getAssetDetailsPath() {
    return properties.get(PN_DEFAULT_ASSET_DETAILS_PATH, rootPath + "/details");
}

public String getAssetDetailsUrl() {
    return getAssetDetailsPath() + ".html";
}

This doesn't put it through any of Sling's Resource Resolver Mapping mechanisms. I know that with the more recent AEM Core Components, the LinkManager is often used to take such a resource path and transform it into a link that takes these mappings into account. Would it be possible to refactor some of those Config methods to use it?

We use the LinkManager throughout our site and therefore, the /content/<client>/us/en urls are obfuscated. Our results cards urls however, have the whole path.

Is there any other way to obfuscate both the URLs of the detail card page and those of the assets in the details suffix? We would like a url that originally looks like /content/client/us/en/resources/details.html/content/dam/client/documents/asset.pdf to be transformed into resources/details.html/asset.pdf. Ideally, we'd also be removing the .html after the details page name in the url.

[davidjgonzalez]

Doesnt the link rewriter transformer run this through rr.map(..) which i assume would do this on the HTL level?

Im not familiar with LinkManager, can you point me to the javadocs?

[DigiLiviu]

@davidjgonzalez I'm not sure if the link rewriter just picks all urls and transforms them, maybe it did in a previous version...? I remember when we were setting up our site, none of our links were obfuscated until we used the LinkManager to generate the urls in our models and return them to the HTL scripts already processed.

Have you seen links in the Results component on a publish site get obfuscated without first processing them on the backend? Maybe we haven't turned something on?

The LinkManager API is at https://javadoc.io/static/com.adobe.cq/core.wcm.components.core/2.23.4/com/adobe/cq/wcm/core/components/commons/link/LinkManager.html

You can see an example of it being used in the core components on the button: https://github.com/adobe/aem-core-wcm-components/blob/3524e33424bf6831faca014284c5bad803d3744d/bundles/core/src/main/java/com/adobe/cq/wcm/core/components/internal/models/v2/ButtonImpl.java#L46

It's passing in a resource object in that example but it can also take a url path, which is what I think we'd need: https://javadoc.io/static/com.adobe.cq/core.wcm.components.core/2.23.4/com/adobe/cq/wcm/core/components/commons/link/LinkManager.html#get-java.lang.String-

[DigiLiviu]

@davidjgonzalez let me actually get back to you on this one, it might just be that the more complex urls are confusing our mappings

[davidjgonzalez]

Any luck? Can we close this issue?

[davidjgonzalez]

Please re-open if this is still an issue; that said - highly recommend not to re-write URLs for ASC as it has not been tested with this.

[DigiLiviu]

@davidjgonzalez I have been unable to re-write URLs using the JCR Mapping mechanism for URLs with extensions in the suffix. Obviously, that's common in ASC since the urls have the file name, extension and all, in the suffix. If I rename the file in the DAM to not have an extension, rewriting works. I wonder if there are limitations on JCR Mappings for extensions in the suffix...

[davidjgonzalez]

Ahh - yes, it will not rewrite suffixes since it (Sling) doesnt know if a suffix is a resource path or just some other arbitrary data.

[DigiLiviu]

@davidjgonzalez so what is the recommended way to obfuscate the /content/dam/<company-name> path of the dam in the details page urls that look like <path-to-details-page>/content/dam/<company-name>/<path-to-asset> ?

[DigiLiviu]

@davidjgonzalez just to circle back on this, we worked with Adobe support and they recommended a link transformer to get it done. Not as smooth as JCR Mappings but it got the job done.