On Friday, 23 March 2012 16:44:00 UTC-4, Tobias Oberstein wrote:
> But yes, I think the feature would be useful in the protocol to
> client know they're not authorized after a pub/sub attempt.
> I've come across 4 scenarios where I'd like to notify the user
> not subscribe or publish:
> * User attempts to subscribe to topicURI
> is not allowed
> * User has successfully subscribed to topicURI
> http://example.com/authorized but later has his privileges
> server stops sending him messages in that channel
> * Use attempts to publish to topicURI http://example.com/readOnly
> not allowed
> * The server logic is "you can only publish to channels you're
> subscribed to" and user tries to publish to a topicURI he/she is
Those are all valid use cases IMHO .. the last one probably more being
a specific policy.
First, I've created a Wiki page so we can collect use cases /
requirements at 1 place
Then, up till now, I collected a couple of unsolved issues with WAMP
on the AutobahnPython repo .. since WAMP (the proto def / spec) is
only now split off:
which - in terse form;) - goes in the same direction as your use cases.
Here are a couple of first thoughts:
If it would only be about feedback upon a client subcribes/publishes,
then that could be done by a pattern like RPC .. sub/pub could even
be RPCs .. only the delivered events needed to have a different
"pattern" .. unsolicited message.
However, the feedback for _revoking_ a grant _during_ a session are
Also, the stuff in #64 is non-RPC-like.
With these, there isn't any "callid" to correlate the incoming msg.
For these reasons, I was more thinking in the direction of having
"meta events" on a channel.
There is the message type
EVENT = [ TYPE_ID_EVENT , topicURI , event ]
There could be a new one
METAEVENT = [ TYPE_ID_METAEVENT , topicURI , <t.b.d.> ]
The <t.b.d.> could be quite flexible to transport metainfo things
This may be one option. We should think about this from different
angles .. see if it could work .. see if there are other options.
For example: what happens if I do:
sess.subscribe("topic1", onEventHandler, onMetaEventHandler);
.. time goes by .. I receive meta event: "topic1", GRANT_PUB | GRANT_SUB
upon that happening, I do
.. time goes by .. server revokes pub right
.. I receive the metaevent: "topic1", REVOKED_PUB
How do I know which of evt1 and/or evt2 made it?
There is at least 1 WAMP open Q in the same area:
Since as it stands, WAMP PubSub subscriptions are on
concrete "topic URIs".
I can only have 1 subscription on a given URI.
I cannot have a subscription of a "prefix URI" .. that is essentially
a subscription on a set of URIs .. all URIs with a certain prefix.
Its _not_ like
mySubscription1 = sess.subscribe(<topic A>)
mySubscription2 = sess.subscribe(<topic A>)
=> still subscribes on <topic A> via mySubscription2
Its _not_ like
mySubscription1 = sess.subscribe(<topic A>, subPrefix = true);
receiving events for all like
Ok, enough first thgouhts;)
> On Friday, 23 March 2012 12:18:27 UTC-4, Tobias Oberstein wrote:
> Hi Chris,
> Am 23.03.2012 15:59, schrieb Chris Boden:
> > In writing a couple applications I have desired the
> > deny access to clients on the pub/sub part of WAMP. For example, if
> > building a chat two people have subscribed to their own private
> room. I
> > would like the ability to deny access to other people publishing or
> > subscribing to that topicURI. I've been able to just ignore
> messages on
> > the server side, but not able to verbosely tell the client their
> > were denied.
> So that sounds as you know about the
> stuff, but missing a feedback to client, not just "silent" discard on