Posts tagged "cq"

August 27, 2012

How to prevent users from entering duplicate vanity URL’s

This is something which should come very handy at every CQ implementation. The requirement for vanity URLs is that you cant have two pages in CQ with the same vanity URL. In this blog I will try to go over an implementation which will prevent your content authors from entering duplicate vanity URL in the first place.

1. First thing you will need to do is override the OOTB page component dialog and the tab_basic node. To do this, please copy the following nodes

    • /libs/foundation/components/page/dialog
    • /libs/foundation/components/page/tab_basic

2. Paste these nodes as the child of your projects page component whose “sling:resourceSuperType” is “foundation/components/page”

 

3. For the dialog node, change the path to the basic tab to match the path of the “tab_basic” you pasted in your projects page component.
4. For the “tab_basic” node update the “tab_basic/items/vanity/items/vanityPath/fieldConfig” node to add the following two properties
  • vtype
  • vtypeText
5. Override  the following in your apps folder
  • /libs/cq/ui/widgets/js.txt
  • /libs/cq/ui/widgets/source/widgets
6. To your overridden widgets directory at “/apps/cq/ui/widgets/source/widgets”, add a file called duplicateVanityCheck.js
CQ.Ext.apply(CQ.Ext.form.VTypes, {
duplicateVanityCheck: function(v, f) {var dialog = f.findParentByType("dialog");
var dialogPath = dialog.path;
var cqresponse = CQ.HTTP.get("/apps/duplicateVanityCheck?vanityPath="+v+"&pagePath="+dialogPath);
 
var json = eval(cqresponse);
var vanitypathsjson = json.responseText;
var JSONObj = JSON.parse(vanitypathsjson);
var jsonVanityPath = JSONObj.vanitypaths;
 
if (jsonVanityPath.length == 0) {
return true;
} else {
// check whether the path of the page where the vanity path is defined matches the dialog's path
// which means that the vanity path is legal
return false;
}
 
//alert( "Checking Duplicate" );
}
});

 

7. In your overridden js.txt file, add this line

  • widgets/duplicateVanityCheck.js

 

8. You also need to make sure that your foundation client lib has a dependency on “cq.widgets”.

9. Now, we have to create an OSGi bundle that will query the JCR for an entered vanity and return the JSON that will be used by duplicateVanityCheck.js. The code for this class will look something like below

/**
 * @scr.component immediate="true" metatype="false"
 * @scr.service interface="javax.servlet.Servlet"
 * @scr.property name="sling.servlet.methods" values.0="GET"
 * @scr.property name="sling.servlet.paths" values.1="/apps/duplicateVanityCheck"
 */
 
public class VanityDuplicateCheck extends SlingAllMethodsServlet{
 
    private static final Logger logger = LoggerFactory.getLogger(VanityDuplicateCheck.class);
 
