Is there any information available regarding cycle usage for operations such as:
dfx canister logs {canister} assuming public log visibility
dfx canister call {canister} {guarded_query_endpoint} assuming the query method is guarded and the caller is not authorised
dfx canister call {canister} {guarded_update_endpoint} assuming the update method is guarded and the caller is not authorised
I like the idea of public logs, but I’d like to understand the potential for increasing cycle drain attack susceptibility by doing this (if this operation would be significantly more expensive than trying to call an endpoint for which the caller is not authorised).
This also has me wondering roughly how many cycles are burned by a single call to a query endpoint and also to an update endpoint which are both rejected due to an unauthorised call. Is it 0 in both cases, or is it non-zero but constant, or is it variable and dependent on other factors?
If you have a list of principals that are able to call a specific API, inspect message can be used to gate access to ingress messages (coming from outside the internet computer) hitting update calls, and then these calls will not burn any cycles if rejected by inspect message. However, inspect message does not protect against calls coming from another canister already deployed to the network.
I think queries still cost cycles in replicated mode.
Thanks @icme, this’ll do the trick nicely Sounds like I should guard for security (goes through consensus), and additionally inspect message as a low security initial gate (but one that does a better job of avoiding unnecessary cycle drain).
Do you know if calls to serve up canister logs are replicated query calls (if there’s consensus involved I expect it costs cycles)?
Assuming this is the case do you know if there are similar ways to protect requests serving up logs? The endpoint isn’t something implemented by the canister developer.
If log access is whitelisted, presumably there would be a small amount of cycle drain to check if the principal is authorised (if logs are served up in replicated mode). Or does access control also take place at the inspect_message level to avoid this?
Sounds like I should guard for security (goes through consensus), and additionally inspect message as a low security initial gate (but one that does a better job of avoiding unnecessary cycle drain).