Question about filtering publish events (at the router)

[paul wisehart]

Hi,
I am making a browser chat app, to learn crossbar/autobahn/wamp.
Original I know :)

So it's working well. There is a server with a crossbar router running.
The chat page, uses the javascript api to publish and subscribe to a topic on the router.

I have some python guests on the router to do things like storing the messages, and creating regular "ping" messages to help developement.

OK now to my issue.  When a user inserts a message with script tags and an alert(), that pops up on each connected page!
Kinda cool, but obviously not good for serious use.

So I want to filter out html and javascript.  And to do it I think I should put another python guest between the publish and subscribe.
So the clients would publish to say 'mysite.chat.pending', and subscribe to 'mysite.chat.ready'.
And, have the python guest subscribe to 'mysite.chat.pending', and for each message do some filtering, and then publish the safe version to 'mysite.chat.ready'.

I do not want to filter in javascript on the page, because someone could read it and get around it by scripting their browser, or whatever.

SO, My question is does this idea seem sane?
Would I ruin performance, but inserting this python code between the browsers publish and subscribe cycle?

thanks for any insight.

[Tobias Oberstein]

Your need of checking the payload of published events can be addressed with different mechanisms.

One of these is what you describe (publish -> receive & validate -> publish). However, I'd just use a procedure for the verified-publish. You register a procedure which chat clients call to send their messages. The procedure checks the payload, and if fine, does the actual publication.

Another option would be: use the (beta) built-in payload validation facilities of Crossbar.io. Ah, wait, that is using JSON schemas to define valid payloads .. wouldn't help much in your case .. you need to find script tags. So my recommedation: implement a "com.myapp.send_message" procedure with payload checking and publish therein.

[paul wisehart]

Thanks, that makes sense.  

On Wednesday, May 27, 2015 at 5:18:38 PM UTC-4, Tobias Oberstein wrote:

...

Another option would be: use the (beta) built-in payload validation facilities of Crossbar.io. Ah, wait, that is using JSON schemas to define valid payloads .. wouldn't help much in your case .. you need to find script tags. So my recommedation: implement a "com.myapp.send_message" procedure with payload checking and publish therein.

...

[José Juan Montes]

Another option would be: use the (beta) built-in payload validation facilities of Crossbar.io. Ah, wait, that is using JSON schemas to define valid payloads .. wouldn't help much in your case .. you need to find script tags. So my recommedation: implement a "com.myapp.send_message" procedure with payload checking and publish therein.

Thanks for this.

On the other hand, I was actually looking for some way for a component to intercept published messages. I feel it'd allow for quicker development in my case.

Use case: I need to do some caching of some messages in order to repeat them for recently connected sessions. An interceptor would work. Later on I'll need to respond to some RPC calls with some special responses for some users (to avoid concurrent access to some methods). I'd like to offload that burden off the main process, and put it on the router, but I'll have to "proxy" all RPC calls within my component.

Is there such a thing as an interceptor?

Best regards!

[José Juan Montes]

Additional info:

- I see that for the first part of my use case, there is a feature request: https://github.com/wamp-proto/wamp-proto/issues/69 , although I'd prefer to manage that in my own "interceptor" component.
- I posted a related question to SO: http://stackoverflow.com/questions/32726514/how-to-provide-both-initial-data-and-subsequent-events-via-wamp-websockets?noredirect=1#comment54184222_32726514

[Alexander Gödde]

Hi José!

A message history feature is mentioned in several issues: https://github.com/wamp-proto/wamp-proto/issues/42, https://github.com/wamp-proto/wamp-proto/issues/69. Additionally there is a suggestion for message persistence: https://github.com/wamp-proto/wamp-proto/issues/43.

Currently, your best bet is a component which subscribes to the topics which clients need to receive history for. This would then offer a RPC which components can call to get the required history.

There are no interceptors. To understand your use case better: What would be the difference between interceptor components which get called by the router versus an architecture where: all clients call a RPC 1 which filters out the special cases, calls a RPC 2 with the actual procedure for the non-special case and then returns the result? (Except for one round-trip.)

Regards,

Alex

[Johnny W. Santos]

I've made a component which stores every message from every topic in Redis in case of a component failure, so they can call a RPC and recover the lost messages after the crash time. I plan to implement a better strategy for invalidate the cache but for now it's just time based.

--
You received this message because you are subscribed to the Google Groups "Crossbar" group.
To unsubscribe from this group and stop receiving emails from it, send an email to crossbario+...@googlegroups.com.
To post to this group, send email to cross...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/crossbario/e607e62a-407a-4300-9a45-6ceef114bb37%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Johnny W. dos Santos

[José Juan Montes]

Currently, your best bet is a component which subscribes to the topics which clients need to receive history for. This would then offer a RPC which components can call to get the required history.

 

There are no interceptors. To understand your use case better: What would be the difference between interceptor components which get called by the router versus an architecture where: all clients call a RPC 1 which filters out the special cases, calls a RPC 2 with the actual procedure for the non-special case and then returns the result? (Except for one round-trip.)

Indeed you are right. After some thought, I can implement my use cases quite satisfactorily, no need for extra features in crossbar:

1) Replaying last message of certain topics to recently connected users: I can write a component that subscribes to X topics and and uses "wamp.session.on_join" to replay messages to recently joined sessions (albeit this changes the source of the message, it does't matter to me at least).

2) Intercept RPC calls to add permission checking / state checking: I can do it with 2 RPC as you mentioned.

3) Intercept events in order to send them only to certain users (ie. filtering map events by proximity to the user proximity). Again I can add a component and do either "RPC->Publish" or with "Publish->Publish". No need to add interceptor semantics.

Thank you very much for your reply. I was thinking about this the wrong way, possibly influenced by my Java background, I guess.

Best regards,

 

- I see that for the first part of my use case, there is a feature request: https://github.com/wamp-proto/wamp-proto/issues/69 , although I'd prefer to manage that in my own "interceptor" component.
- I posted a related question to SO: http://stackoverflow.com/questions/32726514/how-to-provide-both-initial-data-and-subsequent-events-via-wamp-websockets?noredirect=1#comment54184222_32726514

Another option would be: use the (beta) built-in payload validation facilities of Crossbar.io. Ah, wait, that is using JSON schemas to define valid payloads .. wouldn't help much in your case .. you need to find script tags. So my recommedation: implement a "com.myapp.send_message" procedure with payload checking and publish therein.

Thanks for this.

On the other hand, I was actually looking for some way for a component to intercept published messages. I feel it'd allow for quicker development in my case.

Use case: I need to do some caching of some messages in order to repeat them for recently connected sessions. An interceptor would work. Later on I'll need to respond to some RPC calls with some special responses for some users (to avoid concurrent access to some methods). I'd like to offload that burden off the main process, and put it on the router, but I'll have to "proxy" all RPC calls within my component.

Is there such a thing as an interceptor?

Best regards!

--
You received this message because you are subscribed to a topic in the Google Groups "Crossbar" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/crossbario/LbfbxnSd5YA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to crossbario+...@googlegroups.com.

To post to this group, send email to cross...@googlegroups.com.

[Alexander Gödde]

Hi José!

Glad I could be of help! 

Questions like yours are always welcome since they show us what users want to achieve - and sometimes that means that Crossbar.io changes.

Regards,

Alex

To unsubscribe from this group and all its topics, send an email to crossbario+unsubscribe@googlegroups.com.

To post to this group, send email to cross...@googlegroups.com.