Query: Is Vanity Path Rewrite Mapper aem cloud compatible

[SmritiMahto]

Required Information

[ ] ACS AEM Commons Version: 5.0.6 Hi Team We are using acs aem commons feature of Vanity Path Rewrite Mapper for vanity url implementation in out project - AEMaaCS. Can you please let us know if this feature is aem cloud compatible? feature used: https://adobe-consulting-services.github.io/acs-aem-commons/features/vanity-path-rewrite-mapper/index.html

Thanks, Smriti Mahto

[davidjgonzalez]

@SmritiMahto

As far as I know, it is - is there a reason you believe it is not?

[davidjgonzalez]

Closing for now. If you have specific reason you believe its not, please re-open.

[mitcoding]

@davidjgonzalez I have the same question. As this doesn't seem to work once deployed to Cloud on the publish instance. it seems to work locally and cloud author instances.

I used this method to enable the feature: https://adobe-consulting-services.github.io/acs-aem-commons/features/vanity-path-rewrite-mapper/index.html#via-acs-aem-commons-error-handler-v3100

Are there any other special Dispatcher configuration I need to do as well that the article failed to mention?

com.adobe.acs.commons.errorpagehandler.impl.ErrorPageHandlerImpl.cfg.json:

{
    "enabled": true,
    "cache.serve-authenticated": false,
    "cache.ttl": 300,
    "error-page.system-path": "/content/<site_name>/us/en/errors",
    "error-images.enabled": false,
    "error-images.path": "",
    "vanity.dispatch.enabled": true
}

• I inserted in the config comment to not give away actual public site info. with that said the custom error pages from acs-commons does work, but the vanity.dispatch.enabled is the part that doesn't work on cloud publish.

[mitcoding]

looking into the code further it looks like line 83 of VanityURLServiceImpl.java is where everything gets screwed up on Cloud (final String pathScope = StringUtils.removeEnd(requestURI, candidateVanity)).

On local candidateVanity will always be something like /vanity.html and requestURI is something like /content/us/en/vanity.html.

which means pathScope resolves to "/content/us/en"

On Cloud candidateVanity will always be something like https://www.domain.com/vanity.html and requestURI is something like /content/us/en/vanity.html.

which means pathScope resolves to "/content/us/en/vanity.html" because candidateVanity string doesn't match the ending of requestURI due to it including the scheme, host name and port. which is having the effect of causing isVanityPath to always return false even it is a valid vanity path.

[mitcoding]

created a pull request with a potential fix: https://github.com/Adobe-Consulting-Services/acs-aem-commons/pull/2998