Propagate msg.caller across multiple canisters? (ethereum equivalent of tx.origin)

Developers
1

I’ve found that if I have:

Canister A:
public shared(msg) func foo(){
 Debug.print(debug_show(msg.caller));
 await B.bar();
};

Canister B:
public shared(msg) func bar(){
  Debug.print(debug_show(msg.caller));
};

What I will get is first the user principal from canister A,
but then Canister B will print the principal of canister A, instead of the user principal.

Is there a way to propagate msg.caller from the user? So that canister B can know which user principal originated the function call?

I know I can do this by locking down canister B.bar so it can only be called by canister A, and then passing in an argument of the user’s ID from canister A’s msg.caller. But I’m wondering if there’s a simpler more direct way.
You can do this in ethereum, with tx.origin, I’m wondering if there’s an equivalent in the IC.

2

See a bit of healthy discussion: Request - Inter Canister Calls - Add Original Caller() - #7 by skilesare

I’m still in favor of exposing almost every system variable through the msg interface(origin, block number, coinbase, etc). Having the data available only increases the kinds of systems that we build. The motoko devs generally feel differently and I appreciate their desire to keep the language simple and keep users from shooting themselves in the foot, but still…I like having the data rather than not having it.

3 Likes
3

To clarify my concern, it is not simplicity, but not repeating the fundamental mistakes of the Web, which created a disastrous nightmare of omnipresent data collection, hidden user tracking, spying and surveillance, and dystopian privacy and security violations all around, all behind the backs of its mostly unaware users. And all constructed from seemingly harmless and anonymous data points.

“Having the data available only increases the kinds of systems that we build” – yes, and if we take the goal of becoming Web 3.0 seriously, then that would be a bug, not a feature.

A modern system ought to follow the principles of least authority, data austerity, and explicit user consent. Ideally capability-based, to ensure this by construction and prevent loophole creep.

7 Likes