Conversation
|
Blocked by #3785. |
2a3b793 to
6aa3143
Compare
| } | ||
| } | ||
|
|
||
| privKey, err := x509.ParseECPrivateKey(rawKey) |
There was a problem hiding this comment.
Wow. We really use DER here.
There was a problem hiding this comment.
What's the problem with them?
There was a problem hiding this comment.
Not that it's a big problem, but not something I'd expect either. NeoGo never does it, for example. To be fair, the most appropriate storage format here would probably be NEP-2, but that can be done in #3426.
There was a problem hiding this comment.
can be migrated too if it is a problem
| zap.String("token_id", hex.EncodeToString(k)), | ||
| ) | ||
| } | ||
| // iterating over accounts |
There was a problem hiding this comment.
Iterating over all of them is a bad idea. Rather there should be an index like {epoch}{user.ID}, but that's a different issue.
There was a problem hiding this comment.
Is there already such an issue? Or should I create one?
There was a problem hiding this comment.
Please add an issue for it.
There was a problem hiding this comment.
I was thinking, how should we do GetToken then? It occurred to me that we could either have a separate bucket for such an index, in which case we would have two buckets, or GetToken would search by cursor, which removes O(1) token retrieval.
There was a problem hiding this comment.
You're storing {acc} -> {key} now, it can be {pref_0}{acc} -> {key}, then a separate {pref_1}{epoch}{acc} key without any value. Adding a key is adding two keys into the same bucket. Then checking for obsolete values is trivial, Seek() to {pref_1} and grab items till epoch is not current. Then drop all of them.
There was a problem hiding this comment.
Oh, I understand. I overthought it, just need another key.
6aa3143 to
175c665
Compare
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #3817 +/- ##
==========================================
+ Coverage 25.58% 25.62% +0.03%
==========================================
Files 667 667
Lines 42941 43011 +70
==========================================
+ Hits 10988 11021 +33
- Misses 30949 30974 +25
- Partials 1004 1016 +12 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
CHANGELOG.md
Outdated
| ### Changed | ||
| - SN retries notary requests if `insufficient amount of gas` error appears (#3739) | ||
| - Speed up metabase resync by using batch operations (#3804) | ||
| - Session key storage access session keys by account only (#3817) |
pkg/util/state/migratation.go
Outdated
| } | ||
| } | ||
|
|
||
| p.l.Info("duality token migration completed", |
There was a problem hiding this comment.
session token storage migration completed
And this can logged outside of transaction, btw.
|
|
||
| owners := make(map[user.ID]int) | ||
| c := rootBucket.Cursor() | ||
| for ownerKeyBytes, v := c.First(); ownerKeyBytes != nil; ownerKeyBytes, v = c.Next() { |
There was a problem hiding this comment.
Looks like this will be performed on every node start, while in fact it's needed only once. Can this be solved?
There was a problem hiding this comment.
If data has migrated, then their v != nil, meaning that continue will be called below, on the first check. Or should we avoid the for loop as well?
There was a problem hiding this comment.
Ideally you should just read something (no DB changes at all) and move on if there is nothing to do.
There was a problem hiding this comment.
Because Update() itself will write to the DB even if there are no changes done. Also we'd get a migration message when no migration was done in fact.
There was a problem hiding this comment.
If we assume that migration is performed only once and only for the old version of token storage, then before starting migration, we can first View the first key in the bucket, and if it has a value, which means that it is not a nested bucket, then the data has already been migrated. Is this option acceptable?
| } | ||
| } | ||
|
|
||
| privKey, err := x509.ParseECPrivateKey(rawKey) |
There was a problem hiding this comment.
Not that it's a big problem, but not something I'd expect either. NeoGo never does it, for example. To be fair, the most appropriate storage format here would probably be NEP-2, but that can be done in #3426.
| zap.String("token_id", hex.EncodeToString(k)), | ||
| ) | ||
| } | ||
| // iterating over accounts |
There was a problem hiding this comment.
Please add an issue for it.
| fatalOnErr(err) | ||
| } | ||
|
|
||
| err = persistate.MigrateSessionTokensToAccounts() |
There was a problem hiding this comment.
it gonna migrate until we remove it? can be tight to node's version. but no-op migration should not be a problem though
There was a problem hiding this comment.
I think we'll remove it at some point, but I don't know how to determine when that point will be.
pkg/util/state/migratation.go
Outdated
| } | ||
| privKey, err := p.extractKeyFromPackedToken(tokenData) | ||
| if err != nil { | ||
| if p.l != nil { |
| } | ||
| } | ||
|
|
||
| privKey, err := x509.ParseECPrivateKey(rawKey) |
There was a problem hiding this comment.
can be migrated too if it is a problem
ea12b52 to
18553f8
Compare
Contains obtaining auth key from session token. Also contains fix #3805. Signed-off-by: Andrey Butusov <andrey@nspcc.io>
There is no need to store session information in two formats in session key storage. An ID is not required, as it can be retrieved using the public key account of the open session. Closes #3793. Signed-off-by: Andrey Butusov <andrey@nspcc.io>
Closes #3793.