Message inspection
A canister can inspect an ingress message and decide to either accept or decline the message through the canister's HTTPS interface. If the message is accepted, the canister will execute it.
A canister that does not have a Wasm module installed will reject any ingress messages. If the canister does not implement canister_inspect_message, all ingress messages will be accepted.
The canister_inspect_message functionality should not be used for definitive access control. This is because it is executed by a single replica and does not go through consensus, therefore its result could be spoofed by a malicious boundary node. However, since it does not go through consensus and therefore does not cost cycles, a malicious user cannot use the method to drain cycles from your canister.
HTTP query calls, inter-canister calls, and management canister calls do not trigger #[inspect_message].
Using the canister_inspect_message endpoint, the canister can invoke ic0.accept_message : () → () to accept the message. You can learn more in the IC interface specification.
inspect_message
The canister_inspect_message endpoint can be defined and exported by a Rust canister using #[inspect_message].
The function within this attribute cannot have a return value, and a canister can only have one canister_inspect_message endpoint.
#[inspect_message]
fn inspect_message_function() {
if /* some condition */ {
ic_cdk::api::call::accept_message();
} else {
/* trap or simply not call accept_message to deny*/
}
}