    @Override
    protected void doGet(SlingHttpServletRequest request, SlingHttpServletResponse response) throws ServletException, IOException {
 
        try{
            Session session = request.getResourceResolver().adaptTo(Session.class);
            final String vanityPath = request.getParameter("vanityPath");
            final String pagePath = request.getParameter("pagePath");
            logger.info("vanity path parameter passed is {}", vanityPath);
            logger.info("page path parameter passed is {}", pagePath);
            try {
                QueryManager qm = session.getWorkspace().getQueryManager();
                String xpath = "//element(*)[sling:vanityPath='"+ vanityPath + "']";
                logger.info("xpath is {}", xpath);
 
                Query query = qm.createQuery(xpath, Query.XPATH);
                logger.info("Xpath Query Statement is {}", query.getStatement());
                QueryResult result = query.execute();
                NodeIterator nodes = result.getNodes();
                logger.info("result is ", result.getNodes().toString());
 
                TidyJSONWriter tidyJSONWriter = new TidyJSONWriter(response.getWriter());
 
                tidyJSONWriter.object();
 
                tidyJSONWriter.key("vanitypaths").array();
 
                response.setContentType("text/html");
 
                while (nodes.hasNext()) {
                    Node node = nodes.nextNode();
                    logger.info("Node path is {}", node.getPath());
                    logger.info("Page path is {}", pagePath);
                    if(node != null && node.getPath().contains("/content"))
                    {
                        // check whether the path of the page where the vanity path is defined matches the dialog's path
                        // which means that the vanity path is legal.
                        if(node.getPath().equals(pagePath))
                        {
                            //do not add that to the list
                            logger.info("Node path is {}", node.getPath());
                            logger.info("Page path is {}", pagePath);
                        } else {
                            tidyJSONWriter.value(node.getPath());
                        }
                    }
                }
 
                tidyJSONWriter.endArray();
                tidyJSONWriter.endObject();
                response.setContentType("application/json");
                response.setCharacterEncoding("UTF-8");
            }
            catch(RepositoryException re){
                logger.error( "Error in doGet", re );
            }
        } catch (JSONException e) {
            logger.error( "Error in doGet", e );
        }
    }

8. At this point you should have everything you need to prevent content authors from entering duplicate vanity URL’s. If they do enter a URL that is already in use, it will fail the validation and they will see an error message similar to what you entered in the vtypeText property.

 

Enjoy..and as always, please leave comments/questions and I will try to answer them as soon as possible.

5:49 PM Permalink
May 19, 2012

How to enable and test CQ’s permission sensitive caching

In this blog post I would like to extend on the permission sensitive caching knowledge base item documented at:

http://dev.day.com/content/kb/home/cq5/CQ5SystemAdministration/PSCachingDelivery.html

One thing to note is that the auth_checker configuration should be placed under the site configuration (usually under the farm entry). Here’s an example:

# each farm configures a set off (loadbalanced) renders
/farms
  {
  # first farm entry (label is not important, just for your convenience)
  /website
    {
    # Authorization checker: before a page in the cache is delivered, a HEAD
    # request is sent to the URL specified in 'url' with the query string
    # '?uri='. If the response status is 200 (OK), the page is returned
    # from the cache. Otherwise, the request is forwarded to the render and
    # its response returned.
    /auth_checker
      {
      # request is sent to this URL with '?uri=' appended
      /url "/bin/permissioncheck.html"
 
      # only the requested pages matching the filter section below are checked,
      # all other pages get delivered unchecked
      /filter
        {
        /0000
          {
          /glob "*"
          /type "deny"
          }
        /0001
          {
          /glob "*.html"
          /type "allow"
          }
        }
      # any header line returned from the auth_checker's HEAD request matching
      # the section below will be returned as well
      /headers
        {
        /0000
          {
          /glob "*"
          /type "deny"
          }
        /0001
          {
          /glob "Set-Cookie:*"
          /type "allow"
          }
        }
      }
      # client headers which should be passed through to the render instances
      # (feature supported since dispatcher build 2.6.3.5222)
      /clientheaders
        {
...

Testing

To test the PermissionHeadServlet created for permission sensitive caching delivery purposes, the curl command would be your friend. Here are some examples of the commands to retrieve the authentication status on a “locked-down” item in DAM:

[Without Proper Authentication]:

$ curl --head http://_pubserver_:_port_/content/dam/testsite/documents/sensitive_doc.pdf

And here’s the result:

HTTP/1.1 403 Forbidden
Connection: Close
Server: Day-Servlet-Engine/4.1.17
Content-Type: text/plain;charset=UTF-8
Date: Sat, 19 May 2012 18:17:36 GMT
Transfer-Encoding: chunked
X-Reason: Authentication Failed
Set-Cookie: JSESSIONID=c6a8de36-be69-4e9d-8706-df4bd79c3062; Path=/; HttpOnly

[With Proper username/password]:

$ curl --head http://_pubserver_:_port_/content/dam/testsite/documents/sensitive_doc.pdf --user admin:admin

And here’s the result:

HTTP/1.1 200 OK
Connection: Keep-Alive
Server: Day-Servlet-Engine/4.1.17
Content-Type: application/pdf
Content-Length: 758951
Date: Sat, 19 May 2012 18:25:07 GMT
Last-Modified: Wed, 07 Mar 2012 00:14:39 GMT
11:30 AM Permalink
February 10, 2012

How to save nodes to a dynamic path when using scaffolding

The out of the box scaffolding lets you choose a target path which where all the pages you create using the scaffolding will be stored.

I recently ran into a use case where the client wanted to save the pages to a dynamic path based on the date on which the page was created. One can achieve the fore mentioned use case by doing something similar to what I will lay out in this blog post.

1. Override the out of the box wcm/scaffolding path by creating the same path structure in the apps folder. The new structure should look like below.

You can copy the contents of the folder in the apps directory from the libs directory.

2. We will have to update the wcm/scaffolding/components/scaffolding/body.jsp file to add our custom code to change the save location.

  • Make sure the following classes are imported.
  • The code to get the current date

  • In the myForm.addButton method, update the out of the box code to change the formUrl to your dynamic value. Code below.

 

That should be it! You are now saving pages created using a scaffolding in dynamic locations

12:42 PM Permalink