Well, it depends on what you want to do with your functions. Supposing both of them are queries or updates, your example would go like this:
In this example, the caller gets to control the principal sent here. You, as a canister, have 0 control over it. Whatever the user sends you will receive here. This is obviously not OK if you want to check access rights for example.
You’d use this if you want to allow a principal to produce some effects on another principal, but in that case you’d probably want to call it something else just so you don’t confuse the two.
This is the proper way to get the true caller of a function. This is guaranteed by the replica to be the principal calling your function. You’d use this to verify that the user is who they say they are, implement access control, etc.
One quick gotcha on this subject:
If you have a call that does some async stuff (e.g. call an update fn on a different canister), you won’t be able to get the caller(); after the async is answered, so you’d probably want to save that in a local variable at the beginning of the function call, before issuing the async call.
I did not know about this one, so I am learning a lot about it. Thank you!
Am I correct in understanding that, for example, if we assume that the user using the application is authenticated by Internet Identity, it is best to retrieve it with caller() rather than having the front end specify the Principal as an argument?
If you don’t pass in arguments, you can’t do Rust unit test casually and have a bit of trouble testing.
I think the current best way to test the functionality at once is to write out the dfx command in a shell script and run it.