Redirect Manager Tool - Enhancement to ignore selectors in the url

[thcharan]

Required Information

• AEM Version, including Service Packs, Cumulative Fix Packs, etc: ALL Versions_
• ACS AEM Commons Version: ALL VERSIONS_
• Reproducible on Latest? yes/no YES

Expected Behavior

We often run in to business cases - where we want to rewrite url's based on specfic user profile cookies with "Selectors" .

for example -
when user requests a url /content/a/b/c.html , it needs to rewritten to
/content/a/b/c.xyz.html ,
/content/a/b/c.qrt.html ,
/content/a/b/c.rtp.html

We want to have ability where ACS redirect tool ignores the selectors. Preferably define it as OSGI config Global flag. "ignoreSelectors"

So, the expected behavior of this flag be :
if there is redirect entry with source as /content/a/b/c.html to redirect to /content/d/e/f.html is defined in the redirect tool.
when a incoming request is any of the below ->
/content/a/b/c.xyz.html ,
/content/a/b/c.qrt.html ,
/content/a/b/c.rtp.html

the redirect tool will ignore the selectors and match the redirect entry and will honor the redirect to /content/d/e/f.html

[thcharan]

@YegorKozlov - thoughts?

[tomasz-niedzwiedz-wttech]

Hi, we could use this feature as well. Right now it's difficult to use this tool when there's a considerable amount of selector-based logic implemented on a given AEM-based platform.
Maybe a blanket ignore selectors setting, maybe an allow-list (literal or glob-based) for selectors to be ignored.

[YegorKozlov]

@thcharan, @tomasz-niedzwiedz-wttech You can use regex to match selectors,. e.g.

/content/we-retail/en/terms(.one)?(.two)?(.three)?

# will match
/content/we-retail/en/terms.one.html
/content/we-retail/en/terms.two.html
/content/we-retail/en/terms.one.two.three.html

so instead of ignoring selectors you'd specify which ones you need to match.

Will it work for you?

[thcharan]

@YegorKozlov -
@tomasz-niedzwiedz-wttech

Thanks for the response.

Couple of reasons why i have different point of view on this,

1. The biggest advantage of Redirect tool is have business users self manage the redirects, they do not know any of these selectors and regexp. I do not think - having that burden on Marketing users of this tool to remember these intricasies is a good idea.

I would still lean on either
"IgnoreSelectors" option as global osgi setting as boolean or allow-list (literal or glob-based)
OR
even better Context Aware Confg Setting per site as the most preferable approach that works seemlessly across implementations on multi tenant platforms with many sites hosted.. (flag or or allow-list like literal or glob-based)

thoughts?

[tomasz-niedzwiedz-wttech]

I think there's merit in @thcharan's proposal. If this tool is given to super users to self-manage the redirects, requiring them to know and update the glob patters to include all selectors used internally by the given AEM implementation across multiple redirects would be unreasonable.

One could try to work around this by crafting a regex that matches a whole selector string, assuming there are no . characters in the URL itself

/content/we-retail/en/terms(\..+)*\.html

but it seems error-prone and a potential performance problem if the number of such entries is excessive. I can see how this could backfire even if such rules were created by developers and admins only.

[thcharan]

@YegorKozlov - Any thought on 'Context Aware Config (Glob based)' approach for this that may land us with a more scalable solution.

[YegorKozlov]

@thcharan @tomasz-niedzwiedz-wttech I'm fine add this feature, just wanted to understand why you needed it and why regex wouldn't work for you.

IMO it should be a runtime, user-managed setting, managed at either on redirect level, or on the context level, e.g. there can be cases where selectors would be off for one content tree, and be on for others.

[thcharan]

@YegorKozlov / @tomasz-niedzwiedz-wttech

"there can be cases where selectors would be off for one content tree, and be on for others" -- this is correct in most multi-tenant /multi sites hosted aem platforms. I agree on this use case.

"managed at either on redirect level, or on the context level" -- Agreed, how about we approach like below if we go with your approach ?

In the redirect entry dialog -> user can be presented with both the below two fields

"Accept Any Selectors" -> boolean checkbox field -> default selection state ('true')
"Accept Specific Selectors" -> user can configure specific selectors list that applies. (whatever format of input this can be)

In the Site Conf Level -> There will be one field -> "Accept Specific Selectors"

What's defined at a redirect entry level always takes precedence, this means the below -

usecase-1) At redirect entry level, accept-any-selectors-checkbox = true and 'accept-specific-selectors' = empty , the end behavior would be that the redirect will match url with any selectors.

usecase-2) At redirect entry level, accept-any-selectors-checkbox = false and 'accept-specific-selectors' = 'non-empty' , the end behavior would be that the redirect will honor the applicable selectors defined here.

usecase-3) At redirect entry level, accept-any-selectors-checkbox = false and 'accept-specific-selectors' = 'empty' , it will fallback to site level conf rule defined with applicable selectors.

usecase-4) At redirect entry level, accept-any-selectors-checkbox = false and 'accept-specific-selectors' = 'empty' and sitelevel-conf for selectors is empty --> then it should behave the way it is functioning today with the current version.

[YegorKozlov]

@thcharan I'd rather not complicate this feature. Your point is that using regex is too complicated for non-tech users. IMO overloading the dialog with too many options will result in the same problem, i.e. it will confuse users instead of helping them. IMO if we support this feature, it would be a simple checkbox at the site conf level.

[thcharan]

@YegorKozlov / @tomasz-niedzwiedz-wttech -
"simple checkbox at the site conf level" - Agreed, let's move forward with that simplistic approach.

[YegorKozlov]

@thcharan @tomasz-niedzwiedz-wttech here you go
The context configuration offers a new option to ignore selectors for the content tree:

[thcharan]

@YegorKozlov - Looks Great!

[thcharan]

@YegorKozlov -- seems like this is not working in the aem-cloud-service envts... it works for you ?

[YegorKozlov]

@thcharan it worked for me in AMS and on-prem 6.5.18. please give me a few days to check in the cloud setup.

[thcharan]

@YegorKozlov - So, My Team investigated this issue by debugging runtime on a AEM Cloud SDK on localhost. Below is our findings. It's a major issue.

In a nutshell, None of the "Context Aware Cfg Options" is working in AEM-Cloud. So technically this is not just impacting "Ignore Selectors" option, but impacts all the CA options. Findings below

1. com.adobe.acs.commons.redirects.filter.RedirectFilter.java is having this below line of code,

@reference
ConfigurationResourceResolver configResolver;

2. The configResolver is injected with a valid configResolver object --- no issues with that. However keep in mind -- this configResolver is still operating with a anonymous user context ( NOT AS A SERVICE USER CONTEXT WITH ELEVATED PERMISSIONS).

3. when code flow control reaches the match() method,

we have this line, which works fine, returning the path of an valid context aware path applicable to that site.
String configPath = configResource.getPath();

The code fails here -- returns an empty valuemap (size=0) since the anonymous user context didn't have permissions on that node.
ValueMap properties = configResource.getValueMap();

On local, when we are logged in as admin on that browser session -- the same code worked,.

Solution -
use this to get the conf resource path, String configPath = configResource.getPath();
once you have above context aware conf path, use resourceResolver of the service user to get the valuemap on that "redirects" node..to read the properties.

Note - Anonymous is part of everyone group... the Out of the box permissions in the below screenshot should make it clear of the issue described above.

[thcharan]

Since this issue pre-existed before IgnoreSelectors option was introduced, i created a new issue for this --

#3284

we can communicate on that issue thread.