Posts tagged "dispatcher"

August 20, 2013

How to send an AEM dispatcher flush request via cURL

In the “Invalidating Cached Pages from AEM” document on https://dev.day.com/docs/en/cq/current/deploying/dispatcher/page_invalidate.html, 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" \ 
     http://_dispatcher-server-hostname_[:port]/dispatcher/invalidate.cache

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 :P

 

4:09 PM Permalink
May 17, 2013

Firewall rules for typical CQ Author-Publish-Dispatcher setup

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 http://dev.day.com/docs/en/cq/current/core/administering/cluster.html

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

In the Adobe CQ security checklist located at https://dev.day.com/docs/en/cq/current/deploying/security_checklist.html, 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 http://sling.apache.org/documentation/the-sling-engine/url-to-script-resolution.html):

{selectorStringPath}.{requestExtension}.{scriptExtension}

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

test.xyz.html
test.abc.html
test.aaa.html
test.bbb.html
test.abcde.html

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