How to change AEM’s redirection HTTP status code?

Posted on Tuesday, August 20, 2013 By

Redirection of request URLs in AEM can be configured at the Sling level, typically in the mapping configuration under /etc/map node. Depending on the requirements, there are times when customers would like to change the default HTTP status code for redirection. And here you will find two ways of changing the status code:

The sling:status way

Documented in already, you may use sling:status property to set a specific status code for a particular redirection. To extend the example given on the page linked above:

      +-- http
           |    +-- sling:redirect = ""
           |    +-- sling:status = "301"

Via OSGi configuration

Another way, which really sets the default for all redirection, is to configure the status code at the OSGi bundle level. In the OSGi console, browse the the Configuration page and locate:

“Apache Sling Resource Resolver Factory”

and change the redirect status field to whatever status code is appropriate (highlighted in diagram below).

Sling redirection status code


4:50 PM Permalink

How to send an AEM dispatcher flush request via cURL

Posted on Tuesday, August 20, 2013 By

In the “Invalidating Cached Pages from AEM” document on¬†, there is a brief section covering how to invalidate dispatcher cache manually. It only talks about sending HTTP requests to the dispatcher and it briefly touches on the format. So, where’s the quick (and dirty, if you will) command? Anything for me to copy and paste and get the job done?

Here you go:

curl -H "CQ-Action: Activate" \ 
     -H "CQ-Handle: /content/bar" \ 
     -H "Content-Length: 0" \
     -H "Content-Type: application/octet-stream" \ 

Of course you will have to replace the content path and the host/port.

If you ever need a “hook” to get a custom set of files to be invalidated from the dispatcher, for whatever reason, put the above into a script in any *nix environments (where cURL is supported) should do the job for you. Oh, did I forget to mention that you can actually trigger a command from an AEM workflow? You get the idea ūüėõ


4:09 PM Permalink

Firewall rules for typical CQ Author-Publish-Dispatcher setup

Posted on Friday, May 17, 2013 By

I came across a few projects in the past that required CQ implementations spanning multiple data centers thus needing tons of firewall rules. Like many enterprise environments, the process of filing firewall requests (to open a few holes), to scheduling outage windows and all the way to getting the rules in place, can easily take up a week or two, if not days. Not to mention that the same process probably have to be repeated multiple times (DEV, QA, Staging, Production…). This is especially hard if your organization is using CQ for the very first time, as there are rules usually missed.

So I wanted to use this post to capture the port that should be opened in a typical CQ set up. In the following tables, I’m assuming:

  • CQ Author running on default port 4502
  • CQ Publish running on default port 4503
  • Dispatcher/Webserver running on port 80/443.

Replication from CQ Author to CQ Publish

| Source Server | Source Port | Destination Server | Destination Port |
| CQ Author     | 4502        | CQ Publish         | 4503             |

Cache Flushing from CQ Publish to Dispatcher

| Source Server | Source Port | Destination Server | Destination Port |
| CQ Publish    | 4503        | Dispatcher         | 80 / 443         |

Clustering CQ (2 instances)

| Source Server   | Source Port | Destination Server | Destination Port |
| CQ (Auth1/Pub1) | 8088        | CQ (Auth2/Pub2)    | 8088             |

Range of ports listed at

Reverse Replication from CQ Publish to CQ Author

| Source Server | Source Port | Destination Server | Destination Port |
| CQ Publish    | 4503        | CQ Author          | 4502             |

Dispatcher retrieving published content

| Source Server | Source Port | Destination Server | Destination Port |
| CQ Dispatcher | 80 / 443    | CQ Publish         | 4503             |

If there is a dispatcher sitting in front of Clustered Author

| Source Server     | Source Port | Destination Server | Destination Port |
| CQ Author         | 4502        | Author Dispatcher  | 80 / 443         |
| Author Dispatcher | 80 / 443    | CQ Author          | 4502             |
| CQ Author1        | 8088        | CQ Author2         | 8088             |

