WAMP permissions

#1

In writing a couple applications I have desired the functionality to 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 actions were denied.

I know I can create this ability by setting up other topicURI channels and creating a sub-system, but I think this would be a nice feature of the WAMP protocol its self.

Thoughts?

0 Likes

#2

Hi Chris,

···

Am 23.03.2012 15:59, schrieb Chris Boden:

In writing a couple applications I have desired the functionality to
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 actions
were denied.

So that sounds as you know about the

AutobahnPython/examples/pubsub/authorization

stuff, but missing a feedback to client, not just "silent" discard on server?

0 Likes

#3

hah, neat! I had no knowledge what so ever. I’ve used WAMP/AutobahnJS with a PHP WebSocket library and written similar code in that language. I’ve only looked at JS code and documentation.

But yes, I think the feature would be useful in the protocol to let the 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 they can not subscribe or publish:

  • User attempts to subscribe to topicURI http://example.com/private and is not allowed

  • User has successfully subscribed to topicURI http://example.com/authorized but later has his privileges revoked, the server stops sending him messages in that channel

  • Use attempts to publish to topicURI http://example.com/readOnly but is 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 not in

···

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 functionality to
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 actions
were denied.

So that sounds as you know about the

AutobahnPython/examples/​pubsub/authorization

stuff, but missing a feedback to client, not just “silent” discard on
server?

0 Likes

#4

But yes, I think the feature would be useful in the protocol to let the
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 they can
not subscribe or publish:

* User attempts to subscribe to topicURI http://example.com/private and
is not allowed
* User has successfully subscribed to topicURI
http://example.com/authorized but later has his privileges revoked, the
server stops sending him messages in that channel
* Use attempts to publish to topicURI http://example.com/readOnly but is
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 not in

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

https://github.com/tavendo/wamp/wiki/PubSub-Feedback

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:

https://github.com/tavendo/AutobahnPython/issues?labels=wamp&sort=created&direction=desc&state=open&page=1

In particular:

https://github.com/tavendo/AutobahnPython/issues/65

which - in terse form;) - goes in the same direction as your use cases.

And then:

https://github.com/tavendo/AutobahnPython/issues/64

···

===

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 necessarily non-RPC-like.

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
like above.

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

sess.publish("topic1", evt1);

.. time goes by .. server revokes pub right

sess.publish("topic1", evt2);

.. 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:

https://github.com/tavendo/AutobahnPython/issues/63

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>)

mySubscription1.unsubscribe()

=> still subscribes on <topic A> via mySubscription2

but:

sess.subscribe(<topic A>)
sess.unsubscribe(<topic A>)

Its _not_ like

mySubscription1 = sess.subscribe(<topic A>, subPrefix = true);

receiving events for all like

<topic A>
<topic A/foobar>
<topic A/subbar2>

...

Ok, enough first thgouhts;)

\Tobias

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 functionality to
     > 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
    actions
     > were denied.

    So that sounds as you know about the

    AutobahnPython/examples/​pubsub/authorization

    stuff, but missing a feedback to client, not just "silent" discard on
    server?

0 Likes

#5

I see you’ve been thinking about this longer than I have. :slight_smile:

“Those are all valid use cases IMHO … the last one probably more being a specific policy.”

I completely agree. I wanted to point it out as it would seem like a common requirement. I think, from a technical perspective, it would be handled the same as my #3 example, but be the decision of the developers server application.

I think I like the idea of Meta Events more than RPC on the PubSub. Although, an acknowledgement or error on a Sub might make sense. Would a sub need an ID though? Would a user attempt to make 2 subscriptions to the same URI? I would think the topicURI as context would be enough.

-What if, instead of ALLOW_SUB and REVOKE_SUB there was just DENY_URI. If the use tried to Sub w/o authentication, has access revoked, or tries to publish to a URI w/o auth, they receive the same error of “DENY_URI on topicURI” with a human message? In your continuity example that would satisfy both errors.-

Although, being async, the user would receive two error messages without real context…so, forget my thinking out loud idea.

···

===

On ticket #63 - I never would expect sub-prefix functionality.

My take on WAMP was that because everything was URI based I thought REST from the get-go. More specifically, HATEOS.

If I were to make a Twitter like app built on WAMP, I would expect functionality like this:

