One of the problems that AEM had with vanity URLs was that for each vanity URL there needed to be a filter rule that allowed access to the vanity URL in the Dispatcher. This meant that a content author could create a vanity URL and publish it, but it was not available without updates to the Dispatcher and a restart of the web server.
However recent Dispatcher versions (since 4.1.9 I think), there’s a new /vanity_urls setting that enables the dispatcher to get a list of vanity urls from the Publish instance and allow these requests if the request fails the Dispatcher filter (see Enabling Access to Vanity URLs for more info). However there’s a few things that need to be done in order to set this up correctly:
- Download and install the VanityURLS-Components from Package Share if it’s not already installed on your system (Note: This needs to be installed on your Publish instance)
- Go to the user admin of your Publish instance and allow ‘Read’ permission to
/libs/granite/dispatcher/content/vanityUrlsfor the ‘everyone’ group - Add a filter rule in the dispatcher to allow the vanity URL to be called on Publish instance:
/0100 { /type "allow" /url "/libs/granite/dispatcher/content/vanityUrls.html" } - Add a caching rule to prevent caching of this URL:
/0001 { /type "deny" /glob "/libs/granite/dispatcher/content/vanityUrls.html" } - Add the vanity_urls configuration to the farm:
/vanity_urls { /url "/libs/granite/dispatcher/content/vanityUrls.html" /file "/tmp/vanity_urls" /delay 300 } - Restart your webserver
It’s worth noting that the file defined at the /file setting is not automatically created\updated at the time interval set at /delay, but only when a request is made that fails the /filter rules of your Dispatcher. On fail, it checks to see if the file is there – if it’s not there then genrate and use it, otherwise if it is there and is not older that /delay seconds use it, or finally if it it is older than /delay seconds update it from the Publish instance and then use it.
I hope this helps anyone having trouble getting this working as expected.
I've been a developer for over a decade, working with a varied range of products. I'm also an Adobe Certified Expert AEM 6.0 Developer, CQ 5.6 Component Developer, ColdFusion, and Advanced ColdFusion, and a Certified Scrum Master.
Code Monkey 
nice post.
re the rule:
/0100 { /type “allow” /url “/libs/granite/dispatcher/content/vanityUrls.html” }
afaik that should not be done. Dispatcher has access to this URL already. With the rule external visitors (browsers) have access as well. Not good.
Thanks Michael,
When I was trying it out, the dispatcher would return a 404 when trying to access this location. After discussions with Daycare they suggested that I add the location to the dispatcher rules. They also mentioned that some people prefer to give access to a different group (eg anonymous) instead of everyone, and this is part of the reason they did not document this.
Good post. For adding permission to the vanity url node on publish, I don’t think going to useradmin for every publisher is a good idea. Imagine someone with a setup of 20 prod publish servers across multiple data centers. I think it’s better to create an acl package for permission to this node and deploy that
100% agree Abhishek. What I ended up doing was add the ACL to the VanityURLS-Components package, and install it directly on the Publish instances. That way the required code is installed along with the required ACL.
Hi,
we have followed the same steps metioned above but still facing the issue.
Vanity paths are not getting updated in dispatcher.
1) seems the flush from author is happening for content path(original path)..not happenng for the vanity paths on dispatcher.
any leads would be of greater help.
REgards
Surya
Try setting your dispatcher logs to debug and see what is happening to the calls to /libs/granite/dispatcher/content/vanityUrls.html. Also don’t forget that you need to request a page that fails all filter rules (or does not exist) via Dispatcher for the file to be generated in the first place
Hi,
I tried configure vanity URLs for multiple domain.
For example:
one.domain.com/test going to page /sites/site1/page-of-site-1.html
two.domain.com/test going to page /sites/site2/page-of-site-2.html
I used regex in URL but the dispatcher not recognise it.
if entry a vanity URL in format [protocol][host]:[port]/[vanity-url] it not recognise of dispatcher
if entry a vanity URL in format [vanity-url] then if we will add the same urls for both domain we will have one record in /libs/granite/dispatcher/content/vanityUrls.html file. And unclear what page will be opened.
can you help?
Hi Andrey,
Unfortunately this is not really possible with vanity URLs at the moment. I’ve had this come up in the past and spoken to Adobe about it, and the best way to deal with this is to use Resource Mapping, however this is not as author friendly as vanity URLs. An enhancement request for this has been logged so maybe we’ll see it in a future release of AEM.
HI Kris,
I am following the blog to configure vanity url from dispatcher.
Each time I created a new vanity url in Author and activate to publish. I checked /libs/granite/dispatcher/content/vanityUrls.html. it shows up.
But cannot access from the dispatcher. Unless I have to go to Apache Sling Resource Resolver in system console and click on the “save” button. It takes few minutes then access the vanity url from the dispatcher it works fine.
Any advices please help.
Thanks,
Thong
Hi Kris,
With the above approach vanity urls are working in our site, and same vanity url is working for subdomains also . We want whenever parent site vanity url is accessed by user, and if user is on child site(microsite) with different domain than browser url should change to parent site. Can this be possible?
How to clear the dispatcher cache for these vanity pages? I heard there is field called aliasUpdate but even after adding that into author replication agent request is not reaching till Publish box.
Some really excellent information, Glad I found this.
Its a good website. Thanks for giving full information about the Granite Vanity. You can also check at granitess.com