Expand my Community achievements bar.

SOLVED

Selector value issue in getSelectors method

Avatar

Level 2
We are using following URLs with selectors, but due to some reason its not taking “amp” characters in “slingRequest.getRequestPathInfo().getSelectors();” method. /content/site/en/home.username-camp.html /content/site/en/home.username2-lastnameamp.html /content/site/en/home.username3-lastampname.html But I am getting below values for selector 1 by using “slingRequest.getRequestPathInfo().getSelectors();” method in my code. username-c username2-lastname username3-lastname Please note we have tested in lower environments its working as expected, its happening in PROD environment, kindly help me to resolve this issue.
1 Accepted Solution

Avatar

Correct answer by
Employee Advisor

Hi @karthik-elumalai!

 

The behavior sounds a bit strange, especially since you are reporting that everything works as expected on lower environments. It's a bit hard to give detailed advice with the amount of information provided.

 

My general advice in this kind of scenario is:

  • Determine which component in the request stack is removing the substring in question.
  • Does this happen on author and publish?
  • Does this happen when accessing the instance directly vs. going through dispatcher, load balancer or other components involved?
  • What URL are you seeing in the request and access logs for the incoming requests?
  • Is the substring still present or has it been removed somewhere before even hitting AEM (maybe through rewriting/redirection in the webserver, a WAF or some other component)?
  • What is the full request URL in the class that is handling these requests and tries to extract the selectors? Is the substring still present?
  • Check the filter chain of the incoming request to see if something could potentially manipulate the URL and/or selectors.

Another approach would be to search for differences between your production setup (where the issue occurs) and a lower environment (where everything works as expected). It's always recommended to have some kind of pre-prod or staging environment that is very similar (if not equal) to the production setup to minimize differences and allow for easier issue reproduction and analysis.

 

Potential candidates causing the outlined issue that I could think of:

  • URL rewriting on webserver level (cutting out the substring)
  • Some kind of WAF that assumes the "amp" is malicious because it may reflect a HTML encoded ampersand ("&") and therefore filters it
  • Some filter within AEM that manipulates the URL and/or certain selectors

 

Hope that helps!

View solution in original post

5 Replies

Avatar

Community Advisor

can you check if you have any rewrite rules for amp



Arun Patidar

Avatar

Level 2
Hi Thanks for your response. there is no rewrite rules involved here.

Avatar

Correct answer by
Employee Advisor

Hi @karthik-elumalai!

 

The behavior sounds a bit strange, especially since you are reporting that everything works as expected on lower environments. It's a bit hard to give detailed advice with the amount of information provided.

 

My general advice in this kind of scenario is:

  • Determine which component in the request stack is removing the substring in question.
  • Does this happen on author and publish?
  • Does this happen when accessing the instance directly vs. going through dispatcher, load balancer or other components involved?
  • What URL are you seeing in the request and access logs for the incoming requests?
  • Is the substring still present or has it been removed somewhere before even hitting AEM (maybe through rewriting/redirection in the webserver, a WAF or some other component)?
  • What is the full request URL in the class that is handling these requests and tries to extract the selectors? Is the substring still present?
  • Check the filter chain of the incoming request to see if something could potentially manipulate the URL and/or selectors.

Another approach would be to search for differences between your production setup (where the issue occurs) and a lower environment (where everything works as expected). It's always recommended to have some kind of pre-prod or staging environment that is very similar (if not equal) to the production setup to minimize differences and allow for easier issue reproduction and analysis.

 

Potential candidates causing the outlined issue that I could think of:

  • URL rewriting on webserver level (cutting out the substring)
  • Some kind of WAF that assumes the "amp" is malicious because it may reflect a HTML encoded ampersand ("&") and therefore filters it
  • Some filter within AEM that manipulates the URL and/or certain selectors

 

Hope that helps!

Hi Thanks for your response. its happing in direct publisher (no dispatcher involved) and we are using this code in header component and HTTP URL looks fine.

Avatar

Employee Advisor

Hi @karthik-elumalai!

Good to know that you were able to cross out dispatcher and other infrastructure. So you have narrowed things down to the processing within AEM.

Have you tried debugging further into the code that is used here?

 

slingRequest.getRequestPathInfo().getSelectors();

 

Please refer to the Sling API and check the following:

  • Is the URL (including selectors) still correct on the slingRequest object?
  • Is the URL (including selectors) still correct on the RequestPathInfo object?
  • What does slingRequest.getRequestPathInfo().getSelectorString() return?

Have you already checked the filter chain for this?