Filtering real-time messages for users

[foralobo]

Hi, I don't know if this is the right area to ask for this question but... I try it and ask for excuse if I am making something to wrong.

I need some idea to a specific scenario. I would like to filter some realtime info messages for determinate users and so let the others without info. For example one typic scenario like this is the "privacy notification" management of Telegram Messenger.

Now, I can send message to one room and then, to program the clients for ask the messages with filters but IT IS NOT SICURE if we are talking of privacy.

I must absolutely filter messages:

• Sending only to determinate users reading the setting privacy (but how to it?? if I am a malevolent person and I have an account, I can subscribe at that room and listen those private messages). It is not a good idea
• Or (my preference) to use a system that permit to filtering the messages (reading the setting privacy) BUT SERVER SIDE.. Is it possibile with some feature out of the box? Must I write some code to customize app server side?

Any other ideas???

Thanks

[scottinet]

Hi,

You can secure realtime subscriptions easily, although it does need some effort on your part.

For your needs, you'll have to add a unique filter condition when doing subscriptions, linked in some way to a user kuid, either directly or by maintaining something like a conversion table.

If you do that, then you have unique subscription IDs linked to their attached users.

The last step, then, is to simply add a pipe, listening to the realtime:beforeSubcribe API action, with a simple test: if the filter condition doesn't match the user ID of the request, you can simply throw an error, and Kuzzle will interrupt the action with the thrown error.
You can find the user ID in the KuzzleRequest provided to the pipe: request.context.user._id

And voila: you now have secured realtime subscriptions, where users can only listens to their own notifications, without anyone else able to do the same.

edit: you can do the same with user profiles instead of user ids, allowing you to link resources to a set of users, instead of individual ones.

[foralobo]

"no generic backend can ever fulfill every and all business logic possible out of the shelf."
Of course!!!!!

I just wondered what the right approach might be. I've worked quite a bit with sockets, but doing everything from scratch. In systems like kuzzle, where 90% are ready, it is good to have some experience to understand which is the correct approach. I imagined what was suggested to me

(in fact in my first question it is cited as the second point:

"Or (my preference) to use a system that permit to filtering the messages (reading the setting privacy) BUT SERVER SIDE .. Is it possible with some feature out of the box? Must I write some code to customize app server side?"
)

I was just wondering if there was something ready for that purpose !!

Thank you very much ... and I apologize in advance but I will probably return for help !!!!

[scottinet]

The solution I described is server-side ;-)
With Kuzzle, you can inject code directly in Kuzzle API processes, and you can modify or even stop the execution of API actions that way.

It's a standard practice for our users to do exactly that: add custom security checks, complementing the out-of-the-box permission system, and interrupt a workflow with the adequate error if something does not comply to security and/or business rules.

And that seems to be what you need to do with your feature: add custom checks when users perform realtime:subscribe actions, and stop them from subscribing to content they shouldn't have access to.
All you have to do is to add a little bit of code throwing an error if an invalid subscribe is performed, and insert it in Kuzzle's workflow by registering this code as a "pipe".
Kuzzle takes care of the rest: it will take the error, and return it in a standardized way to the user, while interrupting the API action on its side.

[foralobo]

Clear... thanks

[foralobo]

Hi,

You can secure realtime subscriptions easily, although it does need some effort on your part.

For your needs, you'll have to add a unique filter condition when doing subscriptions, linked in some way to a user kuid, either directly or by maintaining something like a conversion table.

If you do that, then you have unique subscription IDs linked to their attached users.

The last step, then, is to simply add a pipe, listening to the realtime:beforeSubcribe API action, with a simple test: if the filter condition doesn't match the user ID of the request, you can simply throw an error, and Kuzzle will interrupt the action with the thrown error.
You can find the user ID in the KuzzleRequest provided to the pipe: request.context.user._id

And voila: you now have secured realtime subscriptions, where users can only listens to their own notifications, without anyone else able to do the same.

edit: you can do the same with user profiles instead of user ids, allowing you to link resources to a set of users, instead of individual ones.

Hi, I tested your idea about filtering and it is ok... but

I need to filter some message for some users (end this is ok)...
also, I need to filter message FROM SOME users dynamically.

I try to explain better:

there are three user:

user1
user2
user3

and those users can publish 2 types of event: event "foo" and event "bar"

user1 can see all events from all users and, user2 and user3 can see events from user1.
user2 (that can see events from user1) can't see events from user3 and vice-versa

so.. how I can setting may pipe to filter dynamically the subscription for some emitters??
IMPORTANT: I must filter dynamically the subscription for some emitters but those setting can change at any time...
so,
I can filter a determinate event for a determinate user ok, via [request.context.user._id] but..
I need to filter event for a determinate user IF the emitter is... userX and not userY. Tomorrow the setting can change and I can need to filter event for a determinate user IF the emitter is... userY and not userX.

Is it possible???

thank you very much

[foralobo]

I have in mind an idea but I don't know if it is the right approach:

The events are: "foo" and "bar" but I can use a convention: "username:eventname" so... "user1:foo" (or similar).

If user2 wanna see the event foo of user2, he must subscribe to user2:foo and the pipe will can check for db index if that events is permitted for him.

From a technical point of view, it works... ma is it a correct practice in the kuzzle world??

Thanks

[scottinet]

Hi,

Events are not propagated outside Kuzzle, so users never have access to them. So unless I didn't understand your solution, I don't think that it's a viable one.

An easy way to do that is to use profiles: you can code your pipe in such a way that if a user belongs to some profile, then they can complete a given subscription. User profiles are also available in the KuzzleRequest object provided to pipes.

Another way would be to add complementary permission properties to your user objects: user objects in Kuzzle are extensible with custom content.

Either way, this would make your verifications dynamic, and linked directly to Kuzzle's permission system. So all you have to do is to check for a property, which will be updated on the fly if you change a user settings (be it their profiles list or their custom content, whatever solution you choose).

As a side note: I feel that this thread exceeds the purpose of a mere github issue. So I'm going to close it for now.

If you have more questions, don't hesitate to join our discord server, or to ask them on StackOverflow (with the Kuzzle tag)