I'm not really sure about the onDispatch, the only use of it being
called after the messages got dispatch would be add the ability of
logging successfull and failed deliveries, which still can be an
Exactly that would be the purpose.
important feature. But allowing the server to modify the eligible set of
subscribers on each event, as well as the event itself, would be a bit
You can modify the event itself, but not the list of actual receivers,
using a custom publish handler today.
Modifying the eligible list _could_ be done by extending the custom
publish hook, but I am not sure if that's sane: it's no longer PubSub
when who actually gets events has nothing to do with who is subscribed
to a topic, but ... what exactly?
more interesting. Maybe a pair of onPreDispatch and onPostDispatch would
allow for the best flexibility in working with the dispatch of events,
in a standardized way.
I've been looking at the wamp.py file, and opted to move the entire
dispatch of the factory into a custom factory, in order to see how much
control I can get over the dispatched events. Maybe this would be the
solution to the authenticated subscription problem, as well as to the
forced unsubscribe. This would leave the pubsub code unchanged, and
transfer all security measures to the dispatcher. Clients which falied
IMHO, thats a bad idea: you only wanna write a custom pub/sub handler if you really need it .. for auth you dont need it. The design is to
make easy things easy, and complex things possible.
to authenticate via RPC for a specific subscription simply won't get the
messages delivered, and possibly get only one single message at the
beginning telling the client that the subscription is not active. This
would allow the server to stop providing messages to certain clients at
any time. I will focus on that.
Well, this is open-source, so feel free to fork;)
I don't understand what you are saying about only exposing the auth
interface with registerXXX in order to manage subscriptions, could you
please expain this again? Does this mean that I should/could call
self.registerForPubSub("http://example.com/test/ps#", True) in an RPC
call instead of the onSessionOpen? I didn't realize I can set the topics
offered server-side on a per-client basis. Is this what you mean? I'll
Yep, thats what I mean. Just call your registerXXX not in onSessionOpen,
but only in the RPC that finishes your authentication. In onSesssionOpen
you only register the RPCs needed for the auth itself.
Am 04.04.2012 13:29, schrieb Daniel Faust:
test this out. This would still not solve the forced server-side
unsubscribe feature; how could I do that?
On Wed, Apr 4, 2012 at 12:27, Tobias Oberstein > <tobias.o...@gmail.com <mailto:tobias.o...@gmail.com>> wrote:
yep, there is WampServerFactory.dispatch() to generate
server-originating events or for implmenting custom pub/sub handlers.
there currently is no onDispatch() method, but there probably
should be one, which fires when dispatching has finished and
provides the numbers of requested, filtered and actual receivers.
for your point 2) below: that would require both changes to the
WAMP protocol and all WAMP implementations.
the way you can achieve the same effect: initially, have only
called registerXXX to expose the auth interface to the client.
upon the client having authenticated itself, call registerXXX
for the exact set of interface it should be able to use.
the one piece is currently missing (but would be easy to add):
Am 04.04.2012 10 <tel:04.04.2012%2010>:46, schrieb Daniel F.:
Ok, I managed to solve 1) with the dispatch method.
On Wednesday, April 4, 2012 10:09:27 AM UTC+2, Daniel F. wrote:
I'm now able to listen to the events posted to the channel
I still have 2 problems:
1) How can I publish an event directly from the server
2) I'd like to limit access to topics via authentication. I
use RPC so that the client can get a token from the server
can then use in the subscribe call, the server can then
validity of this token and allow the subscription to the
also unsubscribe (kick) the client from the topic at any
token could be removed if the @exportSub would allow to read the
session id of the client attempting to subscribe, and it
be used to decide if this is a client which should get
or not. Is this possible?
On Wednesday, April 4, 2012 12:59:05 AM UTC+2, Daniel F. wrote:
I'm currently checking out the pubsub functionality. Is
way for a server to "tap into" a topic it registered?
to have an event handler on the server which can listen
topics it registeres, for logging purposes (ie insert
into a database), and publishing to them for just in
posting a "server is shutting down in 1 min.")
Is this possible without creating a client in the same
on another port and having it connect via ws to the server?