Unsure how to subscribe to a publish per user

[mitar]

I would simply like to keep the normal subscribe/publish, but just to send messages from publish function to a particular client which is subscribing (instead of keeping the state on the server for publish).

From looking at this package, I am unsure how to do so that each client would have its own set of messages being generated and coming from server. It seems this is more suitable when multiple clients share a set of messages. But how could I do it so that each client (or subscription) has its own set of messages, no other client can see?

[paolo-g]

I just moved over to this package from arunoda's and am having the same problem. Not sure if this is possible since the allow rules use the event name and there's no userId at that point

[maxnowack]

I use the userId as the event name as a workaround and specify the real event name in the parameters.

streamer.emit(Meteor.userId(), { eventName: 'post', postId: post._id })

streamer.allowRead(function allowRead(userId) {
    return this.userId === userId
})

[paolo-g]

Ok, thanks @maxnowack , I see now. We are setting the rule for all streams in streamer. @mitar, I'm not sure if this answers your question but it does mine.

Now I need to figure out how to only allow the server to emit. (Edit: nevermind, I just noticed this: "The default permission deny all comunication, you should define a new permission!")

[mitar]

Yea, I would love it there would be a simpler 1:1 way to move from arunoda's package to this. Using userId as a event name seems hackish. Would it be possible for a malicious user claim that they should receive some other event name with another userId, if they know that userId?

[paolo-g]

@mitar I'm not sure about your use case, but for me it ended up being very close. The security defaults to deny, and for the read rule, using userId is not hackish because the rule is defined on the server, and when you emit from the server you get to use Meteor.userId()

[mitar]

Looking at the code it seems you are right. The above approach would work and works well.

The only issue I have now is that it creates one publish endpoint for each user. So for every even name a publish endpoint is created (Meteor.publish is called). I think it would be much better if only one publish would be created, which handles emitting messages per-user, like Meteor already provides.