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).
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?
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
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.