All,
I have internal redirects working as intended for our UAT, Stage, and Production sites when using a URL capture under /etc/maps.publish.(dev/stage/prod)/https i.e.
<preprod.dc.example.cloud
jcr:primaryType="sling:Mapping"
sling:internalRedirect="[/,/content/pathA/pathB]">
</preprod.dc.example.cloud>
<example.com
jcr:primaryType="sling:Mapping"
sling:internalRedirect="[/,/content/pathA/pathB]">
</example.com>
<www.example.com
jcr:primaryType="sling:Mapping"
sling:internalRedirect="[/,/content/pathA/pathB]">
</www.example.com>
We are using Adobe Cloud Manager and the Adobe support team is attempting to access / login into our Production Publish environments using the IP address of the box. Our etc mappings seem to be blocking logging in via the IP address.
My question is, how can I default accessing the box via an IP address to not use any of these mappings? Can I add an IP address mapping to allow default pathing behavior? Thanks for your support.
Solved! Go to Solution.
Views
Replies
Total Likes
These mappings are configured to the hostnames:
* preprod.dc.example.cloud
* sample.com
but not for requests using an IP address (these do not contain a "host" header). Also these mappings just configure the redirects for the "/" resource.
I don't see why it should not be possible to login into these systems, when you have the IP address and the link to the login-page.
These mappings are configured to the hostnames:
* preprod.dc.example.cloud
* sample.com
but not for requests using an IP address (these do not contain a "host" header). Also these mappings just configure the redirects for the "/" resource.
I don't see why it should not be possible to login into these systems, when you have the IP address and the link to the login-page.
Thanks for the reply Jörg. I was under the impression that the `/` need to be in the sling:internalRedirects to pick up paths such as /apps, /etc, /libs and so on. If every path is prefixed with `/content/pathA/pathB` then I would be incorrectly rendering the previously mentioned paths.
This does not mean that every path is "prefixed" with the provided value. This configuration just influences the map() and resolve() methods of the ResourceResolver, and these are normally just called when resolving a URL to a repository path or mapping a repository path to a URL. For example ResourceResolver.get() does not use it at all.