2

I wrote a contract A that uses msg.sender for authentication: When A creates an item it stores msg.sender in itemsOwners mapping (itemOwners[itemId] = msg.sender;). Later A compares msg.sender to itemOwners[itemId] to check access rights.

Now I have the trouble that I cannot use my contract B to wrap calls to A, because A wrongly assumes that the item owner is the contract B, when B calls A. So it stores a wrong item owner that should be a user, not contract B.

Should I replace msg.sender by tx.origin in A? Or what to do? It was not recommended to use tx.origin. So?

I ask not what is the difference between msg.sender and tx.origin, but what to do?

porton
  • 1,774
  • 5
  • 17
  • 38
  • @goodvibration No. – porton Jul 15 '20 at 17:26
  • Does this answer your question? How do I make my DAPP “Serenity-Proof?”? – goodvibration Jul 15 '20 at 17:36
  • @goodvibration No. – porton Jul 15 '20 at 17:44
  • @porton What's the relationship between A and B? Do they work together? If A and B trust each other a typical solution is to pass the user as an address parameter, and A has the requirement that only B can call such method. – Ismael Jul 16 '20 at 12:57
  • @porton Also the title is a bit misleading, you do not want to know the difference but how to authenticate a user between contracts calls or something like that. – Ismael Jul 16 '20 at 12:58
  • @Ismael The trouble is that B is not trusted. – porton Jul 16 '20 at 22:55
  • @porton It is an interesting problem. In a similar situation we had a ERC 721 token A that we cannot modify, and we wrote B as a sort of delegate. For A the token's owner was B, and B kept an internal mapping from users to tokens and A never knew about that mapping. Obviously if A is a different contract the same solution might no apply as it is. Unfortunately I don't know a solution that will apply in a more general situation. – Ismael Jul 17 '20 at 14:12

0 Answers0