Debugging Dispatcher Authorization Issues

While working on client sites and delivering AEM training, occasionally the dispatcher would not be caching content as expected. For example, when setting up a default dispatcher and trying to cache Geometrixx Outdoors pages, I would get the following output in the log:request contains authorization cache-action for [/content/geometrixx-outdoors/en.html]: NONE

The simple and quick solution for this is to allow caching of authorized content with the dispatcher setting:/allowAuthorized "1"

However, this setting now allows caching of secure content, which may be a security concern. My thoughts were along the lines that Geometrixx Outdoors allows logins, so for some reason, all requests are returning the authorized header, and therefore telling the dispatcher not to cache the request without this setting.

But on the current implementation, I’m working on, there is no login or secured content and the dispatcher is still telling me that the request contains authorization and is not caching.

It turns out that the culprit was my browser. I had the Author interface open in one tab, and the published content in another tab. The browser was sending the authorization tokens from the Author instance to the Dispatcher, as it’s all the same machine (my local development server) in the same browser session. After opening the dispatcher request in an incognito tab, the authorization header was not being sent, and the dispatcher was caching as expected.

So remember, don’t simply set /allowAuthorized to “1” in order to solve an authorization problem unless you actually have secured content that you want to cache – there may be other reasons your dispatcher is thinking your request contains authorization headers.