I'm a DevOps engineer who has inherited an AEM 6.5 environment from an AEM developer who is no longer with the organization. The architecture consists of one dispatcher instance, one author instance, and one publisher instance. Currently the dispatcher is configured to fetch and cache content from the publisher instance and serve content to users from the cache.
It works for all pages except login pages when the user attempts to visit a restricted page (any page which require the user to log in). When visiting a restricted page via the dispatcher instance (https://example.com/site/restricted.html) it performs a 302 redirect to the login page on the publisher instance (https://publish.example.com/site/login.html). This is the same behavior which occurs if a user visits the restricted page directly on the publisher instance (https://publish.example.com/site/restricted.html), but it is not the desired behavior for when accessing the site via the dispatcher instance.
I am trying to make it so that when visiting restricted pages through the dispatcher instance that the user is brought to the login page through the dispatcher (https://example.com/site/login.html), not redirected to the publisher instance. The user should not see publish
appear in the URL at any time, nor should the existence of the publisher instance ever be made visible to a site visitor.
I've been unable to find where this redirect is defined/configured. Here is a summary of my research so far:
I have reviewed all Apache configuration on the dispatcher instance in
httpd.conf
and allconf.d
files and there are no rewrite rules or redirects which seem to cause this behavior. There are no references to the publisher instance IP address, hostname, URL, or subdomain in any of the conf files orVirtualHost
blocks.I have reviewed all dispatcher configuration in the
mod_dispatcher.so
module'sdispatcher.conf
config file on the dispatcher instance and there doesn't seem to be anything related there either. The only reference to the publisher instance is in the/farms/renders
block indispatcher.any
.I’ve examined every configuration option listed in both the author and publisher instance configuration web consoles (https://publish.example.com/system/console/configMgr) which include any of these terms:
login
,redirect
,restricted
,authorization
, andauthentication
but could not find anything that seemed relevant.I’ve also searched in CRXDE Lite on both author and publish (https://publish.example.com/crx/de/index.jsp) for the same terms but didn't find anything relevant. I found the
login.html
page and it's child nodejcr:content
component but there's nothing about redirects in the properties.I've gone onto the publisher server instance and checked the contents of
/opt/aem/crx-quickstart/conf
. I seebundles.json
,cq.pid
,quickstart.properties
, andsling.properties
but none of them have any clues.I've found a file at
/opt/aem/crx-quickstart/launchpad/config/com/day/cq/auth/impl/LoginSelectorHandler.config
which contains this::org.apache.felix.configadmin.revision:=L"1" auth.loginselector.defaultloginpage="/libs/granite/core/content/login" auth.loginselector.mappings=[ \ "/libs/granite/core/content/login:/login", \ ]
but I'm not sure what that is referencing. There is no
/libs/granite/core/content
directory on the server.
Where else might this redirect behavior be defined?
/etc/map
on publish through crx/de (publish.example.com/crx/de/index.jsp), it probably has a sling mapping pointing to dispatcher url. --- although I would advise against changing anything here, unless you are sure what you are doing. – awd/system/console/configMgr
forApache Sling Resource Resolver Factory
and theDay CQ Link Externalizer
for possible mappings defined there as well. Also, I would not dismiss the scenario where this is happening in code and not by configuration. – ronnyfmDay CQ Link Externalizer
as a domain entry. Updating that entry to the dispatcher instance URL resolved my issue. Should you post this as answer so I can mark it as the correct answer? – Employee