Implement dynamic logic for CORS request filtering

[otsakir]

Which CORS requests should get responses with Allow-* headers ? We can do one of the following:

Use a configuration list defined by an administrator.

For example define a new section in restcom.xml like the following:

<corsWhitelist>
	<origin>http://foo.restcomm.com</origin>
</corsWhitelist>

and add the necessary configuration scripts to populate this configuration from restcomm.conf/advanced.conf

Set up a convention

Set up a convention based on the destination name of the request. For example if the incoming request targeted domainA.restcomm.com return an Access-Control-Allow-Origin header like Access-Control-Allow-Origin=rvd.domainA.restcomm.com.

@deruelle , @leftyb thoughts ?

Or of course we could support both ways.

[deruelle]

@otsakir the second option makes more sense to me so far so it stays dynamic and as new domains are added no additional configuration is required.

[otsakir]

ok @deruelle , but what about the convention itself ? does it feel right ?

@lefty ?

[otsakir]

Also, some more thinking...

The issue relates to this:
#2212

The <rcml-server/> configuration section was initially created for the notifications sent to RVD when an account was removed. I'm wondering whether it makes sense to use it for bootstrapping the CORS filter.

Btw, @deruelle , it's not only about cloud. It makes sense to be able to use an arbitrary RVD address (i.e. a configurable one, not a convention-based one) for more flexibility.

[deruelle]

Good point, we should have a simple way to configure the mapping in that case corresponding to your logic below

For example if the incoming request targeted domainA.restcomm.com return an Access-Control-Allow-Origin header like Access-Control-Allow-Origin=rvd.domainA.restcomm.com.

[otsakir]

@deruelle , after discussion with @leftyb , we agreed to take advantage of existing rcmlsesrver-api configuration section in restcomm.xml which points to the RCML server/rvd. It was initially created for sending notifications when an account was removed.

Here is a sample:

	<rcmlserver-api>
		<base-url>/restcomm-rvd/services</base-url>
		<notifications>true</notifications>
		<timeout>5000</timeout>
		<timeout-per-notification>500</timeout-per-notification>
	</rcmlserver-api>

<base-url/> holds a relative url. The idea is to have CorsFilter check _base-url and if it's absolute, apply the CORS allow logic and return headers appropriately.

The section above should probably be refactored to the following to better reflect current state of codebase:

	<rcmlserver>
                <base-url>http://rvdserver.restcomm.com:8081</base-url>
		<api-path>/restcomm-rvd/services</path>
		<notifications>true</notifications>
		<timeout>5000</timeout>
		<timeout-per-notification>500</timeout-per-notification>
	</rcmlserver>

As far as i remember there are no major dependencies of this section other than RcmlserverApi class.

Another issue should be created to handle setting restcomm.xml/rcmlserver appropriately

[otsakir]

Also @deruelle , regarding your comment

@otsakir the second option makes more sense to me so far so it stays dynamic and as new domains are added no additional configuration is required.

If you what you mean is to have a restcomm instance hooked up to multiple RVD instances in different domains each, i see no easy way to do this.

• Think a little what happens with the 'Visual Designer' link that appears in Dashboard. Where will it point to ? Probably it should get removed altogether.
• What about metadata information retrieved from RVD for a set of applications in the 'Apps' ? We need to check the application URL and contact the respective app server. Will this scale ?
• What about notifications to RVD when an account is removed ?
• What happens with the absolute links to the RCML controller that are stored in the Application. Where will they point to ?

We need to be very careful when drafting this out and always have in mind what happens with the storage layer behind the servers. Will it be shared or not ?

[deruelle]

@otsakir what I mean is multi-tenancy ie that a given Restcomm Connect instance can manage many organizations (domains) and so should RVD. At any given point in time though a given Restcomm Connnect can send a request only for the domain it is currently processing the request for ie a request for cloud.restcomm.com will only go to rvd.cloud.restcomm.com never to rvd.anotherorg.restcomm.com by example

[otsakir]

ok @deruelle, i see. So there should be some kind of logic both in the client and the server. In the client (Dashboard) it will be able to guess rvd's location from restcomm's location (i.e. where index.html was retrieved from) and in the server it will check for Origin header in the inverse way. So, yes, we're definitely talking about a convention here.

This seems part of another round of tasks. I think we can proceed with using configuration based allowwed origins for now (already mostly implemented) and review this as part of the organization work.

wdyt ?