:orphan: Router Realms ============= Crossbar.io uses *Realms* as domains for separation of routing and administration. Every WAMP session between Crossbar.io and a *Client* is always attached to a specific *Realm*. Since the routing of calls and events is separate for each realm, sessions attached to different realms won't "see" each other. For example, consider - Client 1 attached to ``realm1`` - Client 2 attached to ``realm1`` - Client 3 attached to ``realm2`` on the *same* Crossbar.io router, and both Client 2 and Client 3 subscribed to topic ``com.example.mytopic``, when Client 1 publishes an event to ``com.example.mytopic``, only Client 2, which is attached to the *same realm* as Client 1, will receive this event. The realm for the session is selected as part of session establishment. For example, when creating a new connection to a WAMP router using `Autobahn\|JS `__, the realm the session (running over the connection) should attach to is specified like this: .. code:: javascript var connection = new autobahn.Connection({url: 'ws://127.0.0.1:9000/', realm: 'realm1'}); Configuring Realms on a Router ------------------------------ Realms are created on a *Router* as part of the *Router* configuration\`: .. code:: javascript { "version": 2, "controller": { }, "workers": [ { "type": "router", "options": { // any router options }, "realms": [ { "name": "realm1", "roles": [ { "name": "anonymous", "permissions": [ { "uri": "*", "allow": { "call": true, "register": true, "publish": true, "subscribe": true } } ] } ] } ], "transports": [ // transports run by this router ], "components": [ // app components running side-by-side with this router ] } ] } In the above example configuration, the *Router* starts up with a single *Realm* (``realm1``). Authorization is configured on a per-realm basis. Authorization is role-based. Above, clients connecting as anonymous have full permissions for all URIs. (This makes sense for starting out development of a WAMP application.) Realm Options ------------- Crossbar.io allows to tune its routing core on a per-realm basis using *realm options*. For example, consider this part of a node configuration for a realm: .. code:: javascript { // realm name "name": "realm1", "options": { // if true (default), enable WAMP meta API "enable_meta_api": true, // if true, bridge the WAMP meta API also to the node management side "bridge_meta_api": false, // dispatch this many events before reentering the event loop "event_dispatching_chunk_size": 100, // checking policy for URIs (can be "strict" or "loose") "uri_check": "strict" }, "roles": [ // role definitions ... ] } The realm options change the default behavior of Crossbar.io for the whole realm. Other realms in the same router worker are unaffected though. The options are provided at startup time of the realm within the router worker, and are unchanged during the lifetime of that realm. Changing an option requires to restart the respective realm. However, the router worker within the realm is started, does not need to be restarted itself. Restarting a realm is a quick and cheap operation. *Read more:* - :doc:`Router Configuration ` - :doc:`Authorization `