Cloudstack 4.2.x Loadbalancer Stickness Policies

Recently while updating an application to consume the cloudstack 4.2.x API I started to run against some issues regarding the loadbalancer stickness policy attribute validation.

On version 4.1.x and lower the API CreateLBSticknessPolicy would accept the policy attributes as raw values, however, on 4.2.x it started to complain about some validation rules.

Screen Shot 2014-02-05 at 12.20.22 PM

There are several things wrong here, lets start from the beginning:

The rest api has a very rudimentary interface to deal with policy parameters, instead of defining a key for each supported parameter it forces you to create a string matching this format


That’s not even a json obejct/array. It is just a plain string which creates some overhead when you are consuming the api since you need to parse the params manually.
Plus there is no way to know which attributes are valid or not, you need to dig in on the documentation or the source code to see what is accepted by the api.

Leaving the api interface aside, I started to look at the UI to check which format they were sending the requests. To my surprise I got the same error I was getting when consuming the api from a third party app.
Screen Shot 2014-02-05 at 12.25.39 PM

As you can see from the picture above there is not indication of what the format should be.
Looking at their docs there is also no mention.

With no choice I had to dig through their source code.
Doing a full search on the project for the string “Failed LB in validation rule id
I found two occurrences:

This is the piece that does the validation:

 public static boolean validateHAProxyLBRule(LoadBalancingRule rule) {  
 String timeEndChar = "dhms";

 for (LbStickinessPolicy stickinessPolicy : rule.getStickinessPolicies()) {  
 List> paramsList = stickinessPolicy  

 if (StickinessMethodType.LBCookieBased.getName().equalsIgnoreCase(  
 stickinessPolicy.getMethodName())) {

 } else if (StickinessMethodType.SourceBased.getName()  
 .equalsIgnoreCase(stickinessPolicy.getMethodName())) {  
 String tablesize = "200k"; // optional  
 String expire = "30m"; // optional

 /* overwrite default values with the stick parameters */  
 for (Pair paramKV : paramsList) {  
 String key = paramKV.first();  
 String value = paramKV.second();  
 if ("tablesize".equalsIgnoreCase(key))  
 tablesize = value;  
 if ("expire".equalsIgnoreCase(key))  
 expire = value;  
 if ((expire != null)  
 && !containsOnlyNumbers(expire, timeEndChar)) {  
 throw new InvalidParameterValueException(  
 "Failed LB in validation rule id: " + rule.getId()  
 + " Cause: expire is not in timeformat: "  
 + expire);  
 if ((tablesize != null)  
 && !containsOnlyNumbers(tablesize, "kmg")) {  
 throw new InvalidParameterValueException(  
 "Failed LB in validation rule id: "  
 + rule.getId()  
 + " Cause: tablesize is not in size format: "  
 + tablesize);

 } else if (StickinessMethodType.AppCookieBased.getName()  
 .equalsIgnoreCase(stickinessPolicy.getMethodName())) {  
 * FORMAT : appsession len timeout  
 * [request-learn] [prefix] [mode  
 * ]  
 /* example: appsession JSESSIONID len 52 timeout 3h */  
 String cookieName = null; // optional  
 String length = null; // optional  
 String holdTime = null; // optional

 for (Pair paramKV : paramsList) {  
 String key = paramKV.first();  
 String value = paramKV.second();  
 if ("cookie-name".equalsIgnoreCase(key))  
 cookieName = value;  
 if ("length".equalsIgnoreCase(key))  
 length = value;  
 if ("holdtime".equalsIgnoreCase(key))  
 holdTime = value;  

 if ((length != null) && (!containsOnlyNumbers(length, null))) {  
 throw new InvalidParameterValueException(  
 "Failed LB in validation rule id: " + rule.getId()  
 + " Cause: length is not a number: "  
 + length);  
 if ((holdTime != null)  
 && (!containsOnlyNumbers(holdTime, timeEndChar) && !containsOnlyNumbers(  
 holdTime, null))) {  
 throw new InvalidParameterValueException(  
 "Failed LB in validation rule id: " + rule.getId()  
 + " Cause: holdtime is not in timeformat: "  
 + holdTime);  
 return true;  

Which is the same in both classes, only difference is the formatting.
Actually, the whole class re-implements most methods, not sure why they can’t share a helper class or extend some base class that implements the common methods.
Might be that they are treated as separated projects so there are some dependencies overhead involved.
Anyway, the validation itself is pretty straight forward for SourceBased rules:

  • table size attribute must end with k, m or g
  • expire attribute must end with d, h, m, or s.

Enabling CORS on a node.js server, Same Origin Policy issue

Recently we faced the famous “XMLHttprequest doesn’t allow Cross-Origin Resource Sharing” error.

To overcome the problem a very simple solution was needed.

Below I’ll try to give a quick overview of what is CORS and how we managed to work around the issue.

Cross-Origin Resource Sharing – CORS

In a nutshell CORS is the mechanism that allows a domain to request resources from another domain, for example, if domain http://websiteAAA tries to request resources from http://websiteBBB the browser won’t allow it due to Same Origin Policy restrictions.

The reason for having Same Origin Policy rules applied on the browser is to prevent unauthorized websites accessing content they don’t have permissions for.

I found a great example that emphasizes the need to have Same Origin Policies enforced by the browser: Say you log in to a service, like Google for example, then while logged in you go and visit a shady website that’s running some malware on it. Without Same Origin Policy rules, the shady website would be able to query Google with the authentication cookies saved in the browser from your session, which of course is a huge vulnerability.

Since HTTP is a stateless protocol, the Same Origin Policy rules allow the browser to establish a connection using session cookies and still keep each cookie private to the domain that made the request, encapsulating the privileges of each “service” running in the browser.

With that being said, imagine a situation where you, as a developer, need to communicate with an API sitting on a different domain. In this scenario you don’t want to hit the Same Origin Policy restrictions.

Workaround 1 – Request resources from a server

The most common way to get around this problem is to make the API request from your own server, where Same Origin Policy rules are not applied, and then provide the data back to the browser. However, this can be exploited:

Last semester I created an example of how an attacker would be able to spoof whole websites and apply a phishing attack circumventing Same Origin Policy restrictions.
The attack structure was very similar of how ARP poisoning is done.

A very brief overview of the attack:

  1. The user would land on a infected page
  2. The page would load a legitimate website by making a request from the attacker’s server where Same Origin Policies are not applied.
  3. The attacker would inject some code in the response to monitor the vicitms activity
  4. After the victm’s credentials were stolen he would stop the attack and redirect the user to the original requested page.

By spoofing the victim’s DNS it would make even harder to detect the attack, but even without DNS spoofing this approach would still catch some careless users.

All the code for the example is available on github
The attack was built on top of a nodeJS server and socketIO
The presentation slides for the attack can also be found here

Workaround 2 – JSONP

Another way to circumvent the problem is by using JSONP (JSON Padding). The wikipedia articles summarizes in a clear and simple way how JSONP works.

The magic of JSONP is to use a script tag to load a json file and provide a callback to run when the file finishes loading.

An example of using JSONP with jquery:

[sourcecode language=”javascript”]
url: "http://website.com/file.json
dataType: ‘jsonp’,
success: function (data) {
// Manipulate the response here

Even though making requests from your server or using JSONP can get around the Same Origin Policy restrictions it is not the best solution, which is why CORS started being implemented by the browser vendors.

With CORS a server can set the HTTP headers of the response with the information indicating if the resources can or can’t be loaded from a different origin.

If you are curious and want to snoop around looking into the HTTP response headers of a page, one way to do that is to use the developers tools that come with WebKit.
Below is a screenshot of all the resources loaded by the stack overflow home page.
Screen Shot 2013-02-14 at 6.34.24 PM

As you can see in the screenshot, the script loaded from careers.stackoverflow.com/gethired/js had the following HTTP header options appended to its response:

  • Access-Control-Allow-Headers
  • Access-Control-Allow-Methods
  • Access-Control-Allow-Origin

That means that if you want to make an ajax call to carrers.stackoverflow.com/gethired/js from your own page, the browser will not apply Same Origin Policy restrictions since the careers.stackoverflow server has indicated that the script is allowed to be loaded from different domains.
*An important note to make is that only the http://careers.stackoverflow.com/gethired/js has the Same Origin Rules turned off, however, the careersstackoverflow.com domain still has them enabled on other pages.

This means you can enable the header options on a response level, making sure a few API calls are open to the public without putting your whole server in danger of being exploited.

This lead us to our problem.

The Problem

In the set up we currently have, one computer plays the role of the API server and we were trying to query that API asynchronously from the browser with a page being served from a different domain.

The results, as expected, were that the call was blocked by the browser.


Instead of hacking around and trying to make the requests from a different server or using JSONP techniques we simply added the proper header options to the responses of the API server.

We are building our API on a nodeJS server, and to add extra headers options to the response could not have been easier:

First we added the response headers to one of the API calls and it worked perfectly, however we wanted to add the option to all our API calls, the solution: use a middleware.

We created a middleware which sets the response header options and pass the execution to the next registered function, the code looks like this:

[sourcecode language=”javascript”]
//CORS middleware
var allowCrossDomain = function(req, res, next) {
res.header("Access-Control-Allow-Origin", "*");
res.header("Access-Control-Allow-Headers", "X-Requested-With");

app.configure(function () {
app.set(‘port’, config.interfaceServerPort);
app.set(‘views’, dirname + ‘/views’);
app.set(‘view engine’, ‘jade’);
dirname, ‘public’)));

app.configure(‘development’, function(){

// API routes
app.get(‘/list/vms’, routes.listGroup);
app.get(‘/list/vms/:ip’, routes.listSingle);
app.get(‘/list/daemons’, routes.listDaemons);

That’s it for CORS, later we’ll cover another cool header option, the X-Frame-Options

If you are interested in finding more about Same Origin Policy or CORS check out this links: