Content Sync - Authentication not working while trying to sync content between local and remote instance

[sanjana287]

Required Information

• [x] AEM Version, including Service Packs, Cumulative Fix Packs, etc: 6.5.15, sp15
• [x] ACS AEM Commons Version: 6.3.2
• [x] Reproducible on Latest? yes/no - yes

Expected Behavior

Content Sync is able to successfully sync resources between 2 local instances, however not able to sync content between a local and a remote instance

Actual Behavior

When trying to sync content between my local instance and a remote client, somehow it is giving me a 404 not found error. This error is not because there is no servlet/content present on the target instance, both instances have acs commons and servlet is also present. On trying to debug, I observed that the request going to the remote client is not reaching with the correct credentials - I am using admin credentials for my remote client, but the request hitting it is null. As a test, I allowed the anonymous access to content on my remote client, and that worked, pointing that there is some issue with the credentials it is receiving. I am using the latest version of acs-aem commons(6.3.2), I am not sure if I am missing out any step, would appreciate some help on this, I have attached a file with stack trace.

Steps to Reproduce

Open Content Sync on local instance and enter the source env as some remote client Try syncing the request ContentSyncError.txt

Links

Links to related assets, e.g. content packages containing test components

[YegorKozlov]

Do you have the latest ACS Commons on the source and the target? Are the credentials correct? Could you check with Curl or Postman, like

curl -u username:password https://remote-aem-instance/apps/acs-commons/content/contentsync/jcr:content/sync.catalog.json?root=/content/my-site

{"resources":[]}

[sanjana287]

Hi @YegorKozlov ,

Yes, I tried both curl and Postman with same admin credentials and it works that way, attaching screenshot.

Additionally, I am using ACS version 6.3.2 on both source and target instances.

[sanjana287]

[sanjana287]

Hi @YegorKozlov ,

Any update on the issue?

[YegorKozlov]

@sanjana287 I see nothing wrong with Content Sync, tried with AEM 6.5.20 and AEM as aem-sdk-quickstart-2023.12.14697.20231215T125030Z-231200 and everything worked fine.

Are you connecting to an on-prem instance or in AMS ? Does it fail to connect to that particular instance only, or to all AEM instances? Can you try Content Sync with another AEM instance running on your local?

[sanjana287]

Hi @YegorKozlov ,

I am using an on-prem AEM instance. Also as I mentioned earlier, content sync is working between 2 local instances. It is only when we have one local and one remote client (on prem AEM instance) , it is failing.

In addition, this is the case with all the remote clients I am trying to connect.

[YegorKozlov]

@sanjana287 could you create a trace logger on org.apache.http , try Content Sync with your remote instance and upload the log file? You can obfuscate the urls .

[sanjana287]

Hi @YegorKozlov ,

I created trace loggers on both local and remote, and hit from local to remote -> I got logs in local and I am attaching that (please note - I have replaced the urls with remote_instance and remote_ip in original logs). As for the remote instance, there was no log printed, I am attaching a screenshot of the request logger from remote instance where I see the request coming from "null". The content sync error log remains the same as I have attached in the original comment.

Also, I might have missed this in your previous comments so just asking again for clarity, are you not able to reproduce the error using a remote client too? (this works for me too in local)

Please let me know if more information is required, thank you for looking into this, appreciate your help.

Thanks. apachehttp.txt

[YegorKozlov]

@sanjana287 So far I couldn't reproduce it . I tried it with a local instance, a remote on-prem AEM 6.5.20, remote 6.5.20 running in AMS, and aem-sdk-2023.12.14697.20231215T125030Z-231200. It worked for me in all the cases.

[sanjana287]

@YegorKozlov anything you could spot with the logs and details I provided?

[YegorKozlov]

@sanjana287

Is your AEM behind Dispatcher? Do you have any security filters that could reject the requests from Content Sync, or maybe, filters by user-agent?

Are these filters from your code? Could you disable them and give a try?

com.project.module.preview.impl.SampleThreadLocalFilter
com.project.module.core.filters.LoggingFilter
com.project.module.core.filters.AssetsAddRenditionServletFilter
com.project.module.core.filters.OnOffThreadLocalFilter
com.project.module.core.filters.StoriesPageRenderingServletFilter
com.project.module.core.filters.ViewMoreFilter

