-
Notifications
You must be signed in to change notification settings - Fork 4
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
Add functions to create and handle UMA invoices. #39
Add functions to create and handle UMA invoices. #39
Conversation
d4edaee
to
03bd8e0
Compare
uma/uma.go
Outdated
invoiceLimit *uint64, | ||
senderUma *string, | ||
signingPrivateKey []byte, | ||
) (string, 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.
Should we be returning a string here or the invoice object directly?
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.
Changed to object
@@ -1011,3 +1020,64 @@ func VerifyPostTransactionCallbackSignature( | |||
} | |||
return verifySignature(*signablePayload, *callback.Signature, otherVaspPubKeyResponse) | |||
} | |||
|
|||
func CreateUmaInvoice( |
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 know we did things this way elsewhere in the uma go SDK, but I'm wondering if there are better object creation conventions in Go (I didn't really know Go well when I was making this sdk). For example, I've noticed that most libraries use the New* naming convention, like NewUmaInvoice
. I'm also wondering if it would make sense to have an options struct for the optional args, kind of like this article suggests. Totally optional suggestions, but figured it'd be good to see if we can do better this time from the start. I kind of regret how verbose and ugly some parts the go uma sdk are :-/... soooo many params lol.
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 one has to create an unsigned invoice and sign it. So I think we should stick with this method. However for other objects, we could utilize New
return protocol.FromBech32String(invoice) | ||
} | ||
|
||
func VerifyUmaInvoiceSignature(invoice protocol.UmaInvoice, otherVaspPubKeyResponse protocol.PubKeyResponse) 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.
Should this be a function on the invoice object instead? Might make it easier for folks to find the method.
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 think for now I'm going to to the verification here as it creates another object to get the unsigned payload. Also this follows the patter for other signature validation in this file.
03bd8e0
to
3090bce
Compare
3090bce
to
b7be542
Compare
Also bumped go-ethereum to newest version for lint and dep bot |
f9aba5b
to
d189933
Compare
d189933
to
895c295
Compare
No description provided.