ppl = sess.subscribe(‘http://wamp.ws/users’);

ppl.event -> {chris: ‘http://wamp.js/users/chris’, tobias: ‘http://wamp.ws/users/tobias’}

tobias = sess.subscribe(‘http://wamp.ws/users/tobias’);

tobias.event -> {src: ‘http://wamp.ws/users/tobias’, msg: ‘Hello World!’, on: 1332776748}

Subscribing to /users would give me names of people as they join. From there, I can subscribe to those users to see messages published by them.

Subscribing to a URL would give me discoverable URIs to subscribe to.

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 let the
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 they can
not subscribe or publish:

  • User attempts to subscribe to topicURI http://example.com/private and
    is not allowed
  • User has successfully subscribed to topicURI
    http://example.com/authorized but later has his privileges revoked, the
    server stops sending him messages in that channel
  • Use attempts to publish to topicURI http://example.com/readOnly but is
    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 not in
    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

https://github.com/tavendo/wamp/wiki/PubSub-Feedback

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:

https://github.com/tavendo/AutobahnPython/issues?labels=wamp&sort=created&direction=desc&state=open&page=1

In particular:

https://github.com/tavendo/AutobahnPython/issues/65

which - in terse form;) - goes in the same direction as your use cases.

And then:

https://github.com/tavendo/AutobahnPython/issues/64

===

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
necessarily non-RPC-like.

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
like above.

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

sess.publish(“topic1”, evt1);

… time goes by … server revokes pub right

sess.publish(“topic1”, evt2);

… 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:

https://github.com/tavendo/AutobahnPython/issues/63

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()
mySubscription2 = sess.subscribe()

mySubscription1.unsubscribe()

=> still subscribes on via mySubscription2

but:

sess.subscribe()
sess.unsubscribe()

Its not like

mySubscription1 = sess.subscribe(, subPrefix = true);

receiving events for all like

Ok, enough first thgouhts;)

\Tobias

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 functionality to
 > 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
actions
 > were denied.

So that sounds as you know about the

AutobahnPython/examples/​pubsub/authorization

stuff, but missing a feedback to client, not just "silent" discard on
server?
0 Likes

#6

Hi Chris,

I am right now collecting all the loose ends for WAMPv2 as GitHub
issues.

That should allow us to have discussion either here or there, but
collect the concrete issues systematically on GitHub (rather them being
lost in mail threads on this list).

I see you've been thinking about this longer than I have. :slight_smile:

Yeah. Even more so: I wanted to "incubate" ideas in subconsciousness
for a while;) And also gain practical experience.

"Those are all valid use cases IMHO .. the last one probably more being
a specific policy."
I completely agree. I wanted to point it out as it would seem like a
common requirement. I think, from a technical perspective, it would be
handled the same as my #3 example, but be the decision of the developers
server application.

agree.

I think I like the idea of Meta Events more than RPC on the PubSub.

me too. RPC is RPC. its something different and we shouldn't mix stuff up.

Although, an acknowledgement or error on a Sub might make sense. Would a
sub need an ID though? Would a user attempt to make 2 subscriptions to
the same URI? I would think the topicURI as context would be enough.

I think I agree also here. Let me rephrase, to be sure we mean the
same.

I either have a subscription on a topic or not. A subscription isn't an
entity for itself, which would then need some kind of ID (not URI), since it's something temporary. Anyway, no.

The subscription is to the topic like a call is to a procedure.

topic and procedure are identified by URI.

calls need an ID, but only to correlate the result. The call ID is
NOT visible to the app.

So yeah, lets keep it simple:

A subscription ACK or DENY or REVOKE for a topic is just a metaevent
on that topic:

On the wire:

[SUBSCRIBE,
    "http://awesometopic#1"]

=>

[METAEVENT,
     "http://awesometopic#1",
     "http://wamp.ws/pubsub#subscription-denied",
     {"desc": "Topic is closed on Weekdays!",
      "validdays": [6, 7]}]

From JS:

sess.subscribe("http://awesometopic#1", onEvent1, onMetaEvent1);

function onMetaEvent1 (topic, metatopic, metaevent) {

  // topic == "http://awesometopic#1"
  // metatopic == "http://wamp.ws/pubsub#subscription-denied"
  // metaevent == {.. stuff above..}
}

-What if, instead of ALLOW_SUB and REVOKE_SUB there was just DENY_URI.
If the use tried to Sub w/o authentication, has access revoked, or tries
to publish to a URI w/o auth, they receive the same error of "DENY_URI
on topicURI" with a human message? In your continuity example that would
satisfy both errors.-
Although, being async, the user would receive two error messages without
real context...so, forget my thinking out loud idea.

metatopic's : could be i.e.

Authorization:
ACK http://wamp.ws/sub#ok
DENY http://wamp.ws/sub#denied
REVOKE http://wamp.ws/sub#revoked

Presence/"Rooms"
JOIN http://wamp.ws/sub#joined
LEFT http://wamp.ws/sub#left

In a way, above schema would allow quite some freedom as to what servers
implement, enforce and what clients use.

Extensibility. Some nicely minted, well-known URIs for the most common
use cases would of course be neat. Together with spec for "metaevent"
payload. But that could be split off from definition of base protocol
format ..

===

On ticket #63 - I never would expect sub-prefix functionality.

My take on WAMP was that because everything was URI based I thought REST
from the get-go. More specifically, HATEOS.
If I were to make a Twitter like app built on WAMP, I would expect
functionality like this:

ppl = sess.subscribe('http://wamp.ws/users');
ppl.event -> {chris: 'http://wamp.js/users/chris', tobias:
'http://wamp.ws/users/tobias'}
tobias = sess.subscribe('http://wamp.ws/users/tobias');
tobias.event -> {src: 'http://wamp.ws/users/tobias', msg: 'Hello
World!', on: 1332776748}

Subscribing to /users would give me names of people as they join. From
there, I can subscribe to those users to see messages published by them.

Subscribing to a URL would give me discoverable URIs to subscribe to.

Ok. I see. I need to think about that. It is thoroughly simple, which
I always like. It avoids complexities dealing with prefix subscriptions,
not to speak of general wildcard subscriptions (where the * does not
appear at the end, but somewhere in the middle). I think and come back
to that one ..

Cool! Feedback is helpful;) This is getting somewhere!! Lets close the
loop, do v2 and rock..

Cheers,
Tobias

···

Am 26.03.2012 17:50, schrieb Chris Boden:

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
    let the
     > 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
    they can
     > not subscribe or publish:
     >
     > * User attempts to subscribe to topicURI
    http://example.com/private and
     > is not allowed
     > * User has successfully subscribed to topicURI
     > http://example.com/authorized but later has his privileges
    revoked, the
     > server stops sending him messages in that channel
     > * Use attempts to publish to topicURI http://example.com/readOnly
    but is
     > 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
    not in

    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

    https://github.com/tavendo/wamp/wiki/PubSub-Feedback
    <https://github.com/tavendo/wamp/wiki/PubSub-Feedback>

    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:

    https://github.com/tavendo/AutobahnPython/issues?labels=wamp&sort=created&direction=desc&state=open&page=1
    <https://github.com/tavendo/AutobahnPython/issues?labels=wamp&sort=created&direction=desc&state=open&page=1>

    In particular:

    https://github.com/tavendo/AutobahnPython/issues/65
    <https://github.com/tavendo/AutobahnPython/issues/65>

    which - in terse form;) - goes in the same direction as your use cases.

    And then:

    https://github.com/tavendo/AutobahnPython/issues/64
    <https://github.com/tavendo/AutobahnPython/issues/64>

    ===

    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
    necessarily non-RPC-like.

    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
    like above.

    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

    sess.publish("topic1", evt1);

    .. time goes by .. server revokes pub right

    sess.publish("topic1", evt2);

    .. 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:

    https://github.com/tavendo/AutobahnPython/issues/63
    <https://github.com/tavendo/AutobahnPython/issues/63>

    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>)

    mySubscription1.unsubscribe()

    => still subscribes on <topic A> via mySubscription2

    but:

    sess.subscribe(<topic A>)
    sess.unsubscribe(<topic A>)

    Its _not_ like

    mySubscription1 = sess.subscribe(<topic A>, subPrefix = true);

    receiving events for all like

    <topic A>
    <topic A/foobar>
    <topic A/subbar2>

    ...

    Ok, enough first thgouhts;)

    \Tobias

     >
     > 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
    functionality to
     > > 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
     > actions
     > > were denied.
     >
     > So that sounds as you know about the
     >
     > AutobahnPython/examples/​pubsub/authorization
     >
     > stuff, but missing a feedback to client, not just "silent" discard on
     > server?
     >

