Repository navigation
Conversation
Not up to standards ⛔🔴 Issues
|
| Category | Results |
|---|---|
| CodeStyle | 1 minor |
🟢 Metrics 169 complexity
Metric Results Complexity 169
🟢 Coverage 53.94% diff coverage · +0.12% coverage variation
Metric Results Coverage variation ✅ +0.12% coverage variation (-1.00%) Diff coverage ✅ 53.94% diff coverage Coverage variation details
Coverable lines Covered lines Coverage Common ancestor commit (ba98b1d) 91152 22423 24.60% Head commit (7f6d24a) 91573 (+421) 22640 (+217) 24.72% (+0.12%) Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch:
<coverage of head commit> - <coverage of common ancestor commit>Diff coverage details
Coverable lines Covered lines Diff coverage Pull request (#3667) 545 294 53.94% Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified:
<covered lines added or modified>/<coverable lines added or modified> * 100%
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
619354d to
cee52aa
Compare
| return ErrEventsNotConfigured | ||
| } | ||
|
|
||
| share, err := s.validateShare(ctx, shareID) |
There was a problem hiding this comment.
Hm, when only requiring knowledge of the share id, which isn't particularly secret, anyone who knows that ID could terminate existing sessions.
I think we could maybe prevent this by requiring either the last token or the (expired) session here?
There was a problem hiding this comment.
you mean sessionToken?
There was a problem hiding this comment.
Right. Basically something only the user of the current session (=guestlink recipient) would know.
| if err := s.store.Redeem(rec.ShareIDHash); err != nil { | ||
| if errors.Is(err, storage.ErrAlreadyRedeemed) { | ||
| return nil, &RedeemError{ErrorType: ErrAlreadyRedeemed, ShareID: rec.ShareID} | ||
| if err := s.store.Update(rec.ShareIDHash, func(r *storage.Record) error { |
There was a problem hiding this comment.
With the option to create new tokens in Renew there's a little toctou race here now. After verifying the token and the share we only lock the record in Update, so if a renew happens in between the callback marks the new record as redeemed instead of the previous one.
We should add another check in the callback to catch those cases.
| Pin: pinStr, | ||
| Timestamp: now, | ||
| }); err != nil { | ||
| if rbErr := s.store.Update(token.Hash(shareID), func(rec *storage.Record) error { |
There was a problem hiding this comment.
Similarly to the race described above, we should only roll back if the record on disk still matches what we were working with in the first place
There was a problem hiding this comment.
Actually... maybe the update function itself should verify the record after locking instead of relying on all callers to be thorough.
We could implement it by storing a revision number in the records and adding a UpdateFrom(seen Record, fn func(*Record) error) (Record, error) function which verifies that the revision matches after grabbing the lock, for example (just a suggestion)
There was a problem hiding this comment.
that's actually a good idea
| } | ||
|
|
||
| func Hash(p string) (string, error) { | ||
| if p == "" { |
There was a problem hiding this comment.
nit: we could verify the length against Length instead.
|
needs a rebase, but the code itself looks good to me. |
f1197b9 to
63545a7
Compare
…ge has now revisions
cb104d7 to
7f6d24a
Compare
2 participants
closes: #3625
Renewal and PIN verification endpoints
dependent on: opencloud-eu/libre-graph-api#78