Fixes: stellar#1030 Soroban allows contract authors to call `require_auth()` not only on a G-address (for users), but also on a C-address (for contracts). This will result in a cross-contract call to the `__check_auth` function in the signing contract. This enables all sorts of powerful and novel use-cases. See https://developers.stellar.org/docs/build/guides/conventions/check-auth-tutorials#customaccountinterface-implementation Just as if one account submits a transaction (meaning that account signs the transaction envelope) but the contract calls `require_auth` on a different one, the app author will need to use `needsNonInvokerSigningBy` and `signAuthEntries`, so app authors benefit from these functions when `require_auth` is called on a contract. This fixes various assumptions that these functions made to also work with this sort of cross-contract auth. - `needsNonInvokerSigningBy` now returns contract addresses - `sign` ignores contracts in the `needsNonInvokerSigningBy` list, since the actual authorization will happen via cross-contract call - `signAuthEntry` now takes an `address` instead of a `publicKey`, since this address may be a user's public key (a G-address) or a contract address. Furthermore, it allows setting a custom `authorizeEntry`, so that app and library authors implementing custom cross-contract auth can more easily assemble complex transactions. Additional changes: - switch to new test cases from AhaLabs/soroban-test-contracts, embed as git submodule - switch to `stellar` instead of `soroban` - use latest cli version (this version fixes a problem that some of the tests were working around, so they were removed) - add (untested) workaround for stellar#1070

Commits

Commits on Oct 3, 2024

feat!: enable cross-contract auth