Test `user.require_auth` when user is not authorized 🧐

[honest tree]

Hello! I have seen a lot of examples of the usage of require_auth.
Let's use soroban-examples/token as an example. We have:

fn set_admin(e: Env, new_admin: Address) {
        let admin = read_administrator(&e);
        admin.require_auth();
        write_administrator(&e, &new_admin);
        event::set_admin(&e, admin, new_admin);
    }

This function will only be sucsesfull if it was the admin itself that called the set_admin function.

The only way that I see that this is being tested, is checking at the recorded_top_authorizations like this:

token.set_admin(&admin2);
    assert_eq!(
        e.recorded_top_authorizations(),
        std::vec![(
            admin1.clone(),
            token.contract_id.clone(),
            Symbol::short("set_admin"),
            (&admin2,).into_val(&e),
        )]
    );

However this does not tests the case where a fake_admin tries to call the set_admin function.

I expect to do something like this:

#[test]
#[should_panic(expected = "NOT ADMIN")]
fn set_admin_deauthorized() {
    let e: Env = Default::default();
    let fake_admin = Address::random(&e);
    FROM(fake_admin).token.set_admin(&admin2);
}

In solidity this is like this:

    await expect(token.connect(other).set_admin(other.address)).to.be.revertedWith('NOT_ADMIN')

How can we test this in rust and the soroban SDK?
Thanks!

[distant edge]

The test you listed checks the contract correctly called require_auth on the admin address. Thus, that unit test ensures the admin address will be required to sign for the set of arguments that match recorded_top_authorizations, and covers the case where a non-admin attempts to maliciously call the function.

See this thread for context, but the TL;DR is contracts don't need to unit test for host functionality (that the call to require_auth correctly verified the signature)-> https://discord.com/channels/897514728459468821/1095492719943622697

[honest tree]

Thanks for the explanation.
It's strange, however, that during tests, we cannot choose from which account to call the function

[royal crystal]

this will be possible in the next release - I'm still not convinced this provides an actual, additional coverage, but you'll be able to write as many negative scenarios as you want (the caveat is that you'll be really testing the soroban host)

[unreal lodge]

Isn't the negative test (also) testing the presence of the corrent require_auth call(s)? It seems important to test that.

[royal crystal]

negative tests are now possible, but I still don't think they're necessary. there is just one correct auth payload and an infinite amount of incorrect ones - it's like testing that 2 + 2 == 4 via covering 2 + 2 != 5, 2 + 2 != 0, 2 + 2 != 1000000 etc.

[ionic gulch]

did you change something? It looks like it was already possible to check that a user could not invoke a function 🤔

[royal crystal]

yes, now you have a way to both verify the auth payloads that have been recorded, as well as pass your own payloads as a precondition to running the function

the latter isn't used widely though, beyond tests in sdk