Best way to apply permissions to projected streams?

I’m currently building a project against the 2.0.1 binaries where I need to be able to provide a separate stream for each organization that submits data. I’ve used a projection similar to some posted elsewhere in this forum to split those off based upon a “source ID” I store in the messages. Something like this:

fromAll()
.when({
$any: function (s, e) {
if(e.body && e.body.SourceId) {
linkTo(‘sourceEvents-’ + e.body.SourceId, e);
}
}
});

``

This works great, and provides me an easy way to see only the events that come from a single source.

What I’d like to do now is create a user for each of these projected streams and apply read permissions to the projected stream, so that I can have client applications connect directly to the EventStore to get the latest updates without being able to see streams from other users. I’m curious what the recommended practice for doing this would be. My initial thought was to have a projection watch for the sourceEvents-xxxxx streams getting created and emit a new event to a stream. That stream would be monitored by a task on an Azure worker role that could create the user and apply read permissions for that source’s user to the projected stream. However, I haven’t found a good way of determining when that projected stream gets created yet.

I’ve tried a few variations on something like the following, including another “$any” filter, looking for helpful events via the debugger. But all I could ever seem to trap with this were the aggregate streams themselves, instead of the projected sourceEvents-xxxxx streams, even when running all the default system projections.

fromAll()
.when({
StreamCreated: function(s,e) {
if(e.body && (typeof e.body == ‘string’) && e.body.lastIndexOf(“sourceEvents-”, 0) === 0) {
var sId = e.body.substring(13);
emit(“SourceStreamCreations”, “SourceStreamCreated”, {
SourceId: sId
});
}
}
});

``

Other ideas I had:

  1. Create the user up front and seed an arbitrary, no-op event to get the stream created. I’d prefer not to have to stick arbitrary data in the stream if I can help it, though.
  2. Create the metadata for the stream before it actually exists. Haven’t explored this yet, because I wasn’t super-comfortable with creating a system stream without some kind of confirmation that this isn’t a terrible idea.

If anyone has done something similar or can offer some advice, it’d be greatly appreciated. Thanks!

Creating the stream up front is no issue. We have been discussing adding the ability to set this in projections (eg in your $init etc).

Sounds like that’s the way to go then. I’ll look into pre-creating the metadata stream, since that seems to be the path of least resistance. Thanks for your time!