We are seeing an issue in our production environment where links are being incorrectly substituted. Our author (and our code) only select resources from the JCR to build links. AFAIK, the links should be relative but we are actually seeing host names in the links.
For instance, if an author selects the resource /content/domain_com/en-us/locator, we expect to see the HTML:
<a class="block-level list-item-link" href="https://forums.adobe.com/content/domain_com/en-us/locator.html" title="Locations" target="_self">Locations</a>
And in most environments, we do see that, but intermittently, we see this:
<a class="block-level list-item-link" href="https://test-host.domain.com:4503/content/domain_com/en-us/locator.html" title="Locations" target="_self">Locations</a>
Ironically, we only see that in production.
We do have some sling redirects set up, but I'm not sure if they are the cause. My understanding is that they will only change relative paths-not add on a hostname.
The relevant sling redirect could be this:
"jcr:created": "Fri May 18 2018 15:29:02 GMT-0500",
But I'm not really sure.
FYI, we are running 6.3 SP1.
Any help would be appreciated.
Thanks for your prompt reply JaideepBrar. I'll try to get the logging added in production. In the meantime, I poked around a bit and found this:
There are five sections:
Configuration, Configuration Test, Resolver Map Entries, and Mapping Map Entries.
Resolver Map Entries look reasonable for the most part. They are things like:
Fine. No problem. Then I look farther down at Mapping Map Entries. And I see:
I can send a screenshot of the actual jcrresolver console, but I can't post it on the open web.
Here's the thing. We don't want any external redirects. We create all of our sling redirects as above (using sling:internalRedirect). Apparently it does both? Not sure how we can create a redirect that doesn't create a mapping both directions.
Hi Hermant, we looked through that. We were able to disable many of the external redirects by changing them to be regexps, but we are still fiddling with it. Is there a way to turn off external redirects entirely?
Using the same mechanism for both direct and reverse mappings without an explicit switch is a thoroughly brain damaged design.
If the same content tree is mapped to multiple domains via sling mappings as in your case, it could very well lead to the issue as you have identified in resolver.
For turning off external redirects, you need to fix your sling mappings to remove "sling:redirect" properties appropriately per use case.
So after discussing with my team, we do actually need reverse mappings BUT we don't want external redirects. I.e. we only ever want absolute URLs used if the links in the content tree are absolute URLs. If there are relative URLs in the content, we wanted them to be relative (but mapped on a path basis).
But every example that I have seen has absolute URLs in the replacement column. Probably because there's always a host in the /etc/map tree. I.e. it's always something like /etc/map/http/hostname. Is there a way to create a mapping that isn't host specific?
Is there a way to do this?
Yes, you can create mappings that aren't host specific. A solution would be to use Sling Resource Resolver Factory - URL Mappings in /system/console/configMgr only for inbound urls but not for outbound urls
Do you share the root path with multiple domains that controlled via sling mappings? If yes, then you may modify your relative urls to keep the root rather than real-relative urls - that would prevent the domain-substitution to happen on publish servers.
You may share a sample sling:mapping rule structure if none of the above mentioned works out.
gauravb10066713 maybe you could give me an example of how I can do this?
I need to map /content/domain_com/en-us to /en-us. So for example, http://domain.com/en-us should be redirected to directed to the resource /content/domain_com/en-us BUT all links that are to /content/domain_com/en-us should be generated as /en-us regardless of the hostname in the request.
How can I do that?
As mentioned above in the second solution, use '/domain_com/en-us/...' as the relative url in your jsp/htl script rather than '/en_us/...', that should fix your issue.
You do realize that I'm not hardcoding links in jsp or htl, right? Are you seriously suggesting that I write something myself to do path rewriting myself? If so, then why am I paying for an AEM license?
The path doesn't need to be hardcoded and instead it can be dynamic or a configuration or other ways.
Per my knowledge, for this use case, Sling is behaving as it should to resolve the urls based on custom configurations. It all depends on ranking/execution of services.
I would let other folks to recommend solution(s).