0 Likes

#7

[METAEVENT,

http://awesometopic#1”,
http://wamp.ws/pubsub#ok”]

Consider the client received this from the server without a prior SUBSCRIBE transmission. Does the client “accept”? Technically, the server can send any messages it wants. Could this be a new feature of metaevents in v2? Or a scenario that needs to be handled in the javascript?

···

On Thursday, 29 March 2012 16:25:23 UTC-4, Tobias Oberstein wrote:

Hi Chris,
I am right now collecting all the loose ends for WAMPv2 as GitHub
issues.

That should allow us to have discussion either here or there, but
collect the concrete issues systematically on GitHub (rather them being
lost in mail threads on this list).

Am 26.03.2012 17:50, schrieb Chris Boden:

I see you’ve been thinking about this longer than I have. :slight_smile:

Yeah. Even more so: I wanted to “incubate” ideas in subconsciousness
for a while;) And also gain practical experience.

“Those are all valid use cases IMHO … the last one probably more being
a specific policy.”
I completely agree. I wanted to point it out as it would seem like a
common requirement. I think, from a technical perspective, it would be
handled the same as my #3 example, but be the decision of the developers
server application.

agree.

I think I like the idea of Meta Events more than RPC on the PubSub.

me too. RPC is RPC. its something different and we shouldn’t mix stuff up.

