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

18 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

18 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

28 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

28 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

17-03-2021

This doesn't change my major concern...that the system is NON-secure by default [..] In the past, the default dispatcher configuration was that any query parameter circumvents the dispatcher cache.

 

Just to clarify: the default configuration — included when a project is bootstrapped with the AEM archetype — has not changed (ignoreUrlParams remains commented out). We acknowledge that the creation and maintenance of the allow list rules (ignoreUrlParams, Sling selectors, and Sling suffixes) is going to take additional effort, likely beyond what dev teams are doing today. These rules, as the name of the tool suggests, are intended to optimize your use of the dispatcher.

 

As we were building the tool we also acknowledged that not all of these rules are going to work for everyone, so we created an extension mechanism that can be used to fine tune the rule set (or replace it altogether) depending on your specific needs. To show how this works, I’ve added a branch to a sample project which disables the ignoreUrlParams rule via the rule extension mechanism: https://github.com/blefebvre/aem-dot-example-project/compare/disable-ignore-url-params-rule

 

This extension mechanism, along with other features of the DOT, is covered in a lab-format exercise we put together to get folks comfortable with the tool: https://github.com/adobe/aem-dispatcher-experiments/tree/main/experiments/optimizer

 

But the reality of AEM development is that it's far more onerous for local developers to run a full author, publish, dispatcher stack locally, keep content in sync across them, and deploy code to all environments for all changes as they work. [..] there's just no convincing developers to run a full stack.

 

We’re open to ideas on how we can make this easier. Currently, the archetype supports the `mvn install -PautoInstallSinglePackage -PautoInstallSinglePackagePublish` flags which will deploy packages to both author and publish instances in a single command. Would an official Docker container facilitate running a local dispatcher? Are there other ways we can make the use of the dispatcher easier and more commonplace for day-to-day development?

 

consider a service that confirms a user signup with an emailed link that includes a UUID pointing to the registration

 

An additional thought on your example: if this service were implemented as a servlet (such as this Create Servlet example, although using "sling.servlet.methods=get" instead), it's worth noting that responses to requests without extensions will still not be cached by the dispatcher - regardless of the configuration of the ignoreUrlParams rule.