Is the inspect_message function planned for Motoko in the near future?
Also, will inspecting and discarding an ingress message with a large payload prevent the canister from being charged cycles, other than the cost of cycles for the inspect_message function itself?
Lastly, even if Motoko gets inspect_message, how can a canister defend against a hacker deploying another canister and sending large inter-canister payloads to a function in a constant loop? I imagine the function logic could throttle or block repeated requests from the same principal (saving storage), but afaik, the cycles will still get drained.
Will this be taken up again soon? I think inspect_message can be really valuable to use for early authentication in order to prevent cycle drainage attacks.
I have a strong opinion that it’s needed. Without the ability to intercept messages, any canister written with Motoko is vulnerable to a cycle drain attack.
@claudio then the docs here should remove the query call from the inspect_message call? Does it make sense for query calls to be included in the msg arg since they won’t be blocked regardless of the boolean returned?
Confusingly, a shared query function can be called using a regular HTTP call to obtain a certified response: this is why the variant type also includes shared query functions.
You would probably need to use dfx with a manually issued, certified (not plain) query to observe the filtering.
Okay, I’m confused. You mean I can call the shared query function as an update method, and this update call can be filtered by inspect_messge? Is this mentioned in the spec?
I understood that inspect_message is there so that you can run some code on one replica first before it goes through the expensive process of being run on all replicas. So for a query call (that is called as a query call) you can just put the filtering code directly into the query function. You don’t need inspect_message to achieve the same result.