-
Notifications
You must be signed in to change notification settings - Fork 14
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
Simpilfy user id derivation from key #475
Simpilfy user id derivation from key #475
Conversation
@@ -354,7 +354,8 @@ func (b Token) SigningKeyBytes() []byte { | |||
// Returns zero user.ID if Token is unsigned or key has incorrect format. | |||
// | |||
// See also SigningKeyBytes. | |||
func ResolveIssuer(b Token) (usr user.ID) { | |||
func (b Token) ResolveIssuer() user.ID { |
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 where neofsid
or anything like that fails miserably, btw.
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 I drop this commit?
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'm not sure about keeping user.IDFromKey
. We can try moving its code to bearer
thus removing it from public API. If anyone's got a keys.PublicKey
, he can do id.SetScriptHash(pk.GetScriptHash())
. If he's got bytes, then pk.DecodeBytes(key)
(and associated error handling) is not that hard as well.
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.
Moved IDFromKey
to bearer
7afb608
to
ecef897
Compare
// ECDSA with SHA-256 hashing (RFC 6979). Provides [Signer] interface. | ||
// | ||
// Instances SHOULD be initialized with [NewSignerRFC6979] or [NewSignerRFC6979WithID]. | ||
type SignerRFC6979 struct { |
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.
they are literally named the same (user.SignerRFC6979
and neofsecdsa.SignerRFC6979
). was it discussed too? @cthulhu-rider, @roman-khimov
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 it a problem?
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.
well, one is the "original" while the other one is a wrapper over the first one. also user.Signer*
confuses me (but *ecdsa.Signer*
is clear). also, it reminds me of the problem of reading some neofs-node code when it is not clear what struct is here: sdk or api-go
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.
Any alternative?
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.
as i understand, you have already discussed it so i am only able to suggest naming with User
, Wrapper
, WithID
. all of them are bad if the whole concept is taken as the only way
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.
user.UserSmth
is not a good thing. SignerRFC6979WithID
seems to be longer than most people would like it to be. Wrapper
is meaningless. If we don't have any better options then we can go with the current one.
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.
OK otherwise.
Conflict. |
Signed-off-by: Evgenii Baidakov <evgenii@nspcc.io>
Signed-off-by: Evgenii Baidakov <evgenii@nspcc.io>
Signed-off-by: Evgenii Baidakov <evgenii@nspcc.io>
Signed-off-by: Evgenii Baidakov <evgenii@nspcc.io>
c74f989
to
8be458e
Compare
Rebased |
closes #428