I seem to have solved the system topic problem.
I was unable to get the static permissions working as I was using a dynamic authorizer, and when i provided both the authorizer & permissions keys in the config, it seemed to ignore the custom authorizer and just dump me straight into the permissions which didn’t allow me to customize at a topic level.
I ended up just doing it all through the authorizer and checking things manually:
def authorize(self, session, uri, action):
stripped_uri = uri[len(“com.company.product.”):]
if stripped_uri == ‘system’:
grant everyone read access to system updates
if action == ‘subscribe’:
ben’s temp dumb auth
user = u’user.%s’ % session[u’authid’]
if stripped_uri == user:
And the config looks like this:
This seems to solve my problem - just the question about the secret remains
On Monday, February 16, 2015 at 9:48:26 PM UTC+1, Ben Novakovic wrote:
This was very helpful, thank you!
As for the system updates, you mention “have a topic to which all sessions which have been authenticated as role ‘user’ can subscribe”. How can a user have multiple roles? I attempted to set the authrole to a list in python, but this broke the auth handshake. Ideally I would want the perms on the system topic to be ‘subscribe’ only.
Thanks again for your help!
On Friday, February 13, 2015 at 5:12:00 PM UTC+1, Alexander Gödde wrote:
You can have both a custom dynamic authenticator and a dynamic authorizer component. This gives you the possibility to e.g. use the authenticationID as part of your per-user topic, and verify this upon subscription, i.e. allows implementing your suggested flow.
For general updates, you can e.g. have a topic to which all sessions which have been authenticated as role ‘user’ can subscribe (and this can be statically configured). You can have multiple subscriptions on a single WAMP session (and over a single Websocket connection).
Hope this points you in the right direction.
Am Freitag, 13. Februar 2015 15:47:12 UTC+1 schrieb Ben Novakovic:
TL;DR - is it possible to create the concept of a ‘private’ channel with crossbar eg: 1 realm, many topics, 1 user/topic?
We are currently looking at integrating live updates into our tech stack and crossbar.io looks great, except for one small thing that I am unsure about.
We would like each client to have a websocket connection to the server, and receive updates only applicable for that user. This means that a user can’t see any other users updates, even if they know their ‘topic’ name and attempt to connect directly to it.
Essentially a private channel with just the user, and a HTTP-Pusher service pumping updates to the client.
I (think) the way to do this is:
1.) By creating a single realm, and each user must authenticate to connect to this realm using an auth backend
2.) Get the user to create their own topic based on some id unique to them
3.) When the user attempts to connect to this topic, the authorization handler does a check that this user is infact able to subscribe/create to this topic. If the user doesn’t have the correct authorization - ie hashes don’t match for example, they won’t be able to see the topic, this means that a user can only connect to their specific topic.
Does this sound like a possible implementation of the use case?
Moreover, if we want the user to also receive ‘system’ updates, I’m guessing the user can just subscribe to another topic ie: com.system.updates to get global messages whilst maintaining the existing websocket connection?
Thanks for your time!
Any help whatsoever is appreciated.