networked emit needs to be made secure
pfrazee opened this issue · 8 comments
right now a message is handled by emitting an event on the receiver using the same emit/on interface that's used locally on the rpc object. that could be used to trigger bad behaviors. we need to change the interface somehow -- something like...
rpc.on('remote', function() { /* all network messages here */ })
or
rpc.onRemote('msgtype', ...)
or
rpc.on('remote:msgtype', ...)
Agreed. the reason we don't have this yet is because it doesn't fit into the permissions model we currently have. That is based on allow/deny lists for method names, but of course emitting events just uses one method...
So maybe it would be better to treat permissions as being about parameters, and treat the method name as the first parameter?
I'll bump permissions up the todo list.
what do you think about the source-stream events()
pattern i use in phoenix-api? https://github.com/ssbc/phoenix-api/blob/master/index.js#L36-L47
it's problematic as-is because it would keep the connection open incorrectly. maybe we could make an events-stream rpc-method type that wouldnt do that?
oh, no I think this needs to be baked in, because there are multiple things that need events.
i'm saying do it as a baked in muxrpc method type
// manifest.js
module.exports = {
events: 'emitter', // our new type
ping: 'async',
// ...
}
// plugin.js
var pushable = require('pull-pushable')
api.events = pushable()
api.ping = function (v, cb) {
api.events.push({ type: 'pong', pong: 1+v }) // emit event
cb(null, 1+v)
}
// client.js
var api = muxrpc(...)
pull(api.events(), pull.drain(function (e) {
if (e.type == 'pong')
console.log('ponged', e.pong)
})
api.ping(100)
// emits "ponged 101"
well if you want just want a stream there is nothing stopping you from doing that,
but events have different capabilities, like, it's possible to register multiple listeners to a event emitter,
but not a pull stream.
@dominictarr ah we need to deal with this guy
emit was removed. closing.