Without a proper security model, meteor streams would be useless. So security is the first class citizen of the meteor streams. Meteor Streams has flexible permission based security model. Lets have a look at the image below.

• We define checkpoint 1 with a write permission where client is trying to send an event to the server
• We define checkpoint 2 with a read permission where server is going to send the event to the listening clients

We assume insecure package has been removed from the meteor app

Write Permissions

Let’s see how we can define the write permission for the stream.

helloStream = new Meteor.Stream('hello');

helloStream.permissions.write(function(eventName) {
  var userId = this.userId;
  var subscriptionId = this.subscriptionId;
  //return true to accept and false to deny
  return true;
});

Now we can decide to accept or deny by looking at eventName, userId and subscriptionId.

This function is runs inside a fiber, and you are safe to use any core Meteor APIs.

Read Permissions

Read permissions also work exactly the same as write permissions, but it will be used as the checkpoint for clients who are listening to the stream.

helloStream.permissions.read(function(eventName) {

});

Result Caching

By default, permission result for each subscriptionId, eventName combination will be cached to provide a great level of performance. This is okay for many applications. But sometimes, we need to decide whether to allow or not by looking at some third party conditions. So, in those cases result caching becomes a problem.

So you can easily turn it off. See below.

helloStream.permissions.read(function(eventName, arg1, arg2) {

}, false);

Both permissions.write() and permissions.read() accept a second parameter where if it is false caching will be turned off.

Once caching is turned off, you can access all the arguments of the event. See above example as it can see eventName, arg1, arg2. If cache turned on you can only see eventName.