Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug: KwilSigner is required for user.call #1249

Open
martin-opensky opened this issue Jan 20, 2025 · 8 comments · May be fixed by #1276
Open

Bug: KwilSigner is required for user.call #1249

martin-opensky opened this issue Jan 20, 2025 · 8 comments · May be fixed by #1276
Labels
bug Something isn't working

Comments

@martin-opensky
Copy link

martin-opensky commented Jan 20, 2025

Version / Commit

latest

Operating System

macOs 15.1.1

Configuration

I am using the latest build of Kwil and have started the Kwil Daemon as normal while adding the DB owner manually to the genesis.json.

Expected Behavior

When I make a 'user.call' request, I expect the signer to be optional, so I can call a view action without it. However, I need to provide it otherwise the call fails.

Actual Behavior

Without the signer passed I receive the following response from the RPC server:

{
"jsonrpc": "2.0",
"id": 5,
"error": {
"code": -601,
"message": "failed to get caller: invalid eth address with 0 bytes"
}
}

When I provide a kwil Signer the call functions as expected.

Steps to Reproduce

I make a simple 'view' action call without the signer using the following request to the RPC:

{"jsonrpc":"2.0","id":5,"method":"user.call","params":{"body":{"payload":"AAHlhHRlc3SJY2FsbF9uYW1l1dTJhHRleHSAwoCAyYhTM2RwYkE9PQ=="},"auth_type":"secp256k1_ep","sender":"","signature":{"sig":"","type":""}}}

The action is:
{test}CREATE ACTION call_name($name text) public view returns (name text) { return Sname; }

Additional Information

No response

@martin-opensky martin-opensky added the bug Something isn't working label Jan 20, 2025
@KwilLuke KwilLuke reopened this Jan 20, 2025
@KwilLuke
Copy link
Contributor

@brennanjl - it looks like something changed.

Previously, unauthenticated call requests could be sent with the sender, signature.sig, and signature.type fields empty. Should we remove these fields now if the caller is not authenticating?

@brennanjl
Copy link
Collaborator

brennanjl commented Jan 20, 2025

Should we remove these fields now if the caller is not authenticating?

Yes, they should not be required if not authenticating. Something must have changed / been broken. @jchappelow or @charithabandi can you take a look? These fields should be optional (unless in private mode), right?

@jchappelow
Copy link
Member

Missed this. Having a look.

@jchappelow
Copy link
Member

Wait I though sender was always required, and only signature was optional. How else did we handle @caller before?

@jchappelow
Copy link
Member

Oh it defaulted to an empty eth address. Will revert to legacy behavior

@KwilLuke
Copy link
Contributor

Previously, sender only was included if the query used @caller

@KwilLuke
Copy link
Contributor

Awesome!

@jchappelow
Copy link
Member

For background this was arguably a bug with the EthSecp256k1Authenticator, where if you fed it a nil or empty ident []byte it would return an address

func (EthSecp256k1Authenticator) Identifier(ident []byte) (string, error) {
	return ethCommon.BytesToAddress(ident).Hex(), nil
}

so we get:

func TestEmptyAuthIdentifier(t *testing.T) {
	auth := &auth.EthSecp256k1Authenticator{}
	idstr, _ := auth.Identifier(nil)
	t.Log(idstr) // 0x0000000000000000000000000000000000000000
}

On main:

func (EthSecp256k1Authenticator) Identifier(ident []byte) (string, error) {
	if len(ident) != 20 {
		return "", fmt.Errorf("invalid eth address with %d bytes", len(ident))
	}
	return eip55ChecksumAddr([20]byte(ident)), nil
}

which is very sensible. So instead, I will fix this in the RPC server where it prepares the string for @caller.

@jchappelow jchappelow linked a pull request Jan 22, 2025 that will close this issue
@jchappelow jchappelow linked a pull request Jan 24, 2025 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants