Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
BedrockMission!

Learn More

View all

Sign in to view all badges

What do people think about the dispather recommendation to ignore all non-specified query parameters?

Avatar

Avatar
Validate 1
Level 2
Brett_Birschba1
Level 2

Likes

17 likes

Total Posts

20 posts

Correct Reply

0 solutions
Top badges earned
Validate 1
Give Back
Boost 5
Boost 3
Boost 10
View profile

Avatar
Validate 1
Level 2
Brett_Birschba1
Level 2

Likes

17 likes

Total Posts

20 posts

Correct Reply

0 solutions
Top badges earned
Validate 1
Give Back
Boost 5
Boost 3
Boost 10
View profile
Brett_Birschba1
Level 2

15-03-2021

In the past, the default dispatcher configuration was that any query parameter circumvents the dispatcher cache.  To combat that, developers could configure particular query parameters to be ignored (things like utm_source, etc).

 

Recently, Adobe is changed dispatcher recommendations to ignore ALL parameters by default, only breaking cache explicitly for known query parameters. See https://github.com/adobe/aem-dispatcher-optimizer-tool/blob/main/docs/Rules.md#dot---the-dispatcher-...

 

I'm not sure I like this.  Sure, it increases the default cache hit ratio, but that was something we already accomplish in the past by configuring query parameters to be ignored. My concerns with this change are:

  • It requires the dispatcher configs to be updated if a new query string is added to code, and that is not expected by most developers
  • It does not prevent DDOS attacks (which I've seen Adobe purport that it does) - it just reduces which query params can be used to attack
  • It opens the door (or at least seems to) to very serious security concerns

As a quick example for bullet #3, consider a service that confirms a user signup with an emailed link that includes a UUID pointing to the registration. The first person to click the link works fine. The second person to click the link ends up not only failing to complete registration, but the seeing whatever the cached result from user 1 may have been (which could include account information)


For bullet #1, yes devs can be trained and it's not that big a deal to update the dispatcher since the code sits in the same codebase, but I really am wary of any setup where security (bullet #3) is breached by default unless the developer does actually remember.

 

I think I'd be less concerned with this change if the dispatcher didn't pass through any ignored query parameters to the publish server. That way any functionality based on query parameter would fail for all users including the first user, making issues easier to catch in Staging.

 

Curious what others' thoughts are. Am I missing something?

aem dispatcher
View Entire Topic

Avatar

Avatar
Give Back
Employee
Bruce_Lefebvre
Employee

Likes

27 likes

Total Posts

62 posts

Correct Reply

28 solutions
Top badges earned
Give Back
Boost 5
Boost 3
Boost 25
Boost 10
View profile

Avatar
Give Back
Employee
Bruce_Lefebvre
Employee

Likes

27 likes

Total Posts

62 posts

Correct Reply

28 solutions
Top badges earned
Give Back
Boost 5
Boost 3
Boost 25
Boost 10
View profile
Bruce_Lefebvre
Employee

15-03-2021

Hi Brett,

 

Thanks for sharing these concerns - appreciate your perspective on this. We anticipated questions about this rule and created the first video in our DOT "rule explainer" series to go over our motivation for the ignoreUrlParams rule: https://youtu.be/jgs_0EitZGg 

 

Sure, it increases the default cache hit ratio, but that was something we already accomplish in the past by configuring query parameters to be ignored

 

In our experience we've found that unexpected/unforeseen query params often end up included on links to the public facing site. This can happen automatically with ad campaigns, or when links to the site are sent via an email system. If these links reach a large enough audience they can lead to a slower experience for the users of the links, and at worst (given enough volume) can consume resources on the publish tier.

 

It requires the dispatcher configs to be updated if a new query string is added to code, and that is not expected by most developers

 

If developers are not testing their code and components via a local dispatcher, and end users of the site can only access content via a dispatcher, are the developers really testing the site as it would be used in production? We know that the dispatcher configuration is often an afterthought, and understand that it adds an additional layer to a developers setup, but we do think that it's an important layer which is worthy of consideration throughout the development of the site. To help with this, we've written instructions as part of our lab-format AEM Dispatcher Experiments repo to help devs get a local dispatcher set up on both macOS and Windows:

- macOS: https://github.com/adobe/aem-dispatcher-experiments/blob/main/docs/Local-Dispatcher-macOS.md 
- Windows: https://github.com/adobe/aem-dispatcher-experiments/blob/main/docs/Local-Dispatcher-Windows.md 

 

It does not prevent DDOS attacks (which I've seen Adobe purport that it does) - it just reduces which query params can be used to attack

 

Agree 100% that it does not prevent DDOS. In our experience, it really just helps limit a form of self-inflicted DDOS, where often legitimate links to the site (as described above) can contain query params that count as cache misses.

 

It opens the door (or at least seems to) to very serious security concerns [...] The first person to click the link works fine. The second person to click the link ends up not only failing to complete registration, but the seeing whatever the cached result from user 1 may have been (which could include account information)

 

For content like this which should never be cached no matter what, the "Dispatcher: no-cache" header can be set on the response.