Soroban Invoker Address

[fleet phoenix]

When I invoke a soroban contract function, I want to get invoker's wallet address. How do I do it? There is not a word about it in documentation.

[stable shuttle]

may I provide sample project for you?

[sudden sail]

So if you invoke it, then the invokers wallet address is yours? 🤔 I feel like I am missing something

Do you mean that you want to store the address of the invoker to the contract?

[primal sequoia]

You accept the address as an argument in the function or have it in storage usually

Getting the invoker address might be possible by parsing the call stack but not recommended

No way for u to know ahead of time if its a user or contract. So usually tske an argument in the function called like 'user' then use user.require_auth()

[fleet phoenix]

Would be great, thanks

[fleet phoenix]

I want to be able to read for any purpose I could need the public address of something that invokes the function

[sudden sail]

Yeah what @primal sequoia already suggested is the way to go. so take user as parameter for the contract function, require authentication with user.require_auth(). This prevents anyone invoking the function call using someone elses address as the user parameter. You can then e.g. store the user or do whatever.

[fleet phoenix]

Thanks!
On the side note, that means I need to make some kind of login and I want to make it with some sort of deep link via QR code, is there any guide/example/documentation I can check on that? I've been trying for the last hour and my links are not readable by LOBSTR

[sudden sail]

It's hard to say what is a good way as I don't know what you are building, but just to store the invokers key you do not need any login. About the deep link QR code invocation I am not sure how you should implement it, nor have I seen any guides on that.

[fleet phoenix]

And how do I acquire public key for transaction then? Manual input only?

That's not very convinient way for users

[primal sequoia]

You connect their wallet

[small shoal]

just to be clear, soroban works with account abstraction out of the box. that makes your contracts really flexible on one hand (you just write your contract once and it will be compatible with any types of accounts, such as the existing Stellar accounts, or any type of smart wallet that may use passkeys, suppport subscriptions, spend limits and what not). but on the other hand it unfortunately makes it so some patterns you might be used to don't exist, specifically 'use the invoker as authorizer'. you do need to provide the addresses you want to require auth from explicitly. the benefit is that there may be more than one address and also that you're not really limited by the direct invoker - a single signature may be used to authorize a whole tree of cross contract calls (say, authorize the DEX operation, do a bunch of transfers etc. - all with the same signature)