And finally, there are also services being integrated. An example would be port 389 for LDAP / Active Directory. Don’t forget those!

9:35 PM Permalink

Page level selectors validation to prevent DoS Attacks

Posted on Friday, May 17, 2013 By

In the Adobe CQ security checklist located at, Denial of Service (DoS) Attacks prevention was briefly touched on. In this blog post I am going to give an example on how to best handle selectors validation at the CQ page level.

As mentioned in the security checklist, one of the most commonly seen Denial of Service attacks targeting CQ is by requesting a content page with unlimited number of URLs. Without selectors validation, these page requests are then usually cached, causing the disks to fill up very quickly and bring down the service.

Remember the Apache Sling script resolution? A script may have the following form (see


Imagine I have a valid CQ page test.html, here are the few variations I can have for the same page:

All these would be valid pages (if without checking the selectors) and would be cached in the cache layer if configured so.

The best way to prevent the above is to do a validation of the selectors at the page level. Sling API, specifically the RequestPathInfo, provides the getSelectors() method to get all the selectors from the requested URL. If you are not expecting any selectors being passed to your CQ page, you should make sure that slingRequest.getRequestPathInfo().getSelectors() yield an empty array. Otherwise, you should do a very strict comparison of the selectors array with what you’re expecting.

If there’s any unexpected selectors, you may choose to throw a 404 (Not Found) or other error status code so that the page does not get cached.


Note that the above would only prevent invalid requests from being cached. These requests, although not cached, would still be routed all the way to the CQ servers (another means of DoS attacks is to generate massive number of requests to a targeted server). So another highly recommended line of defense, is to set up very strict dispatcher filter rules so that invalid requests would not generate any traffic to the CQ servers.


9:31 PM Permalink

CQ 5.6 Out Of The Box Workflow Processes, and what they do/can be used for.

Posted on Monday, May 13, 2013 By

I will try and cover what are all the OOTB workflow processes available in CQ 5.6. The processes in red below are the ones where I will add some explanations to as and when I find time.

  • Collaboration Worklow
    • Approve Comment –¬†This process is to approve a comment posted on the site automatically. It will only approve the comment if you have the “Approve” box checked on the Arguments tab of the wf process dialog.The script used by the process is located under
      • /etc/workflow/scripts/social/set_approved.ecma.
    • Approve Comment Step – This process is to send a notification to a user or group to approve a comment. You have the option to choose the User/Group on the dialog and also an option to send an email.
    • Blog Search Ping – This process submits a blog post to various blog search engines. It uses the¬†BlogSearchPingService for the post. Look at the “Day CQ Social Collaboration Blog Search Engine Ping” class’ configuration in the Felix Console. There are no arguments available for this process.
    • Calendar Subscription – This process can be used to either subscribe or unsubscribe to a calendar. It will either¬†subscribe or unsubscribe the calendar component given as the “target”¬†¬†property in the workflow metadata to the event or calendar (payload). You can choose whether you want the process to do a subscription or an un-subscription from the process arguments.
    • Check Blog Spam – This process checks a comment for spam. OOTB you can either use Akismet service, you need to enter a valid key and registered URL for the spam service in the configurations for Day CQ Antispam.
    • Check Journal Spam – Same as the Check Blog Process above, uses the the Akismet service.
    • Flush (Replicate) Page –¬†A process to flush(replicate) a page for a given replication agent, the argument should be like “agent:flush” for the dispatcher flush agent. It uses the script “/etc/workflow/scripts/social/flush_page.ecma”.
    • Forum Subscription –¬†Process to subscribe and unsubscribe from a forum.¬†¬†Subscribes or unsubscribes the given user in the metadata to the payload forum topic. This process is used in¬†conjunction with the User State Toggle Button feature. You can choose the “Subscribe” or “Unsubscribe” argument. Subscribe is the default.
    • Journal Search Ping – Same as the Blog Search Ping process above.
    • QnA Subscription – Same as the Forum/Calendar Subscription process above.
    • Send Email –¬†Sends an email based on an email template. You can either point to a template or put the template in a text area of the Arguments tab of the process. The Day CQ Mail Service must be configured for this to work.
  • DAM Workflow
    • Command Line –¬†A process to execute multiple command line programs (imagemagick for example). Mime type, Commands and Thumbnails are the arguments that can be passed to the process. This is documented pretty well on the process dialog itself.
    • Create Sub Asset –¬†This process will fragment an asset in its subassets.¬†Sub assets are assets stored under another asset, as a result of splitting up the asset in fragments during its import, e.g. the single pages of a multi-page PDF file.
    • Create Thumbnail –¬†This process will create one or more thumbnails for the asset to be processed. This is pretty self explanatory.
    • Create Video Storyboard –¬†A process to create a video storyboard. Workflow process that calls FFMPEG on the command line to create a storyboard¬†of a video. A storyboard consists of several key frames extracted from the¬†video. The key frames will be stored as subassets of the video asset. Also, a¬†merged film strip of the key frames will be stored as a storyboard rendition¬†of the video asset.¬†Frame Count, Start, Maximum Width, Maximum Height , Upscale and Frames are the arguments.¬†Examples:¬†Create 10 frames, starting with the first at 12 seconds into the movie¬†frames:10,start:12¬†Create 10 frames, each 100 x 80 px, upscaled:¬†frames:10,maxWidth:100,maxHeight:80,upScale:true¬†Create 5 frames, each at a defined position, each 100 x 80 px, upscaled:¬†maxWidth:100,maxHeight:80,[00:05:00],[00:10:00],[00:15:00],[00:20:00],[00:25:00].¬†Will create thumbnails of size 140×100 and 48×48 with a black¬†letterbox/pillarbox only for assets of the video based mime types.
    • Create Video Thumbnails –¬†Workflow process that calls FFMPEG on the command line to create thumbnails of the image. You can specify the dimension of the thumbnails to be created. For example, using the following workflow step arguments:count:3,index:1,start:10,[140×100],[48×48]. Will create thumbnails of size 140×100 and 48×48 with a black letterbox/pillarbox only for assets having a video-based mime-type.
    • Create Web Enabled Image – This one is pretty well explained on the process dialog itself.
    • Delete Asset – Self Explanatory.
    • Delete DAM Asset –¬†The process will delete the file in the /var/dam when the asset in the /content/dam location got deleted. Deletes an Item for the Payload under the following condition: The Payloads relative path to a given source root exists in a given destination branch.¬†If the Payload points to /content/dam/geometrixx/buildings, the Process checks if an Item exists at /var/dam/geometrixx/buildings. If there is an Item and this Item is not involved in a Workflowm, it will be deleted. Assuming the source and destination arguments were set to match the example.
    • Extract Meta Data – Self Explanatory.
    • Gate Keeper –¬†This process prevents the workflow from being fired if an asset is restored, a version restore for example.
    • IDS Job Process –¬†Workflow process for InDesign assets.
    • Light Box Update Asset –¬†This process sets the entry in the lightbox as new originial to the asset it references. It looks at the “assetRefs” property for the original asset.
    • Media Extraction –¬†InDesign Media Extraction. This process creates a¬†SOAP packet with an embedded¬†EmbeddedScript to be executed on InDesign server. The process arguments lets you choose the ExtendScript library, Extend Scripts and the Links Folder Path.
    • Page Extraction –¬†InDesign Page Extraction.¬†This process step creates a CQ page from an InDesign document.The actual extraction is carried out by a configurable PageExtractionHandler. This step works on asset renditions only. The renditions to use are determined by the PageExtractionHandler as well and are expected to be created in a previous step. Arguments¬†available ¬†are

      extractionHandler: The actual extraction handler class to use for creating the page
      pageName: The name int for the extracted page
      pageRoot: The root path for the extracted page
      pageTemplate: The template to use for the extracted page
      pageDesign: The page design to use for the extracted page
      pageTitle: The page title to use for the extracted page

    • Resize Image –¬†The process dialog for this is pretty self explanatory.
    • Resize Image to Area –¬†Same as above, except that you can enter the area of the image (width x height).
    • Set Last Modified –¬†Self Explanatory
    • Synchronize /var/dam –¬†The SyncContentProcess syncs the content below /var/dam with¬†/content/dam in two different modes (cleanup and sync).¬†Process is only executed if started with a mode argument, the payload exists¬†and is currently not involved in a Workflow.
    • Synchronize Asset –¬†Self Explanatory from the process dialog.
    • Synchronize Content –¬†The SyncContentProcess syncs the content below /content/dam in¬†two selectable modes (cleanup and sync).¬†Expects its Payload to point to a nt:folder. The cleanup mode removes the nodes in /content/dam structure that have no counterpart in the /var structure. The sync mode starts for any nt:file in the branch a Workflow with the Workflow Model Id provided in the arguments and the files path as the payload. The workflow model id argument is the¬†Identifier¬†of a WorkflowModel. This Workflow will be started on Assets¬†added by this Process in mode sync. It is ignored in cleanup mode. Example :/etc/wokflow/models/syncmodell
    • Transcode Video –¬†Self Explanatory.
    • Unarchiver –¬†The process dialog does a very good job of explaining what this process does.
    • XMP Writeback –¬†Writes metadata back to the binary.
  • WCM Workflow –¬†All the OOTB processes in this group are pretty self explanatory.
    • Activate Page/Asset
    • Create Version
    • Deactivate Page/Asset
    • Reverse Replicate Content
  • Workflow
    • AND Split –¬†Puts an AND split in your workflow model. You can choose between 2 and 5 branches.
    • Absolute Time Auto Advancer –¬†Workflow Auto Advance Process.
    • Auto Advancer –¬†Same as above.
    • Call Url –¬†Process to call a URL. Script is located at¬†/etc/workflow/scripts/urlcaller.ecma. Arguments are URL, username and password. Pretty self explanatory once you look at the ECMA script.
    • Container Step –¬†Process to contain a workflow within a workflow. The process dialog lets you choose the workflow model you want to include.
    • Create Task –¬†Process to create a task in the new CQ 5.6 Task Manager. The process dialog does a pretty good job of defining arguments and what they are used for.
    • Delete Node –¬†Self Explanatory.
    • Dialog Participant Step –¬†This process lets you define your custom dialog that will be presented to the user when they want to complete the workflow task from the CQ inbox. This is a good way to have users enter custom data when completing a workflow task.
    • Dynamic Participant Step –¬†This process lets you choose a participant dynamically within the workflow rather than setting it up in the model on creation.
    • Extract Export Data¬†
    • Form Participant Step –¬†Same as the dialog participant step. Reference here on how to use it.
    • Goto Step –¬†Lets you go back to a particular step in the workflow. At the time of writing this blog, there was a UI bug where if you had the goto step inside a split, the drop down wont show the steps outside the branch of the split. The workaround for this is to manually update the property in CRXDE for the goto step process.
    • Lock Payload Step –¬†Self Explanatory.
    • No Operation –¬†Self Explanatory.
    • OR Split –¬†Self Explanatory.
    • Participant Step –¬†Self Explanatory.
    • Process Assembler
    • Process Step –¬†Self Explanatory.
    • Random Participant Chooser –¬†Self Explanatory.
    • Scene7
    • Sentiments Analyzer
    • Test & Target Offer
    • Unlock Payload Process –¬†Self Explanatory.
    • Watchwords Analyzer
    • Workflow Initiator Participant Chooser –¬†Sample that chooses the workflow initiator as the participant.

As always, please leave comments with questions/concerns and I will try to answer as soon as I can.

11:56 AM Permalink