Although, an acknowledgement or error on a Sub might make sense. Would a
sub need an ID though? Would a user attempt to make 2 subscriptions to
the same URI? I would think the topicURI as context would be enough.

I think I agree also here. Let me rephrase, to be sure we mean the
same.

I either have a subscription on a topic or not. A subscription isn’t an
entity for itself, which would then need some kind of ID (not URI),
since it’s something temporary. Anyway, no.

The subscription is to the topic like a call is to a procedure.

topic and procedure are identified by URI.

calls need an ID, but only to correlate the result. The call ID is
NOT visible to the app.

So yeah, lets keep it simple:

A subscription ACK or DENY or REVOKE for a topic is just a metaevent
on that topic:

On the wire:

[SUBSCRIBE,
http://awesometopic#1”]

=>

[METAEVENT,
http://awesometopic#1”,
http://wamp.ws/pubsub#subscription-denied”,
{“desc”: “Topic is closed on Weekdays!”,
“validdays”: [6, 7]}]

From JS:

sess.subscribe(“http://awesometopic#1”, onEvent1, onMetaEvent1);

function onMetaEvent1 (topic, metatopic, metaevent) {

// topic == “http://awesometopic#1
// metatopic == “http://wamp.ws/pubsub#subscription-denied
// metaevent == {… stuff above…}
}

-What if, instead of ALLOW_SUB and REVOKE_SUB there was just DENY_URI.
If the use tried to Sub w/o authentication, has access revoked, or tries
to publish to a URI w/o auth, they receive the same error of “DENY_URI
on topicURI” with a human message? In your continuity example that would
satisfy both errors.-
Although, being async, the user would receive two error messages without
real context…so, forget my thinking out loud idea.

metatopic’s : could be i.e.

Authorization:
ACK http://wamp.ws/sub#ok
DENY http://wamp.ws/sub#denied
REVOKE http://wamp.ws/sub#revoked

Presence/“Rooms”
JOIN http://wamp.ws/sub#joined
LEFT http://wamp.ws/sub#left

In a way, above schema would allow quite some freedom as to what servers
implement, enforce and what clients use.

Extensibility. Some nicely minted, well-known URIs for the most common
use cases would of course be neat. Together with spec for “metaevent”
payload. But that could be split off from definition of base protocol
format …

===

On ticket #63 - I never would expect sub-prefix functionality.

My take on WAMP was that because everything was URI based I thought REST
from the get-go. More specifically, HATEOS.
If I were to make a Twitter like app built on WAMP, I would expect
functionality like this:

ppl = sess.subscribe('http://wamp.ws/users’);
ppl.event -> {chris: ‘http://wamp.js/users/chris’, tobias:
http://wamp.ws/users/tobias’}
tobias = sess.subscribe('http://wamp.ws/users/tobias’);
tobias.event -> {src: ‘http://wamp.ws/users/tobias’, msg: ‘Hello
World!’, on: 1332776748}

Subscribing to /users would give me names of people as they join. From
there, I can subscribe to those users to see messages published by them.

Subscribing to a URL would give me discoverable URIs to subscribe to.

Ok. I see. I need to think about that. It is thoroughly simple, which
I always like. It avoids complexities dealing with prefix subscriptions,
not to speak of general wildcard subscriptions (where the * does not
appear at the end, but somewhere in the middle). I think and come back
to that one …

Cool! Feedback is helpful;) This is getting somewhere!! Lets close the
loop, do v2 and rock…

Cheers,
Tobias

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
let the
 > 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
they can
 > not subscribe or publish:
 >
 > * User attempts to subscribe to topicURI
[http://example.com/private](http://example.com/private) and
 > is not allowed
 > * User has successfully subscribed to topicURI
 > [http://example.com/authorized](http://example.com/authorized) but later has his privileges
revoked, the
 > server stops sending him messages in that channel
 > * Use attempts to publish to topicURI [http://example.com/readOnly](http://example.com/readOnly)
but is
 > 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
not in

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

[https://github.com/tavendo/wamp/wiki/PubSub-Feedback](https://github.com/tavendo/wamp/wiki/PubSub-Feedback)
<[https://github.com/tavendo/wamp/wiki/PubSub-Feedback](https://github.com/tavendo/wamp/wiki/PubSub-Feedback)>

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:

[https://github.com/tavendo/AutobahnPython/issues?labels=wamp&sort=created&direction=desc&state=open&page=1](https://github.com/tavendo/AutobahnPython/issues?labels=wamp&sort=created&direction=desc&state=open&page=1)
<[https://github.com/tavendo/AutobahnPython/issues?labels=wamp&sort=created&direction=desc&state=open&page=1](https://github.com/tavendo/AutobahnPython/issues?labels=wamp&sort=created&direction=desc&state=open&page=1)>

In particular:

[https://github.com/tavendo/AutobahnPython/issues/65](https://github.com/tavendo/AutobahnPython/issues/65)
<[https://github.com/tavendo/AutobahnPython/issues/65](https://github.com/tavendo/AutobahnPython/issues/65)>

which - in terse form;) - goes in the same direction as your use cases.

And then:

[https://github.com/tavendo/AutobahnPython/issues/64](https://github.com/tavendo/AutobahnPython/issues/64)
<[https://github.com/tavendo/AutobahnPython/issues/64](https://github.com/tavendo/AutobahnPython/issues/64)>

===

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
necessarily non-RPC-like.

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
like above.

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

sess.publish("topic1", evt1);

.. time goes by .. server revokes pub right

sess.publish("topic1", evt2);

.. 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:

[https://github.com/tavendo/AutobahnPython/issues/63](https://github.com/tavendo/AutobahnPython/issues/63)
<[https://github.com/tavendo/AutobahnPython/issues/63](https://github.com/tavendo/AutobahnPython/issues/63)>


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>)

mySubscription1.unsubscribe()

=> still subscribes on <topic A> via mySubscription2

but:

sess.subscribe(<topic A>)
sess.unsubscribe(<topic A>)

Its _not_ like

mySubscription1 = sess.subscribe(<topic A>, subPrefix = true);

receiving events for all like

<topic A>
<topic A/foobar>
<topic A/subbar2>

...

Ok, enough first thgouhts;)

\Tobias


 >
 >
 > 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
functionality to
 > > 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
 > actions
 > > were denied.
 >
 > So that sounds as you know about the
 >
 > AutobahnPython/examples/​pubsub/authorization
 >
 > stuff, but missing a feedback to client, not just "silent" discard on
 > server?
 >
0 Likes

#8

Thats a protocol error. Similar to what already today could "happen": a
misbehaving server could send the client a RPC results for a call ID
for which there never was a RPC in the first place, or send a call
result for a RPC twice.

Fail early. Means: protocol violation => connection is closed immediately. Since: it doesn't make a lot of sense continue talking
to a peer which is apparently broken.

IOW: the WAMP implementation on the receiving side needs to handle that
by failing the connection.

For Autobahn on the WebSocket level you can configure what should happen
to "fail the connection": do close handshake or brutally drop TCP.

Since WAMP doesnt have a closing HS (at the WAMP level), it's indistinguishable from the app POV anyway.

···

Am 29.03.2012 23:08, schrieb Chris Boden:

[METAEVENT,

"http://awesometopic#1 <http://awesometopic/#1>",
"http://wamp.ws/pubsub#ok"]

Consider the client received this from the server without a prior
SUBSCRIBE transmission. Does the client "accept"? Technically, the
server can send any messages it wants. Could this be a new feature of
metaevents in v2? Or a scenario that needs to be handled in the javascript?

0 Likes