Rules of AEM

Adobe Experience Manager (AEM) is a popular content management system that is widely used to develop and manage websites, mobile apps, and other digital experiences. However, like any other web application, AEM is vulnerable to cross-site request forgery (CSRF) attacks. CSRF attacks are malicious attacks where an attacker tricks a user into performing an action they did not intend to perform by exploiting the user's active session on a website. In this blog, we will discuss some measures that can be taken to protect AEM from CSRF attacks. Implement CSRF protection in AEM: The first and most important step to protect AEM from CSRF attacks is to implement CSRF protection in the application. AEM provides a built-in CSRF protection mechanism that can be enabled by setting the "sling.filter.methods" property in the OSGi configuration. This property specifies which HTTP methods are allowed to execute without requiring a CSRF token. Implement CSRF protection in Disp

Prevent Denial of Service (DoS) Attacks : AEM  A denial of service (DoS) attack is an attempt to make a computer resource unavailable to its intended users. At the dispatcher level, there are two methods of configuring to prevent DoS attacks: Use the mod_rewrite module (for example,  Apache 2.4 ) to perform URL validations (if the URL pattern rules are not too complex). Prevent the dispatcher from caching URLs with spurious extensions by using  filters .  For example, change the caching rules to limit caching to the expected mime types, such as .html .jpeg .gif .swf .js .doc .pdf .ppt .... as per your project requirement. An example configuration file is given below,  for  this includes restrictions for mime types.      When configuring Dispatcher you should restrict external access as much as possible. The      following example provides example for the minimal access for external visitors, you can refer the default file.  /filter { # Deny everything first and then allow s

Upgrading the dispatcher module in AEM Often the AEM dev-ops team faces the challenge on Dispatcher upgradation. It is not clear anywhere how to do it and what precautions one should take while doing the same.  In this article we will cover these steps,  Upgrading the Dispatcher Module : Step 1 -  Download the required dispatcher module version from the  Adobe dispatcher download page  ,  Make sure you download the dispatcher version module as per the OS. https://experienceleague.adobe.com/docs/experience-manager-dispatcher/using/getting-started/release-notes.html?lang=en Step 2 -  Extract the dispatcher module at some location on server or local machine.                      tar -xvzf <dispatcher-xxxxxxxx.tar.gz> (linux)  Step 3 -  Copy the extracted dispatcher-xxxxxxxxxx.so file to the module folder of the server.                          Module folder location can vary based on OS, Installation Type. hence please make sure you find the correct module folder.  Step 4 - Set the

How to Delete Dispatcher cache without logging into the Dispatcher servers? Our Authoring team faces day to day challenges while deleting/flush the dispatcher cache. when the changes are not visible on server. They have to be depended on the IT operations/Dev ops teams to do the same. Which some time get very much time consuming for a small work.  In this article we will see it can be configure and used by Author UI itself.  This will allow  AEM authors (or “super authors”) to flush parts of the dispatcher cache manually without the involvement of IT Operations. How to Use 1. Log in to AEM Author 2. Download the ACS commons tool from  ACS Commons Official page 3. Install the downloaded package via aem package manager.   4. Make sure you create the dispatcher flush agents on Author for all Dispatchers. from http://<<host:port>>/miscadmin#/etc/replication/agents.author, check the NOTE's part at the end of page. 5. Navigate to Tools 6. Under the acs-commmons/dispatcher-flu

The dispatcher is used as a load balancing/caching tool by AEM. It can also be used to block anyone from accessing your AEM author instance. This is to ensure that no one outside the client’s network can access it. AEM Author and publisher should never be exposed directly. In most cases, clients may also require a block to be put on AEM pub dispatchers before going live. This is to ensure that no one can see the site except for the client so performance, penetration, and UAT testing can be performed before going live. In this article, we will see, 5 easy steps to enable IP whitelisting in Apache so only the allowed list of IPs have access to AEM through the dispatcher. 1) In Apache to enable whitelisting, the Require directive is used which is provided by the mod_authz_host module. Make sure that you have the module enabled first in  /dispatcher/src/conf.modules.do/00-base.conf LoadModule authz_host_module modules/mod_authz_host.so 2) In the ams default variable file /dispatcher/src/c

How to Increase Apache Request Per Second ? By default, Apache web server is configured to support 160 requests per second. As your website traffic increases, Apache will start dropping additional requests and this will spoil customer experience.  Here’s how to increase Apache requests per second. 1. Install MPM module We need to install MPM Apache module to be able to increase Apache requests per second. You can use mpm_worker or mpm_event module for this, instead of mpm_prefork module which consumes a lot of memory. You can easily install MPM module in Apache with following command For CentOS7/RHEL7 : Adjust /etc/httpd/conf.modules.d/00-mpm.conf Comment the line LoadModule mpm_prefork_module modules/mod_mpm_prefork.so by adding # in front of it. Uncomment the line LoadModule mpm_worker_module modules/mod_mpm_worker.so by removing # in front of it. For Ubuntu/Debian :  Use a2dismod / a2enmod to disable mpm_prefork and enable mpm_worker 2. Increase Max Connections in Apache Open MP

 Maven build is failing due to CHECKSUM issue.  AEM Developers, Infrastructure Engineers regularly come across a challenge on building the AEM code & dispatcher module use to get failed while mvn build. The article addresses in a simple way on how to understand the mechanisms of dispatcher module build, and gives a detailed explanation of how it can be resolved.  This is useful for  building the code for a deployment via Pipeline either it is Adobe Cloud manager or Jenkins, you can see this error while your local build itself.  This error is caused, as the dispatcher owner does not not want you to change/modify few of its default files which are marked as immutable in dispatcher server.  You can find full list of immutable files on of dispatcher provided by Adobe.  https://helpx.adobe.com/experience-manager/kb/ams-dispatcher-manual/immutable-files.html Issue :- In AEM while doing the deployment it is being seen , user get the exception , Maven mandatory check failed.  [main] [ERR

AEM DISPATCHER STATFILE UNDERSTANDING & CACHE INVALIDATION:- AEM Developers, Infrastructure Engineers regularly come across a challenge on decoding the statfile and using it efficiently especially statfile becomes highly relevant in a multi-tenanted environment with different project teams controlling different sites. The article addresses in a simple way on how to understand the mechanisms of stat file and gives a detailed explanation of how it can be used in a multi-tenant environment model.  The image for your reference as a quick overview of the data flow, before we take a deep dive.  This article covers - 1 - When dispatcher serves the old version of the content. How to avoid it. 2- Cache invalidation mechanism. Assumption - If you are reading this article, I believe you would have a basic understanding of Dispatcher and it's configuration. Firstly let’s set the initial configuration for the cache invalidation section of the dis