Below is what I see on my local and this is the expected behavior:

# Content Sync starts the request. I see this line both in my local your logs
14.03.2024 10:39:20.932 *DEBUG* [[0:0:0:0:0:0:0:1] [1710409160166] POST /apps/acs-commons/content/contentsync/_jcr_content/sync.html HTTP/1.1] org.apache.http.wire http-outgoing-15966 >> "GET /apps/acs-commons/content/contentsync/jcr:content/sync.catalog.json?root=%2Fcontent%2Fmy-site&strategy=com.adobe.acs.commons.contentsync.impl.LastModifiedStrategy HTTP/1.1[\r][\n]"

# I don't the see lines below in your logs. Somehow your AEM does not request authentication.
# remote server returns 401 Unauthorized
14.03.2024 10:39:21.099 *DEBUG* [[0:0:0:0:0:0:0:1] [1710409160166] POST /apps/acs-commons/content/contentsync/_jcr_content/sync.html HTTP/1.1] org.apache.http.wire http-outgoing-15966 << "HTTP/1.1 401 Unauthorized[\r][\n]"

# Content Sync sends Authorization: Basic
14.03.2024 10:39:21.115 *DEBUG* [[0:0:0:0:0:0:0:1] [1710409160166] POST /apps/acs-commons/content/contentsync/_jcr_content/sync.html HTTP/1.1] org.apache.http.impl.auth.HttpAuthenticator my-host.adobecqms.net:443 requested authentication
14.03.2024 10:39:21.128 *DEBUG* [[0:0:0:0:0:0:0:1] [1710409160166] POST /apps/acs-commons/content/contentsync/_jcr_content/sync.html HTTP/1.1] org.apache.http.headers http-outgoing-15966 >> Authorization: Basic *******************

# finally get "HTTP/1.1 200 
14.03.2024 10:39:21.288 *DEBUG* [[0:0:0:0:0:0:0:1] [1710409160166] POST /apps/acs-commons/content/contentsync/_jcr_content/sync.html HTTP/1.1] org.apache.http.wire http-outgoing-15966 << "HTTP/1.1 200 OK[\r][\n]"

In your case I don't see the "Authorization: Basic" at all. Somehow the remote instance returns 404 without authorization:

14.03.2024 12:09:28.136 *DEBUG* [[0:0:0:0:0:0:0:1] [1710398366823] POST /apps/acs-commons/content/contentsync/_jcr_content/sync.html HTTP/1.1] org.apache.http.wire http-outgoing-384 << "HTTP/1.1 404 Not Found[\r][\n]"

Also, could you try Postman and curl with "User-Agent: Apache-HttpClient/4.5.13 (Java/11.0.4)"? Just to rule out user-agent.

[davidjgonzalez]

You should be able to verify that credentials are attached to the outgoing request. You should be able to do this by using crx-quickstart/opt/helpers/proxy.jar .

$ sudo java -jar proxy-2.1.jar 4567:remote.aem.com:80

(first port can be some unused local port, the host and last port are whatever your remote AEM env listens on)

Set your local content sync to point to http://localhost:4567 and trigger it -- the proxy jar log in detail the outgoing request and response. Check to make sure the outgoing request has the credentials.

If it does, then its something between your local AEM and Content Sync code running on the remote AEM (CDN/Dispatcher/Servlet Filter) but that something isn't ACS Commons.

If you dont see the credentials in the proxy jar's output on the request, then it would indicate there could be an issue with Content Sync in ACS Commons and your credentials arent being added to the outgoing request (but this seams unlikely since it works against other local envs)

[sanjana287]

Hi @davidjgonzalez and @YegorKozlov ,

Thank you for helping out with the debugging. The issue was with the Apache Sling Authentication Service configuration on the remote client, which is currently binded to one of our custom implementations. By using the proxy.jar, I was able to identify that the basic auth was not initiating only from the remote client. Also thanks to @YegorKozlov for pointing out the same.

We are good to close this, Thank you!