request parameters with vanity url | Community
Skip to main content
cquser_cquser
cquser_cquser
Level 2
October 16, 2015
Solved

request parameters with vanity url

  • October 16, 2015
  • 8 replies
  • 3466 views

We have a requirement in our project that we need to pass request parameters with the vanity url.

So if the vanity url of a page is /vanityurl; the parameter attached would be /vanityurl?param=1&param=b; and the vanity url should get resolved to the page with the parameters and the url in the browser should remain as /vanityurl?param=1&param=b

Is this feasible ? Any pointers will be highly appreciated.

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by ogill

Hi,

there is a similar thread here[1]

First your question about URL parameters, your analytics scripts will run in the browser and send any data to GA from there, so the request reaching the server should not be required. Unless you are doing some processing server side? 

There are two ways you can handle request parameters in your scenario:

1. Deny all parameters. Then identify those parameters used by your codebase and only allow those through. In this case, your marketing team can add whatever they like without it affecting the publish instance. You client side analytics code will send all data to GA. In this scenario, your development team need to be disciplined and be aligned with devops.

2. Allow through all parameters. Identify those parameters to be used by you marketing team and update Apache/dispatcher to block them. Low development overhead but you need strong governance between your marketing and WCM/DEV teams, otherwise the marketing team could bring down your publish instance.

Regards,

Opkar

[1] http://help-forums.adobe.com/content/adobeforums/en/experience-manager-forum/adobe-experience-manager.topic.html/forum__hjr6-dear_all_dispatc.html

8 replies

WhoaShekhar
WhoaShekhar
Level 10
October 16, 2015

Hi There,

Thanks for reaching out to Adobe Community.

Please go through the below community articles and see if they help:

https://helpx.adobe.com/experience-manager/kb/vanity-urls.html

https://helpx.adobe.com/experience-manager/kb/VanityURLs.html

Thanks!

O
Adobe Employee
ogillAdobe Employee
Adobe Employee
October 16, 2015

Hi,

with the arguments at the end of the vanity url, this page would not be cached by dispatcher, is this intended? Would the page really need to be generated with each request.

Regards,

Opkar

cquser_cquser
cquser_cquserAuthor
Level 2
October 16, 2015

Hi,

We can cache the request parameters using the ignoreurlparam  property in the dispatcher; in this way the page would be cached. Can we allow the vanityurl to accept request parameters?

Thanks

O
Adobe Employee
ogillAdobe Employee
Adobe Employee
October 16, 2015

Hi,

vanity urls can be cached and as you say using ignoreurlparam would allow you to cache a url with parameters, so no reason why it can't. Best to test this to make sure it behaves as you want it to. What is your use case for doing this?

Regards,

Opkar

cquser_cquser
cquser_cquserAuthor
Level 2
October 16, 2015

I tried by adding a vanity url testvanityurl?param=1&param=b to a page in a vanilla instance 5.6.1; it does not work; there is no dispatcher involved. There is no specific use case for this; the business uses many vanity urls; they want to add parameters to the url that they can catch at the front end for tracking purposes. Any pointers will be appreciated.

 

Thanks

O
Adobe Employee
ogillAdobe Employee
Adobe Employee
October 16, 2015

If it is for analytics, then what product are you using for analytics? 

The suggestions above would be for caching vanity url's with arguments. The reason you would want to do this is I have seen cases where parameters were not cached, and a retailer had a big release/offer which brought down the server because every request was going to the publish instance.

So you have two issues: how to cache parameter requests and how to capture the request for analytics.

Regards,

Opkar

O
Adobe Employee
ogillAdobe EmployeeAccepted solution
Adobe Employee
October 16, 2015

Hi,

there is a similar thread here[1]

First your question about URL parameters, your analytics scripts will run in the browser and send any data to GA from there, so the request reaching the server should not be required. Unless you are doing some processing server side? 

There are two ways you can handle request parameters in your scenario:

1. Deny all parameters. Then identify those parameters used by your codebase and only allow those through. In this case, your marketing team can add whatever they like without it affecting the publish instance. You client side analytics code will send all data to GA. In this scenario, your development team need to be disciplined and be aligned with devops.

2. Allow through all parameters. Identify those parameters to be used by you marketing team and update Apache/dispatcher to block them. Low development overhead but you need strong governance between your marketing and WCM/DEV teams, otherwise the marketing team could bring down your publish instance.

Regards,

Opkar

[1] http://help-forums.adobe.com/content/adobeforums/en/experience-manager-forum/adobe-experience-manager.topic.html/forum__hjr6-dear_all_dispatc.html

cquser_cquser
cquser_cquserAuthor
Level 2
October 16, 2015

Hi Opkar,

We are using Google analytics for anlytics tracking; and the parameters we want to pass are the UTM codes. We can cache vanity url with with arguments; but as I mentioned earlier; in a simple CQ5 author setup; if on a page I configure a vanity url ; as vanityurl?param1=a&param2=b   and hit the url      http://localhost:4502/vanityurl?param1=a&param2=b  ; I get a resource not found error. I was looking to customize the default vanity url functionality; so that it accepts the query parameters passed; which I can cache later by configuring the dispatcher.

I was looking for the jsp in the foundation page component where the vanity url redirect happens; but couldn't find it. Any help in this direction will be helpful.

Thanks

Terms & ConditionsAccessibility statement

Loading footer...