-
Notifications
You must be signed in to change notification settings - Fork 38
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
getrangehash doesn't work with a bearer token created via cli #2541
Milestone
Comments
roman-khimov
added
bug
Something isn't working
neofs-cli
NeoFS CLI application issues
and removed
triage
labels
Sep 1, 2023
carpawell
added a commit
to carpawell/neofs-node
that referenced
this issue
Sep 7, 2023
Do it as it is already done for GET, HEAD, GETRANGE. In the case of a container node that does not have an object locally, the node spawns GETRANGE request in order to hash it. That is not allowed operation in the NeoFS. Even with nspcc-dev#1884, GET may fail because the node may not be a container part. Moreover, attached bearer token is not allowed for the node's key usage so that is another way to get unexpected results. Forwarding requests is the only sane fix for the nspcc-dev#2541. The code smells but this is not this commit's responsibility: it is hard to fix that bug nicely without a get service refactor. Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
carpawell
added a commit
to carpawell/neofs-node
that referenced
this issue
Sep 7, 2023
Do it as it is already done for GET, HEAD, GETRANGE. In the case of a container node that does not have an object locally, the node spawns GETRANGE request in order to hash it. That is not allowed operation in the NeoFS. Even with nspcc-dev#1884, GET may fail because the node may not be a container part. Moreover, attached bearer token is not allowed for the node's key usage so that is another way to get unexpected results. Forwarding requests is the only sane fix for the nspcc-dev#2541. The code smells but this is not this commit's responsibility: it is hard to fix that bug nicely without a get service refactor. Closes nspcc-dev#2541. Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
carpawell
added a commit
to carpawell/neofs-node
that referenced
this issue
Sep 7, 2023
Do it as it is already done for GET, HEAD, GETRANGE. In the case of a container node that does not have an object locally, the node spawns GETRANGE request in order to hash it. That is not allowed operation in the NeoFS. Even with nspcc-dev#1884, GET may fail because the node may not be a container part. Moreover, attached bearer token is not allowed for the node's key usage so that is another way to get unexpected results. Forwarding requests is the only sane fix for the nspcc-dev#2541. The code smells but this is not this commit's responsibility: it is hard to fix that bug nicely without a get service refactor. Closes nspcc-dev#2541. Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
carpawell
added a commit
to carpawell/neofs-node
that referenced
this issue
Sep 7, 2023
Do it as it is already done for GET, HEAD, GETRANGE. In the case of a container node that does not have an object locally, the node spawns GETRANGE request in order to hash it. That is not allowed operation in the NeoFS. Even with nspcc-dev#1884, GET may fail because the node may not be a container part. Moreover, attached bearer token is not allowed for the node's key usage so that is another way to get unexpected results. Forwarding requests is the only sane fix for the nspcc-dev#2541. The code smells but this is not this commit's responsibility: it is hard to fix that bug nicely without a get service refactor. Closes nspcc-dev#2541. Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
carpawell
added a commit
to carpawell/neofs-node
that referenced
this issue
Sep 14, 2023
Do it as it is already done for GET, HEAD, GETRANGE. In the case of a container node that does not have an object locally, the node spawns GETRANGE request in order to hash it. That is not allowed operation in the NeoFS. Even with nspcc-dev#1884, GET may fail because the node may not be a container part. Moreover, attached bearer token is not allowed for the node's key usage so that is another way to get unexpected results. Forwarding requests is the only sane fix for the nspcc-dev#2541. The code smells but this is not this commit's responsibility: it is hard to fix that bug nicely without a get service refactor. Closes nspcc-dev#2541. Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
carpawell
added a commit
to carpawell/neofs-node
that referenced
this issue
Sep 21, 2023
Do it as it is already done for GET, HEAD, GETRANGE. In the case of a container node that does not have an object locally, the node spawns GETRANGE request in order to hash it. That is not allowed operation in the NeoFS. Even with nspcc-dev#1884, GET may fail because the node may not be a container part. Moreover, attached bearer token is not allowed for the node's key usage so that is another way to get unexpected results. Forwarding requests is the only sane fix for the nspcc-dev#2541. The code smells but this is not this commit's responsibility: it is hard to fix that bug nicely without a get service refactor. Closes nspcc-dev#2541. Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
carpawell
added a commit
to carpawell/neofs-node
that referenced
this issue
Sep 21, 2023
Do it as it is already done for GET, HEAD, GETRANGE. In the case of a container node that does not have an object locally, the node spawns GETRANGE request in order to hash it. That is not allowed operation in the NeoFS. Even with nspcc-dev#1884, GET may fail because the node may not be a container part. Moreover, attached bearer token is not allowed for the node's key usage so that is another way to get unexpected results. Forwarding requests is the only sane fix for the nspcc-dev#2541. The code smells but this is not this commit's responsibility: it is hard to fix that bug nicely without a get service refactor. Closes nspcc-dev#2541. Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
roman-khimov
added a commit
that referenced
this issue
Sep 21, 2023
carpawell
added a commit
to carpawell/neofs-node
that referenced
this issue
Oct 23, 2023
Do it as it is already done for GET, HEAD, GETRANGE. In the case of a container node that does not have an object locally, the node spawns GETRANGE request in order to hash it. That is not allowed operation in the NeoFS. Even with nspcc-dev#1884, GET may fail because the node may not be a container part. Moreover, attached bearer token is not allowed for the node's key usage so that is another way to get unexpected results. Forwarding requests is the only sane fix for the nspcc-dev#2541. The code smells but this is not this commit's responsibility: it is hard to fix that bug nicely without a get service refactor. Closes nspcc-dev#2541. Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Related to nspcc-dev/neofs-testcases#621
Current Behavior
getrange
andgetrangehash
)getrangehash
:In logs there are the following entries at the time of the failure:
Expected Behavior
The command should work with this bearer token. All other operations work ok.
Steps to Reproduce
test_bearer_token_expiration
- allure.tar.gzRegression
(No)
Your Environment
Run on current latest master of neofs-node - 9871712
The text was updated successfully, but these errors were encountered: