Starting in Abiquo 3.0 the client is HTML. This means that how security and login works differs from previous versions. Now security beyond first login is enforced with cookies. This means that it is the browser that must send the cookie back to the API. This mechanism is described here.
The upload/download of templates is made through a direct connection to the Appliance Manager. Then it sends a request to the API to check whether the user is authorized to perform the requested action. This request is basically a replica of the original request to the Appliance Manager.
In a multi datacenter environment API and AM might not be on the same host. This prevents the cookie from being sent, therefore the identity cannot be established. Even if CORS is working this will only allow the result (401) to travel back to the client. To allow the identity to be established, all Appliance Manager instances must reside in the same domain as the API.
This document describes how to set up a very basic Apache 2 to allow for multiple Appliance Manager instances under an 'example.com' domain. All configuration related to other webapps is omitted.
In the file 'client-config.json' the value of the API location must be set to 'example.com':
To ease the configuration it is very convenient that all hosts work on a domain/hostname basis rather than IPs or even 'localhost'.
The domain 'example.com' must resolve to the host. The easiest way is to also set the hostname.
There are two ways to configure an Apache instance. Appliance Manager instances can be exposed either as a path (example.com/am-sweden) or through a subdomain (am-sweden.example.com). The configuration here will show how to set up both in the same configuration file.
The trick here is to modify cookies in the response to add the domain. This enables the browser to send the cookie to 'example.com', 'am-sweden.example.com', 'example.com/am-sweden'. To perform this operation the 'mod-header' needs to be in the Apache.