Skip to content
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

Move policy from node repo #1

Conversation

masterSplinter01
Copy link
Contributor

Moved package policy from repository neofs-node.
Created Makefile and go.mod.

Copy link
Member

@roman-khimov roman-khimov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see .golangci.yml anywhere. And I don't think it's correct to refer to #116 in this way, because that's the neofs-node bug number, we can use nspcc-dev/neofs-node#116 though.

Makefile Show resolved Hide resolved
@masterSplinter01 masterSplinter01 changed the title Feature/116 move policy from node repo Move policy from node repo May 20, 2021
@masterSplinter01 masterSplinter01 force-pushed the feature/116-move-policy-from-node-repo branch from 5ed02af to 2c5d73d Compare May 20, 2021 15:29
.golangci.yml Outdated Show resolved Hide resolved
@masterSplinter01 masterSplinter01 force-pushed the feature/116-move-policy-from-node-repo branch from 2c5d73d to d5c6aed Compare May 20, 2021 15:46
…edit .gitignore

Add coverage and ide files to gitignore

Signed-off-by: Angira Kekteeva <[email protected]>
@masterSplinter01 masterSplinter01 force-pushed the feature/116-move-policy-from-node-repo branch 2 times, most recently from 80c0a7c to bb6dc71 Compare May 20, 2021 16:55
…romNetmap functions

fromNetmap func is used in the function that presents data of placement policy as json

Signed-off-by: Angira Kekteeva <[email protected]>
@masterSplinter01
Copy link
Contributor Author

Fixed linter warnings (except of grammar.go).

Copy link
Member

@roman-khimov roman-khimov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. Where the original version comes from? I see some difference between current state of pkg/policy of neofs-node and the thing we have here (and it'd be nice to specify neofs-node commit here anyway).
  2. You can do
diff --git a/pkg/policy/grammar.go b/pkg/policy/grammar.go
index 0a7ce7f..cc4220a 100644
--- a/pkg/policy/grammar.go
+++ b/pkg/policy/grammar.go
@@ -1,3 +1,4 @@
+//nolint:govet,golint // fails on struct tags here, but participle needs this syntax
 package policy
 
 import (

To fix linter warnings in grammar.go.

@masterSplinter01 masterSplinter01 deleted the feature/116-move-policy-from-node-repo branch May 20, 2021 19:27
cthulhu-rider added a commit that referenced this pull request Jul 31, 2024
Previously, any token w/o lifetime field was always considered as
invalid (expired in particular). In the protocol, the lifetime field's
absence is equivalent to all zero claims. Thus, `InvalidAt` and
`ExpiredAt` methods behaved correctly for all cases except default one.
At the same time, if user explicitly set all lifetime claims to zero -
token was not invalid at the epoch #0.

From now skipping a lifetime field in a token message is equivalent to a
field with all zeros. This change will only affect epoch #0 and will be
invisible in practice since the NeoFS network starts from epoch #1. In
addition, the internal structure of the type has been simplified.

Signed-off-by: Leonard Lyubich <[email protected]>
cthulhu-rider added a commit that referenced this pull request Aug 26, 2024
Previously, any token w/o lifetime field was always considered as
invalid (expired in particular). In the protocol, the lifetime field's
absence is equivalent to all zero claims. Thus, `InvalidAt` and
`ExpiredAt` methods behaved correctly for all cases except default one.
At the same time, if user explicitly set all lifetime claims to zero -
token was not invalid at the epoch #0.

From now skipping a lifetime field in a token message is equivalent to a
field with all zeros. This change will only affect epoch #0 and will be
invisible in practice since the NeoFS network starts from epoch #1. In
addition, the internal structure of the type has been simplified.

Signed-off-by: Leonard Lyubich <[email protected]>
cthulhu-rider added a commit that referenced this pull request Sep 18, 2024
Previously, any token w/o lifetime field was always considered as
invalid (expired in particular). In the protocol, the lifetime field's
absence is equivalent to all zero claims. Thus, `InvalidAt` and
`ExpiredAt` methods behaved correctly for all cases except default one.
At the same time, if user explicitly set all lifetime claims to zero -
token was not invalid at the epoch #0.

From now skipping a lifetime field in a token message is equivalent to a
field with all zeros. This change will only affect epoch #0 and will be
invisible in practice since the NeoFS network starts from epoch #1. In
addition, the internal structure of the type has been simplified.

Signed-off-by: Leonard Lyubich <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants