Expand my Community achievements bar.

Dive into Adobe Summit 2024! Explore curated list of AEM sessions & labs, register, connect with experts, ask questions, engage, and share insights. Don't miss the excitement.
SOLVED

Is there something like servlet filters but for pages for AEM cloud?

Avatar

Level 9

if you use your own (sling)servlets in AEM, you can also write filters to do things like log request or add headers to any servlet based on a pattern, e.g. 

@component
@SlingServletFilter(scope = {SlingServletFilterScope.REQUEST},
					pattern = "/bin/.*",
                    methods = {"GET","POST"})
public class CorrelationLoggingFilter implements Filter {

Is something like this possible for pages?  

We want to implement things like dynamic url rewriting/routing, but not do it in the dispatcher (as this cannot be easily tested on local author env, and to deploy to cloud to test a one line change takes anything between  2 hours and 2 days.

1 Accepted Solution

Avatar

Correct answer by
Employee Advisor

Hi @TB3dock!

 

In general, filters do apply to all requests so the answer to your question if filters can be included into request processing for pages is: yes. Please refer to the example filter implementation of the AEM Maven Archetype for an example [1].

 

That being said, I strongly discourage to build a custom rewriting or ruling mechanism into AEM. This will probably interfere with various AEM and Sling features and mechanisms and potentially break things. You really don't want to go down that rabbit whole.

 

There are two alternative approaches here:

  1. Use the according Apache httpd and dispatcher features
    It's totally possible to test this on a local environment and the AEM Cloud SDK even includes a Dispatcher. I recommend to have at least one (local or server) dev environment in every project that includes a full setup with author and publish instances plus dispatcher for this kind of development.
    Handling rewriting and redirects on the dispatcher level comes with performance advantages and reduces load to the AEM instances. Shying away from this approach because you just don't want to setup a local dispatcher is IMHO not a very resilient argument against it. You will have a dispatcher in production and you really should have a proper setup to develop and test your configurations on the lower/lowest stages as well.
  2. Use the existing AEM features for Resource Mapping [3] such as
    1. JCR Resource Resolver and/or
    2. AEM Mapping Definitions (/etc/map)

Personally, I prefer a combination of rewrite rules on the dispatcher level and link rewriting on the AEM side as outlined in this article [4] .

Please note that this always has two components:

  • Routing incoming requests to the correct path/resource (e. g. mysite.com/home.html to /content/mysite/de/de/home) and
  • Rewriting links inside the page/components (e. g. shortening /content/mysite/de/de/home.html to /home.html in href attributes)

 

Hope that helps!

 

[1] https://github.com/adobe/aem-project-archetype/blob/develop/src/main/archetype/core/src/main/java/co...

[2] https://experienceleague.adobe.com/docs/experience-manager-cloud-service/implementing/developing/aem...

[3] https://experienceleague.adobe.com/docs/experience-manager-65/deploying/configuring/resource-mapping...

[4] https://helpx.adobe.com/in/experience-manager/kb/multi-domain-management-aem-mappings-for-url-shorte...

View solution in original post

5 Replies

Avatar

Community Advisor

Hi @TB3dock 

 

Ideally filters should log all the request. Is it not logging the page requests?

You can change the path and try it out.

Avatar

Correct answer by
Employee Advisor

Hi @TB3dock!

 

In general, filters do apply to all requests so the answer to your question if filters can be included into request processing for pages is: yes. Please refer to the example filter implementation of the AEM Maven Archetype for an example [1].

 

That being said, I strongly discourage to build a custom rewriting or ruling mechanism into AEM. This will probably interfere with various AEM and Sling features and mechanisms and potentially break things. You really don't want to go down that rabbit whole.

 

There are two alternative approaches here:

  1. Use the according Apache httpd and dispatcher features
    It's totally possible to test this on a local environment and the AEM Cloud SDK even includes a Dispatcher. I recommend to have at least one (local or server) dev environment in every project that includes a full setup with author and publish instances plus dispatcher for this kind of development.
    Handling rewriting and redirects on the dispatcher level comes with performance advantages and reduces load to the AEM instances. Shying away from this approach because you just don't want to setup a local dispatcher is IMHO not a very resilient argument against it. You will have a dispatcher in production and you really should have a proper setup to develop and test your configurations on the lower/lowest stages as well.
  2. Use the existing AEM features for Resource Mapping [3] such as
    1. JCR Resource Resolver and/or
    2. AEM Mapping Definitions (/etc/map)

Personally, I prefer a combination of rewrite rules on the dispatcher level and link rewriting on the AEM side as outlined in this article [4] .

Please note that this always has two components:

  • Routing incoming requests to the correct path/resource (e. g. mysite.com/home.html to /content/mysite/de/de/home) and
  • Rewriting links inside the page/components (e. g. shortening /content/mysite/de/de/home.html to /home.html in href attributes)

 

Hope that helps!

 

[1] https://github.com/adobe/aem-project-archetype/blob/develop/src/main/archetype/core/src/main/java/co...

[2] https://experienceleague.adobe.com/docs/experience-manager-cloud-service/implementing/developing/aem...

[3] https://experienceleague.adobe.com/docs/experience-manager-65/deploying/configuring/resource-mapping...

[4] https://helpx.adobe.com/in/experience-manager/kb/multi-domain-management-aem-mappings-for-url-shorte...

Avatar

Level 9

Thank you for this informative reply. Agreed doing URL rewriting/routing it in dispatcher would be easy, but this is static and requires releases to change. As our release cycle is typically months, this wont work as we need to change routing every time we get a new affiliate or want to exclude a specific country for example. We cant use OSGI config parameters as access to these is removed in cloud version. We need to build some custom code and some UI in the CMS or external system to manage it.

The other big requirement is the ability to route based on country (if the ip).  with EpiServer we did this based on the coutry header Cloufflare adds to every request, and is not bypassable.  For AEM, we are not sure how we can do this yet, possibly we need to import a static ID database, or call a 3rd party such as neustar.

Avatar

Employee Advisor

Hi @TB3dock!

The above outline approach can be designed quite flexible when it comes to different countries and languages, depending on your content architecture. The general recommendation is to strictly follow a pattern and stick to ISO country and language codes. This way, you can leverage regular expressions for the matching an mapping on all relevant levels, eleminating the need to change configuration for additional countries or languages. If you rollout additional tenants/brands/websites you will usually need changes to the dispatcher configurations anyways (e. g. adding a new vhost with the new domain).

Apart from that you can check on how AEM handles Vanity URLs [1] and the according integration with the dispatcher. Maybe you can somehow leverage this feature for your purposes or built a custom solution around/ontop of this. For this feature, AEM provides a list of redirect mappings at a certain url and the dispatcher queries this endpoint on a regular schedule and includes the redirect map dynamically.

 

Hope that helps!

 

[1] https://helpx.adobe.com/experience-manager/kb/ams-dispatcher-manual/disp-vanity-url.html

Avatar

Employee Advisor
For the Geo IP use case I've used different modules for Apache httpd, so also handled that on dispatcher level. You can use that to expose the location e. g. as httpd environment variable to set headers (for consumption within AEM or other backend systems) or perform redirects.