Expand my Community achievements bar.

Guidelines for the Responsible Use of Generative AI in the Experience Cloud Community.
SOLVED

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

Avatar

Level 3

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?

1680664_pastedImage_0.png

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

Any ideas?

1 Accepted Solution

Avatar

Correct answer by
Level 7

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

View solution in original post

10 Replies

Avatar

Level 10

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.

Avatar

Correct answer by
Level 7

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

Avatar

Level 10

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.

Avatar

Level 10

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

Avatar

Level 7

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

Avatar

Level 3

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.

Avatar

Level 7

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.

Avatar

Level 10

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

Avatar

Level 7

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

Avatar

Level 3
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