What is the purpose of Dispatcher in front of single Author?

[jura_khrapunov]

Is there any advantage of having dispatcher in front of the Author if it is the only instance, so load-balancing is not required, and as per official documentation cache should be disabled there anyway?

So far it only proxying requests between :80 and :4502 ports to underlying publisher and that's probably it.

Any ideas?

[smacdonald2008]

See here -- Dispatcher Overview

Although there is a section, one of the purposes of Dispatcher is to cache pages to improve the performance of the Pub instance.

So i am not seeing any advantage of having a dispatcher in front of Author instance, where you want to update the content, not deal with cached pages on Author.

Lets see what other community members have to say about this.

[antoniom5495929 · Accepted solution]

Hi,

the purpose of the dispatcher for an author instance is not only for balancing but also for security (e.g. Https [0]) .

You need to consider that if you have a dispatcher in front of the author instance, you could disable the access of CRXDe and SystemConsole for the authors. Without a dispatcher, also the content-authors are able to use the CRXDe with the possibility to change or move something in the repository.

Let me know if you need some other info.

[0] The Dispatcher Security Checklist

Thanks,

Antonio

[Gaurav-Behl]

You may still cache say 10-20% of the requests with specific patterns and extensions but I don't think that's worth the effort.

However, after reading this "caution statement", I'm confused that is it even a real-life use case? Even if you use multiple authors, say for load-balancing, then Touch UI would still be utilized for majority of interactions which breaks the deal.

Caution Statement

if you are using AEM with Touch UI you should not cache author instance content.

[Gaurav-Behl]

We could disable /crx/de and other paths in the author itself rather than using dispatcher for this use case. Same goes with ACLs/security aspects

[antoniom5495929]

It's not the same approach.

By using the dispatcher you could disable it without give access to the AEM instance.

An other point is that in a typical architecture you cannot expose directly the AEM instance in internet but you need to use an Apache.

In fact the AEM instance need to be used in VPN and the business could use the Apache which is in DMZ.

And as i told before, with dispatcher you could also enable the https that in some cases need to be used for some request (e.g. authentication with some external system).

https://helpx.adobe.com/experience-manager/dispatcher/using/security-checklist.html#Enable HTTPS for transport layer security

[jura_khrapunov]

Good point about security, antoniom54959291​, indeed https is required for SSO integration or authentication flow if handled by directly by author.

Does anyone know why Touch UI requests cannot be cached? All content related GET calls have timestamped URL query so they are bypassing cache anyway.

[antoniom5495929]

You cannot cache the touch UI request because otherwise you are not able to use the new version of css or js if you install a new SP or CFP. And you need to delete the generated cache manually after the update of your instance.

[Gaurav-Behl]

Just for HTTPS/Security, you don't need a reverse proxy(Dispatcher), you could simply use a normal proxy and achieve the same results.

[antoniom5495929]

Hi gauravb10066713,

as i told in the previous responses is not only for HTTPS, but also for security.

If you need some other info you can just check the standard configuration in the author_dispatcher.any (that you have in the default installation) to understand which are all the security configuration that are applied in a dispatcher in front of the author.

Thanks,

Antonio

[jura_khrapunov]

You cannot cache the touch UI request because otherwise you are not able to use the new version of css or js if you install a new SP or CFP. And you need to delete the generated cache manually after the update of your instance.

I don't think it is the case otherwise Classic UI was also mentioned. There is something specific to Touch UI they had in mind