Betreff: Is there something like servlet filters but for...

[TB3dock]

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.

[Asutosh_Jena_]

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.

[markus_bulla_adobe · Accepted solution]

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

[TB3dock]

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.

[markus_bulla_adobe]

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

[markus_bulla_adobe]

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.