Design Bug in Naming reTHINK components in DNS prohibits universal deployment of project results

[Endebert]

We've tried to deploy a local set-up of rethink components at the FOKUS testbed, i.e. a catalogue, message node, registry, runtime host, web site that uses the runtime, etc. We encountered the following issue:

Let's assume the catalogue, message node, and registry are deployed / hosted on the following machines:

• catalogue.fokus.fraunhofer.de
• registry.fokus.fraunhofer.de
• msg-node.fokus.fraunhofer.de

Then, the current implementation of the browser runtime requires that the runtime's index.html is retrieved / downloaded from the host fokus.fraunhofer.de.

Obviously, there is no such host fokus in the domain fraunhofer.de.

We believe that there is a semantic bug in the design here as we mandate that semantic overloading of host names vs. (sub)domain names is inherently required by the reTHINK design. Feedback from our IT department indicated that assuming that IT departments allow for such semantic overloading is daring and is not permitted at fraunhofer in general (as establishing further subdomains is also not permitted).

To illustrate the issue further, let's theoretically assume we were allowed to establish a subdomain rethink.fokus.fraunhofer.de.

Then we would have hosts (and corresponding DNS records) named:

• catalogue
• registry
• msg-node

whose fully qualified hostname (i.e. hostname+domainname) were:

• catalogue.rethink.fokus.fraunhofer.de
• registry.rethink.fokus.fraunhofer.de
• msg-node.rethink.fokus.fraunhofer.de

For that configuration, the browser runtime attempts to create an iframe from rethink.fokus.fraunhofer.de/.well-known/runtime/index.html, i.e. it connects to the host rethink in the fokus.fraunhofer.de domain. As we can see here, we have semantic overloading of rethink which is in the latter case a hostname (which is assumed to have a proper DNS record) and in the former cases a (sub)domain name.

Even if in some companies such semantic overloading of DNS records might be supported, we doubt that this approach allows for universal deployment of our developments.

As a solution, we suggest that the runtime is not retrieved from rethink.fokus.fraunhofer.de but instead from runtime.rethink.fokus.franhofer.de. This would resolve the issue of semantic overloading of host and domain names. This would also be closer to the understanding of the domain configuration parameter (see here) in the install() function (which should really be a domain name and nothing else).

Not being sure that we identified all required code to be changed to fix this bug ( @dvilchez , please check further), we believe that only this line has to be changed:

https://github.com/reTHINK-project/dev-runtime-browser/blob/master/src/RuntimeUAStub.js#L91

This means that current testbeds probably have to be adapted to accommodate this change.

As this issue is a blocking factor for us now, please resolve this issue in a timely manner.

I cc the entire project here (@all) as this issue propagates to all developments and testbed installations.

[pchainho]

I agree we should minimise as much as possible constraints on reTHINK deployments and the subdomain based syntax was not a good idea (blame it on me). The usage of the well-known URIs standard should be enough to ensure cross domain interoperability.

Thus, I would rather propose just to remove the rule to use "catalogue" sub-domain in the catalogue URLs.

Another point, is that, probably, the URLs from where the Runtime is downloaded don't have to be standardised, since it doesn't affect interoperability. However, it facilitates portability of Apps among different domains.

Anyway, these changes have to be carefully analysed and should not be implemented in the testbeds before the Review meeting.

[emmelmann-fokus]

I support that we should not role out any such changes before the review meeting. We need a stable environment (the one we had for the advisory board meeting) available for our demos at the review.

This is still not a reason to defer working on the solution right away.

I would still like to push towards discussing this issue now. We can use a dedicated branch to make those changes -- thus not effecting the review -- and then merge this branch into the develop and master branch after the review.

Can we please use this issue to illustrate how you envision that the different (fully qualifying) URLs (i.e., the DNS entries) for the

• catalogue
• registry
• msg-node
• host to get the runtime from (e.g., just call it runtime)

should look like.

We cannot defer the discussion of the solution until after the review as the current situation is a blocker for all of our development activities.

As a technical site note, I personally think @pchainho is right with

Another point, is that, probably, the URLs from where the Runtime is downloaded don't have to be standardised, since it doesn't affect interoperability. However, it facilitates portability of Apps among different domains.

We have a similar convention today when we want to access the web page of a company. We all type www.; so we inherently assume that the web server is hosted on a host named "www". We can establish a similar convention for rethink; we just have to restrict ourselves to specifying "special host names" which should not cause an issue as we have this widely deployed (e.g.: "www"). We just need to through away all assumptions on having a specific structure of the domain.

@pchainho , do you think @dvilchez can start looking at this issue. Maybe he and @Endebert can start working in parallel on a dedicated branch (we can come up with a good name, let's separate it from the develop and master branch) right away?

Thanks for your immediate response. Let's hope we can progress in the next days on the issue.

Best

Marc

[antonroman]

@dvilchez will check if modifying the runtime-browser will be enough to enable that, maybe changes in the runtime-core are necessary.

[dvilchez]

I did the needed changes for the @Endebert's proposal in dev-runtime-browser/dns-naming and it works.

Two considerations:

Google redirect URI mistmatch

Same origin policy https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy

[pchainho]

Since this is related with Interfaces designed in WP2, I've created this issue to discuss it further. We may keep this issue open to discuss specificities to the Core Framework like the impact to our components.

In the meanwhile pls do not deploy anything in the testbeds, especially the ones to be used in the review.