In CQ, ResourceResolver class can be used for resolving a Request into a Sling Resource. However, given a random URL served by a CQ instance, how do you figure out the corresponding Sling Resource of the given URL as a result of Resource Mapping definition?
Let's assume we have some Resource Mapping rules (mapping definition) set up on our Author node via /etc/map so that a sample request to,
Expose API on a CQ Author Node
In CQ, let's say we want to expose some sort of REST API for our internal clients, but don't want these API's accessible by the public. For example, say we'd like the said JSP to be available internally (inside firewall), and to be invoked via the web. The API's responsibility is to clear Dispatcher cache via curl command behind the scene.
If you'd like to hide non-applicable workflows from being seen by users, it is said that you can hide a custom you can remove a tag named 'Workflow:WCM' to control the workflow to display or to hide. No so true, at least not for CQ/WEM 5.6.1. My experiments shows that to have a workflow show in sidekick, the workflow page/node must either have no tag at all, or be tagged with 'Workflow:WCM."
By default, only CQ admin user can impersonate others for testing purposes. Often times, you need a non-admin user to test out others' account. For that, it is possible for a non-admin user to impersonate another person as long as it was set-up before hand.
Production CQ instances deserves tighter security policy. OOTB CQ is too loose in security. For example, you don't need to open your production for client software like CRXDE to access it, nor do you want to open up WebDAV if not necessary. Most importantly, the default password of the super user 'admin' have got to be changed, which is not a straightforward process as you'd expect.
In this post, I outlined specific steps that I took to tighten up security of our CQ Author and Publish nodes in a production environment. If you are planning to launch a public facing CQ, you can go through the same checklist.
CQ5 Code Samples
Coding for CQ/WEM can be quite confusing sometimes, as confusing as it is whether it's CQ or WEM. This post is about basic WEM Code samples (in JSP) using CQ scripting objects on top of JSP implicit objects. First of all, let me be clear, since Adobe acquired Day Software, the name of Day CQ (Comuniqué) had changed to WEM (Web Experience Manager), thus CQ and WEM are interchangeable.
It is common to have multiple CQ Publisher instances in different environments (DEV, QA, PROD, etc.). When you make user administration and security changes toward users and groups on the production server, you may want to bring them down to the lower DEV and QA environments so they don't go out of sync. In such scenario, you have to copy over both user/group definition and the permission definition. This post shows you how to copy users and groups you set up on one CQ instance (source CQ) to another instance (destination CQ), and how to bring over the permissions (resource-based ACLs) from the source CQ to the destination CQ.
There are multiple ways to handle events at different levels in CQ. In this post, I'd show you some sample code that starts a corresponding job based on an event (e.g. the action type of the ReplicationAction event) triggered at the Sling level.
To put the above into context, let's assume we have a 'custom CQ workflow process step' (a.k.a. automated step) - PostPageActivationWorkFlow.java - developed already. The customer step is normally part of some workflow. This custom process step was designed so that it will 'replicate' the payload (the entity upon which a workflow instance acts) to a hypothetical remote place via HTTP POST. To run and trigger this custom process step (which in terms will execute PostPageActivationWorkFlow.replicate() method that I named and implemented), you normally create a workflow by dropping this custom process step into it. When the workflow runs into this step, its execute() will be executed. However, instead of triggering the process step from the workflow, what if we also want such 'replication' to be triggered by an CQ event (specifically, by the action type of the ReplicationAction event)? The following code sample will show you how.
It is often confusing as to how to set up an OSGi development environment for CQ5. In this post, I'll set what is to be coded aside, but focus on how to quickly and easily use CRXDE Lite (the web interface of CQ5) for
In a previous post, I showed you how to render a PDF documentation (.pdf) with an extra image prepended to the whole PDF document using PDF Rewriter. In this post, I'll show how to render a PDF documentation with an additional PDF page appended as a back-cover. This PDF backcover can not be done by PDF Rewritter, as an Adobe staff confirmed PDF Rewriter (used Apache FOP 0.95) has yet to support merging PDF files.
**UPDATE: External links to pdf-files on http-servers and https-servers supported since Apache FOP 1.1.
For merging PDF files, I'll be using a Java PDF library - pdfbox. For this, we need pdfbox app OSGi bundle/jar (1.8.2 as of this writing or the latest version) deployed in the Felix OSGi container so we can develop a .jsp to call into the API for merging PDFs. So get the library ready in your CQ environment with these steps: