What's the recommended way to test failure case for auth in a contract?
#Testing auth failure in a contract test
sharp rock
cc @ionic lion
e.g. I have address.require_auth() in a contract. And in my test I want the auth to fail.
ionic lion
there is no way. there is no point in testing this
instead of testing all the failure scenarios you can test what exactly you require auth for
there is some room for improvement in this - https://github.com/stellar/rs-soroban-sdk/issues/875, but I'm not sure I like any of the options there...
since auth data is a transaction parameter, there is really nothing meaningful you can cover for the failure scenarios besides that the host will panic
that's similar to e.g. the footprint, though for the footprint we don't provide any utils for positive testing as well as it's pointless as well
proud idol
there is no point in testing this
We discussed this some in another thread but I still disagree with that statement. I think that testing access control is pretty important.
ionic lion
yeah, I'm a bit tired of repeating this over and over...
sharp rock
Footprints are quite different to auth. Footprints can only ever cause the entire transaction to fail. Auth can cause a subset of a transaction to fail.
ionic lion
but really, this is not access control testing. this is testing the host. and the contract shouldn't need this
sure, but does this really change anything you can meaningfully cover?
auth failure is no different from any other sub-contract call failure and I guess we don't have a great support for mocking these in general. but I'm not sure why auth (the sub-contract implementation detail) should necessarily be special-cased here
sharp rock
Not trying to special case anything, just want to test auth.
If I wanted to experiment with the Env in contract tests having auth enabled, would commenting out this line be the way to go?
env_impl.switch_to_recording_auth();
And assuming that works, how do I pass the auth parameters to the host? Is it with the AuthorizationManager or is there another way?
ionic lion
you can test auth in declarative fashion
yeah, you could do the enforcing mode for some integration tests... I'm not sure you should though - at this point it's better to test against the core instance
and I don't think this is useful for the SDK - it's a lot of work for no real benefit (instead of verifying the exact specification for what is being authorized you get an unbounded number of failure scenarios, which is cumbersome and provides worse coverage - e.g. see https://github.com/stellar/rs-soroban-env/blob/main/soroban-env-host/src/test/token.rs#L1572)
also importantly the single contract is not sufficient for the enforcing mode as it also cares about the accounts (which comes with a lot of annoying test harness we could get rid of). the current framework albeit maybe having a bit confusing interface exposes only what the contract should care about
clear barn
I tend to agree with Dmytro that explicitly testing cases for require_auth seems out of scope for a contract. env.recorded_top_authorizations() provides enough to verify that require_auth is being called appropriately.
If there is an edge case that needs this, they always can run a test script against the quickstart container. it would be annoying and take like >5m for a test run, but would be doable.
ionic lion
yeah, there is some cost for the larger tests, but probably doing a e2e testing of a dapp would require to do something like that anyway. it might be a wise idea to test the preflight interaction, wallet interaction etc. auth in particular might break in several places besides the contract itself
clear barn
I have noticed that env.recorded_top_authorizations() doesn't seem to work when invoking a WASM contract (anything deployed with e.register_contract_wasm(...)). Is this expected? The same test passes if the contract is deployed via e.register_contract(...).
If not, I can file an issue against the SDK.
ionic lion
no, this is not expected
sharp rock
you can test auth in declarative fashion
What's the approach for doing this?
ionic lion
currently recorded_top_authorizations - the idea is that instead of mocking the correct/incorrect side inputs you verify the auth requirements of your contract call directly (which is why I call this 'declarative' approach - I recognize the interface is imperfect for conveying this)
sharp rock
Is there a way to record non-top authorizations?
ionic lion
we do record everything; there is no accessor for these yet (haven't got any requests yet either), but I think we need to add this eventually
the reason we don't have this yet is purely UX-related, there is nothing preventing it from the technical standpoint
representing trees is tricky; https://github.com/stellar/rs-soroban-env/issues/744 is another issue that needs some sane way of moving the trees to the host
clear barn
I have noticed that `env.recorded_top_authorizations()` doesn't seem to work whe...
When replicating this on the auth contract in the examples repo, it appears to work. Root cause is likely something different on my end!
ionic lion
ok, any repro details would be appreciated
signal forge
When replicating this on the `auth` contract in the examples repo, it appears to...
I'm successfully using it for a wasm invoked contract fwiw.
flint vine
I am slightly late to the party here but have similar queries. When writing and testing a contract how do I set up which addresses are and are not authorised?
ionic lion
you can check which addresses require auth for which arguments. all the other addresses are not authorized
(your contract would probably require auth from one or a couple addresses. about 2^256 remaining addresses are not authorized)
flint vine
Sorry, I am not sure what you mean 😦 I create some user addresses by the random function. In my smart contract code I used the address::random function to invent a new address and called require_auth on it and it seemed to pass. How do I create on that will fail?
ionic lion
you shouldn't be creating random addresses in the contracts; that won't even compile in non-test mode
require_auth passing just means that the user has provided the correct signatures; if they didn't, then it will just panic. there is no point in covering that as this logic is built into soroban host and is not controlled by your contract
