Settle on regex for valid realm names

[petri]

Currently this is not possible: configuring a realm name consisting only of numbers makes crossbar start fail.

For example I have a case where I'd like to autogenerate realms from unique company identifiers (all numbers).

Workaround: add a letter anywhere in the name.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/38277592-settle-on-regex-for-valid-realm-names?utm_campaign=plugin&utm_content=tracker%2F462544&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F462544&utm_medium=issues&utm_source=github).

[meejah]

@petri can you give some more details? Using latest crossbar under Python3 and Python2 I can start up a simple example with a "guest" session connecting via a realm called "999" in the config.

[meejah]

that is, something like this:

            "realms": [
                {
                    "name": "999",
                    ...

[petri]

I was using YAML configuration. Apparently it's ok to use (unquoted) values for realm as long as they include at least one non-numeric character; the realm value is then understood to be a string.

Whereas if the (unquoted) value is all-numeric, it's considered a number and thus an error is raised.

Quoting the value makes it possible to use all-numeric realms using YAML configuration, as well.

I think this is mostly (if not completely) because how the YAML parser works. Should've checked that first I guess.

[meejah]

Ah, I see -- so the real issue here is that you really are passing a "not-string" (i.e. the integer 999) because of the use of YAML? I suppose we could just run anything for real-IDs through str() but I could see that going wrong, too.

Could the error-message be improved? (i.e. what error were you seeing when you did this?)

[petri]

Yes. Here's the snippet from crossbar log starting when things go wrong. Everything before this is normal (the previous message tells 'realm started'):

2016-10-31T11:16:06+0200 [Router 5192] NativeWorkerSession.onUserError 2016-10-31T11:16:06+0200 [Controller 5185] wamp.error.runtime_error: 2016-10-31T11:16:06+0200 [Controller 5185] sending TERM to subprocess 5192 2016-10-31T11:16:06+0200 [Controller 5185] waiting for 5192 to exit... 2016-10-31T11:16:06+0200 [Router 5192] Native worker received SIGTERM - shutting down .. 2016-10-31T11:16:06+0200 [Router 5192] Shutdown of worker requested! 2016-10-31T11:16:06+0200 [Router 5192] Connection to node controller closed cleanly 2016-10-31T11:16:06+0200 [Controller 5185] Native worker connection closed cleanly. 2016-10-31T11:16:06+0200 [Controller 5185] Node worker worker-001 ended successfully 2016-10-31T11:16:06+0200 [Controller 5185] Node worker ended, and trigger 'shutdown_on_worker_exit' active 2016-10-31T11:16:06+0200 [Controller 5185] Node shutting down .. 2016-10-31T11:16:06+0200 [Controller 5185] Shutting down node...

So yes, error message could be more useful. I tried with a DEBUG loglevel, too, but that was not of any more help than the above, really.

[oberstet]

My current thinking is: we should not allow arbitrary realm names (arbitrary Unicode strings), to facilitate reuse of realm names for other purposes as well.

Analog thinking goes for URI segments in WAMP procedure URIs: if these are valid identifiers (in most languages), this facilitates more uses: eg a client library can map WAMP procedure to native client language procedure (as the URI segments are valid identifiers in the programming language).

Eg if realm names are proper URL path segments and valid DNS domain names, this makes sure realm names can be used as part of HTTP/WS scheme URLs and as subdomains, eg.

• wss://example.com/myrealm-001
• wss://myrealm-001.example.com or rss://myrealm-001.example.com

The former allows a WebSocket aware reverse proxy to route incoming WebSocket connections based on the URL segment in wss://example.com/<realm>.

The latter allows to route incoming WebSocket and RawSocket connections to be routed based on DNS.

Of course whatever we finally agree on, that should be propertly documented and logged if an invalid realm name is used.