0

I am using events to fire an order, basically using them as a vehicle for a master/slave connection with an IoT device, through the blockchain.

Ideally i want to always verify the right msg.sender is sending this order and emitting the event, so i made a function with this access control in place. However i have noticed that i can directly call the event with the proper arguments to emit it (i tested this out on truffle), so malicious users could bypass the function with access control entirely.

It doesn't seem like its possible to use the internal or private visibilities when declaring events, since they're not functions.

So my question is, is there no way to enforce access control or visibility on events? Are there any plans to address this, or am i just using them the wrong way?

0

When you talk about "calling" events, are you talking about emitting (creating) them or about querying them?

An event is written to the blockchain which is visible to all participating nodes, so you can't prevent people from querying them.

They are emitted by contract code, so it's perfectly possible to have your contract check msg.sender or any other condition and only emit them if appropriate. If you had some code that's supposed to do that but doesn't seem to be working for you, try posting your code, if possible with a failing test.

It's of course possible for someone else to create a different contract to yours using events the same name and emit whatever they like, but I doubt that's the issue here as you wouldn't normally be listening for events from unrelated contracts.

  • I'm talking about emitting/creating them, not querying. I thought they could only be emitted from contract code, but when testing, if i call the event method directly, using a normal user account and the contract instance, the event is logged as well. – Leo A Mar 10 at 6:10
  • @LeoA You'll need to share your code for us to figure out what you're talking about. Only contracts can emit events, and an external account can't force a contract to do that. – smarx Mar 10 at 15:30
  • @smarx As i was adding the code of my tests to the question, i ran them again and realized is was confusing an event filter (returned from calling the event like it was a function) with a transaction receipt (return from normal functions). The event was not being emitted from being called directly. It was my mistake, you are right, events can olnly be emmitted from contract code thankfully. Thank you both. – Leo A Mar 10 at 18:27
0

I was confusing an event filter (returned from calling the event like it was a function) with a transaction receipt (return from normal functions). The event was not being emitted from being called directly, events can apparently only be emmitted from within contract code. The access control issue i brought up does not exist.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.