-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
feat: custom get signers #16340
feat: custom get signers #16340
Conversation
…6112-custom-signers
…6112-custom-signers
91a9688
to
d8022de
Compare
x/tx/signing/context.go
Outdated
// NOTE: if a custom signers function is defined, the message type used to | ||
// define this function MUST be the concrete type passed to GetSigners, | ||
// otherwise a runtime type error will occur. | ||
func DefineCustomGetSigners[T proto.Message](ctx *Context, getSigners func(T) ([][]byte, error)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if this should be done when constructing a context by setting options. We shouldn't really allow this after initialization
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I explored how to do this with depinject, with CustomGetSignersFunc
as a ManyPerContainerType
, but couldn't come up with anything too good. Maybe we can change the API for DefineCustomGetSigners
. I think we'd need to drop the Generic and possibly pass the type name in.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah we can refactor the API. If that sounds like the right direction, let's first figure out how this works with the signing context options struct and then we can figure out depinject
@@ -113,12 +114,6 @@ func ProvideApp() ( | |||
return nil, nil, nil, nil, nil, nil, nil, nil, nil, err | |||
} | |||
|
|||
// validate the signing context to make sure that messages are properly configured | |||
// with cosmos.msg.v1.signer | |||
if err := interfaceRegistry.SigningContext().Validate(); err != nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why no validation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With current app wiring and depinject, I couldn't find anyway to call Validate after an invoker is called. If it's called before the app will error during start up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting... can we call validate in an invoker?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes but DefineCustomGetSigners
is also called in an invoker and order matters, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK, just one question
// without a custom signer we should get an error | ||
require.ErrorContains(t, err, "use DefineCustomGetSigners to specify") | ||
|
||
// create a new context with a custom signer |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just curious, can you overwrite the proto annotation by defining a custom get signer?
Can we have a test with the expected result? (right now I am not sure what is the expected/wanted behavior)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good point. I think the annotation would override the custom signer but I'll definitely make a test for it.
simtestutil "github.com/cosmos/cosmos-sdk/testutil/sims" | ||
) | ||
|
||
func ProvideCustomGetSigners() signing.CustomGetSigner { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice, it will be useful if this could be displayed in the docs ref: #16294
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this work with gogo messages? Is that important?
Also I think we shouldn't allow a custom get signers if the signer proto annotation exists.
I'm not seeing any place that we're doing validation of the signing context
}, | ||
} | ||
for _, signer := range customGetSigners { | ||
signingOptions.DefineCustomGetSigners(signer.MsgType, signer.Fn) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This code does nothing I'm pretty sure. The receiver is a struct not a pointer
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This code does something, registers a custom signer fn. If you'd like to prove to this yourself, comment it out and run TestDefineCustomGetSigners
in the x/tx integration tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because map is a pointer type?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea. I'm doing an iteration and copy of customGetSignerFuncs in in construction of signing.Context so that changing options after construction won't alter context.
No it doesn't, only pulsar messages. I'll explore gogo support a bit more.
Right now I think the custom signer will be (silently) ignored in favor of the proto annotation. Do you think we should error though? Or just warn.
Line 182 in 9e7a2bb
|
…6112-custom-signers
One approach could be to move the Any unpacking up to the signing context and then allow specifying the message type when registering custom get signers.
I think we should expect an annotation or custom signer but not both |
I'm leaning towards just not supporting gogo here. From what I can tell bera generating pulsar types so this shouldn't be a issue. |
…6112-custom-signers
Great! |
// ValidatorAddressCodec is the validator address codec to use for the registry. It is required. | ||
ValidatorAddressCodec address.Codec | ||
// SigningOptions are the signing options to use for the registry. | ||
SigningOptions signing.Options |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still we just require a signing context to be passed in? Seems like signing options already takes proto files already so there's some redundancy here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could but signing.Options
permits an nil ProtoFileResolver
while interface registry does not. What do you think we ought to do?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe just enforce the check at the interface registry level, or allow a nil resolver and default to hybrid resolver. But duplicated fields in both options structures might be confusing right?
}, | ||
} | ||
for _, signer := range customGetSigners { | ||
signingOptions.DefineCustomGetSigners(signer.MsgType, signer.Fn) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because map is a pointer type?
@kocubinski could i pick your brain on this feature this week, trying to document it but feels a bit odd in how we do it |
Definitely |
Description
Closes: #16112
Introduces an API function in x/tx/signing
DefineCustomGetSigners
which can be called to register arbitrary signer fetching logic. Example registration with depinject via an invoker is shown in integration tests.Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...
!
to the type prefix if API or client breaking changeCHANGELOG.md
Reviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...
!
in the type prefix if API or client breaking change