-
Couldn't load subscription status.
- Fork 15
Added address Verification #1
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
Conversation
I have to add reference to https://cardano.stackexchange.com/q/2498/4255
And give kudos to: https://cardano.stackexchange.com/users/2815/jeroen
Linking PR with the Issue ticket #2
Hey buddy, do you need some help with this? Give me a shout if I can help somehow :D
Really sorry! Work and life got in the way of this one!! I will schedule a few hours next week to get this done.
Really sorry! Work and life got in the way of this one!! I will schedule a few hours next week to get this done.
No problems, I completely understand. Take your time and let me know if you need anything 😄
Do we want to look at getting this Merged? If you have time to do a further review?
Do we want to look at getting this Merged? If you have time to do a further review?
Hi there, I'll take a look at it later today ⏰
...no-token into feature/cip30
I hate JS!
RewardAddress is not a standalone Object!
Check this out.
...ould use TypeScript
...ould use TypeScript
@gavinharris-dev Hi, I see that you're making quite a lot of progress. Request review when you are ready.
Also, if you could remove the commited dist directory it would be awesome 🙌🏻
chrizcros
commented
Apr 7, 2022
Hey @gavinharris-dev @pyropy wanted to check if there is any progress on this pull request?
When I test out the PR I got the error:
Error: "signature" argument should be a function that returns a signature string (Promise<string>) at _callee$ (sign.ts?b2ef:9:1) at tryCatch (runtime.js?96cf:63:1) at Generator.invoke [as _invoke] (runtime.js?96cf:294:1) at Generator.eval [as next] (runtime.js?96cf:119:1) at asyncGeneratorStep (asyncToGenerator.js?1da1:3:1) at _next (asyncToGenerator.js?1da1:25:1)
The reason is that api.signData is a string and not an object:
image
await Web3Token.sign((msg: string) => api.signData(address, toHex(msg)), '1d')
Do you have an idea how to handle that?
Hi @bieric,
Here is an example that I am currently using in our Application. This is using my main branch i.e.,
"dependencies": {
...
"web3-cardano-token": "gavinharris-dev/web3-cardano-token",
...
}
const getLoginToken = async (wallet) => {
const address = await wallet.getUsedAddresses();
if (!address || address.length === 0) {
throw new Error('No wallet address');
}
return await Web3Token.sign(async (msg) => {
return await wallet.signData(address[0], Buffer.from(msg).toString('hex'));
});
};
Wallet.signData (according to CIP30 and implemented on Nami Wallet) will return the type DataSignature which is structured as such:
type DataSignature = {|
signature:cbor\<COSE_Sign1>,
key: cbor\<COSE_Key>,
|};
The DataSignature type is the expected return type for the Callback method provided into Web3Token.sign.
Note: Older versions of Nami Wallet (and perhaps other Wallets) returned a CBOR String as a result of the signData method, I should probably (when allowing users to link a wallet) check that not only is the Wallet supported, but also the Version provided is supported.
In terms of getting this PR merged in, I think (with the extend of the code changes) it would be highly useful to get the code reviewed again. Also really need to work out how to write some Unit Tests for these changes! I need to verify several things now:
- Provided Token is Signed correctly; i.e., with the Private Key of the supplied Address,
- Provided Token has not been tampered with, i.e., the Signature matches a 'recalculated' signature,
- Provided Token is still 'in date'; I.E., has not expired,
I also think that there is a discussion around packaging; I have on my branch the Dist folder where I have the build artifacts available. This is probably undesirable but I'm too new to developing JS modules to know what the process should be; so any tips would be appreciated!
bitlands
commented
Apr 18, 2022
@gavinharris-dev Thank you a lot for your detailed description!
Unfortunately, I have still some problems.
I'm trying it with Nami and Eternl wallet.
I guess eternl is still returning the CBOR string.
image
Nami has other problems (v3.2.1):
image
My questions:
- What wallet/version do you use?
- When a wallet returns a CBOR string do you have an example of how to handle it?
I also want to help maintain this repository since it could be a huge deal for the Cardano community but first I would like to have a working example to better understand it.
Thank you in advance!
What wallet/version do you use?
We use Nami 3.2.1 and get good results. The error you are getting with Nami appears to be thrown in 3 places (in the Nami code):
Without seeing how you are using the library I'm not really able to help much here. Perhaps print out the inputs that you are sending to signData so that you can verify that they are valid HEX encoded values (you need to verify that the address input is in-fact an address and that the 'data' can be decoded back to plain text).
Perhaps if you can post a small example that we can work through it?
When a wallet returns a CBOR string do you have an example of how to handle it?
This is a great question; @pyropy should we be looking to support the 'old' sign data structure? It looks like the community has settled towards the CIP30 version of signData and so my opinion would be that we would not support the return of CBOR string.
@pyropy Do these discussions need to move into an Issue / Discussion rather that a Pull Request?
bitlands
commented
Apr 22, 2022
@gavinharris-dev Thank you a lot I've found the issue. I've decoded the address to the readable string and not let it in the hex format. That's why the signer fails.
Thank you again!
Hey folks, sorry for being absent lately -- I've focused mostly on my day job.
@gavinharris-dev When wallet returns CBOR I guess simplest way is for user to simply handle the decoding process -- we should always stick with the CIP implementation.
Is the PR ready to be reviewed?
chrizcros
commented
May 4, 2022
@pyropy I agree. Yes I think so. I've tested it with Nami and it works good.
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.
Everything looks awesome! Thank you so much for your contributions so far 🎉
I'll test it and once we're sure that it's working properly I'm going to merge it finally 😮💨
package.json
Outdated
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 would stick with version 0.1.0 here perhaps. If the API has no breaking changes then I would just increase it to 0.0.13.
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.
Types ❤️
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.
Can we stick with arrow function types? Also we should make first letter of the function uppercase ⏫
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.
Is .js needed for import?
@chrizcros
chrizcros
May 4, 2022
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.
No its not needed
chrizcros
commented
May 4, 2022
@pyropy Do you have an example how to decode the cbor string to make other wallets compatible?
@bieric You should be able to decode CBOR using some libraries -- for example here's an JS library for encoding/decoding CBOR
Added the method
verifyAddress; this method takes the provided Public Key and Address (supplied by the signing processsignData) and we attempt to recreate the address.To recreate the address we get the
stakeKeyHashand combine it with thepublicKeyHashto create a 'reconstructed' address. We then verify that both the 'reconstructed' address matches the address provided when signing the data (token).This change is to try and prevent actors spoofing a token. Prior to this change, in theory (in my head so it may not be correct) a user could create a signed token with any address as there was no verification that the Public Key (used to verify that the token has not been tampered with) belongs to the address that this token is making claim to.