Hello, when I call the management canister on canisters that I create it gives me a 403. It says I am the controller on ic.rocks and it works to send and get icp with the same principal and with the same agent. Is the management-canister blocking the calls?
@diegop if you have the time, I am looking for a sponse for this question: is the dfx-rust agent the only agent with the current-authorization to call the management-canister and install_code onto new canisters? Are other agents being blocked from installing code onto new canisters?
create_canister can only be called via inter-canister calls. Your wallet, not your principal, is likely to be the controller of your canister. If you want to install code for that canister, you need to ask the wallet to forward
install_code call for you. Or you can use dfx to add your principal as the controller of the canister, then you can call
install_code directly with your principal.
Thank you, so is the install_code method also only able to be called by cross-canister call? What about for the canister_status method?
raw_rand are inter-canister only, because both methods need cycles to run. The rest of the methods can be called as ingress message, but you need to be the controller of the canister for most management canister calls.
For some reason when I call the management-canister with this dart-agent it gives me back a 403. I am trying to call the management-canister’s canister_status method and it gives me a 403. It also gives me a 403 when I call the install_code method. I am trying to call it on this canister: bayhi-7yaaa-aaaai-qahca-cai and with this principal: kxmyk-xvfce-zx3tv-azim5-pcehj-sfrcg-qjohx-zdh76-4x6ls-6dlf3-hqe as the caller/controller. You can see on ic.rocks that this principal is the controller of the canister. The dart agent works to send icp with the same kxmyk-principal/controller so I know the signing and ed25519 authorization functions are correct. And the dart-agent works to contact any other canister, only the management canister is giving a 403. I also tried to call the management canister with the agent that dfx uses and then it gave me the correct-sponse. I am thinking that maybe there is some kind of Basic-Auth-token that the dfx agent is sending to the management canister but nothing like that is list in the spec. Do you have any clue what it is?
There is nothing special in dfx, it just makes calls to the management canister either directly or via a wallet. You can see the ic-repl script to see how we install and check status via calls.
My guess is that the dart-agent is not sending the calls as the kxmyk-principal. It’s the same issue with agent-js, you cannot send the message as the dfx principal, as it needs to import the pem file from dfx.
You can check it backwards here is the cbor bytes of a call, you can see the cbor map on cbor.me and check that the sender is the kxmyk-principal and the public-key corresponds to the same kxmyk-principal.
this got a 403.
Do you know what this is used for and how?:
at this line:
I forked the rust agent and printed the headers and the bytes and im not seeing anything different between what the dart agent is sending and what the rust agent is sending but the rust agent works and dart agent gets a 403. If someone has an idea of what the dart agent is missing?
Yes it is giving me the same error as if the caller is not the controller but if I backwards check it, the caller is the correct-controller.
Does someone know what this canister is?: Principal ifxlm-aqaaa-multi-pleco-ntrol-lersa-h3ae | ic.rocks