-
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
Account based eacl targets #592
Conversation
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.
correct under the hood, but i propose to extend/change API
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 not API repo changes first?
there will be one comment in docs, no binary protocol changes. But we wanna review the concept in practice. In total, yes, we'll have to merge this and API simultaneously @smallhive |
724f847
to
e3543cb
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #592 +/- ##
==========================================
+ Coverage 53.62% 53.69% +0.06%
==========================================
Files 164 164
Lines 19078 19113 +35
==========================================
+ Hits 10231 10262 +31
- Misses 8443 8447 +4
Partials 404 404 ☔ View full report in Codecov by Sentry. |
e3543cb
to
8b59b64
Compare
Updated to |
8b59b64
to
2c4e319
Compare
But still. |
2c4e319
to
bd1d702
Compare
eacl/target.go
Outdated
// SetAccounts sets list of accounts to identify target subject. | ||
// | ||
// Each element of the accounts parameter is a slice of bytes of [user.ID]. | ||
func (t *Target) SetAccounts(accounts [][]byte) { |
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 not just user.ID
then? it is even documented like this
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.
SetBinaryKeys
is deprecated now and changing SetAccounts
signature eliminates possibility to pass public keys
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.
do not see problems or do not understand. if we do not want users to use SetBinaryKeys
why we want them to be able to pass keys via SetAccounts
(a func that is even documented to be used with user.ID slices only)?
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 bet the reason is that we cannot keep getter and setter symmetry while having Set([]user.ID)
. Field is [][]byte
anyway, so it's pretty normal to accept/return value of this type. At the same time, we may provide functional helpers for those who desires to set []user.ID
(#592 (comment))
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.
Field is [][]byte anyway
the field should be kept as long as we have such eALCs set in public networks. but new eACLs should be filled with SetAccounts
and no keys should be accepted. at least that is how i see it
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.
new eACLs should be filled with SetAccounts and no keys should be accepted
it's questionable which ones are new. For example, if i need to add one rule to my existing table w/o touching previously set records - i dont expect the system to deny such table. It worked with N records, i expect it to work with N+1 ones. Yeah, i can refill they whole table, but this is inconvenient for me being a client
the field should be kept as long as we have such eALCs set in public networks
weve been through this before - its impossible to track this in general. We need to clearly define the moment after which support will be cut. This should be either a system timestamp or next major protocol version
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 we deprecate if we gonna support it? to me, that should work this way: 0.43.0 release (node and ir) supports both ways, 0.44.0 supports only accounts. "supports" means accepting new tables, old ones should always work until we understand there are no such tables in the contract
anyway, what is your understanding of public keys deprecation? how long are we gonna support it? till 1.0.0 SDK release? what definition will it have? SetAccounts(accounts [][]byte)
too?
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.
Keys will be supported for as long as needed.
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 for the method interface --- I'd really love to see more specific type here. It can be done symmetrically, the only problem is keys in existing eacls. Keys can be converted into standard accounts, but that can be misleading. We can treat them as separate entities though. We already have Role
concept in the Target
that is independent of Keys
. So we can also have Accounts
that are independent of them, you get keys (size-checked!) in BinaryKeys()
and you get accounts from Accounts()
, they can technically be mixed in the same eacl rule.
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.
all cases can be supported by functions around the most generic methods accepting/returning [][]byte
, so currently proposed approach is the most preferable to me cuz it is the closest to the protocol
bd1d702
to
74b1113
Compare
eacl/target.go
Outdated
// SetAccounts sets list of accounts to identify target subject. | ||
// | ||
// Each element of the accounts parameter is a slice of bytes of [user.ID]. | ||
func (t *Target) SetAccounts(accounts [][]byte) { |
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 for the method interface --- I'd really love to see more specific type here. It can be done symmetrically, the only problem is keys in existing eacls. Keys can be converted into standard accounts, but that can be misleading. We can treat them as separate entities though. We already have Role
concept in the Target
that is independent of Keys
. So we can also have Accounts
that are independent of them, you get keys (size-checked!) in BinaryKeys()
and you get accounts from Accounts()
, they can technically be mixed in the same eacl rule.
user/id.go
Outdated
@@ -82,6 +82,11 @@ func (x ID) WriteToV2(m *refs.OwnerID) { | |||
// Deprecated: use [NewFromScriptHash] instead. | |||
func (x *ID) SetScriptHash(scriptHash util.Uint160) { *x = NewFromScriptHash(scriptHash) } | |||
|
|||
// GetScriptHash gets scripthash from user ID. | |||
func (x ID) GetScriptHash() util.Uint160 { |
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 just be ScriptHash()
, no need to Get
.
74b1113
to
c024d0e
Compare
c024d0e
to
de87053
Compare
de87053
to
1cecfe2
Compare
@@ -45,7 +47,26 @@ func (t Target) CopyTo(dst *Target) { | |||
// | |||
// The value returned shares memory with the structure itself, so changing it can lead to data corruption. | |||
// Make a copy if you need to change it. | |||
// Deprecated: use [Target.Accounts] instead. |
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.
sounds a little strange to me: if i am using binary keys, using Accounts
does not solve my "deprication-message-from-linter" problem; can be like "using raw binary keys is not encouraged and will be dropped eventually, use Accoun-based targets instead". however, it is a minor problem
1cecfe2
to
6b22f9d
Compare
Refs #483. Signed-off-by: Evgenii Baidakov <[email protected]>
This is just a helper for scripthash extraction from user.ID. We can create user.ID from scripthash but don't have the option to do it vice versa. Signed-off-by: Evgenii Baidakov <[email protected]>
Signed-off-by: Evgenii Baidakov <[email protected]>
6b22f9d
to
c30d691
Compare
Refs nspcc-dev/neofs-api#278