Anonymous `PutObject` request doesn't work #311

New issue

Closed

opened 2024-02-14 07:44:45 +00:00 by dkirillov · 0 comments

dkirillov commented

2024-02-14 07:44:45 +00:00

Member

We cannot PutObject using anonymous request even when bucket is public-read-write. Other operations works fine though.

Expected Behavior

PutObject (with --no-sign-request) is successful when bucket is public-read-write

Current Behavior

We get InternalError.
In logs:

2024-02-14T10:31:45.833+0300    error   handler/util.go:46      request failed  {"status": 500, "request_id": "6822aaa9-5e9e-4d10-b95a-bf1ffbd4aad3", "method": "PutObject", "bucket": "policy-test5", "object": "tmp", "description": "could not upload object", "error": "save object via connection pool: init writing on API client s01.frostfs.devenv:8080: client failure: status: code = 1024 message = (*putsvc.Streamer) different token issuer and object owner identifiers NbZwUUnt82vJWAcxddMqMbhYvJzGyvy2gE/NUUb82KR2JrVByHs2YSKgtK29gKnF5q6Vt", "body close errors": []}

Note:

NUUb82KR2JrVByHs2YSKgtK29gKnF5q6Vt is address of gate, and this value is used as owner of new object.
NbZwUUnt82vJWAcxddMqMbhYvJzGyvy2gE is randomly generated (once on startup) key for anonymous requests.

Possible Solution

Drop else branch here.
Probably we should do the same for other methods. It must be fair enough because when request is authenticated it must have bearer token, otherwise we always should use gate key to do frostfs requests

Steps to Reproduce (for bugs)

aws s3api --endpoint http://localhost:8084 create-bucket --bucket test public-read-write
aws s3api --endpoint http://localhost:8084 put-object --bucket test --key tmp --no-sign-request

An error occurred (InternalError) when calling the PutObject operation (reached max retries: 0): We encountered an internal error, please try again.

Regression

Probably yes.

Your Environment

Version used: cc34f659d1
Server setup and configuration: devenv

We cannot `PutObject` using anonymous request even when bucket is `public-read-write`. Other operations works fine though. ## Expected Behavior `PutObject` (with `--no-sign-request`) is successful when bucket is `public-read-write` ## Current Behavior We get `InternalError`. In logs: ``` 2024-02-14T10:31:45.833+0300 error handler/util.go:46 request failed {"status": 500, "request_id": "6822aaa9-5e9e-4d10-b95a-bf1ffbd4aad3", "method": "PutObject", "bucket": "policy-test5", "object": "tmp", "description": "could not upload object", "error": "save object via connection pool: init writing on API client s01.frostfs.devenv:8080: client failure: status: code = 1024 message = (*putsvc.Streamer) different token issuer and object owner identifiers NbZwUUnt82vJWAcxddMqMbhYvJzGyvy2gE/NUUb82KR2JrVByHs2YSKgtK29gKnF5q6Vt", "body close errors": []} ``` **Note**: * `NUUb82KR2JrVByHs2YSKgtK29gKnF5q6Vt` is address of gate, and this value is used as owner of new object. * `NbZwUUnt82vJWAcxddMqMbhYvJzGyvy2gE` is randomly generated (once on startup) key for anonymous requests. ## Possible Solution Drop `else` branch [here](https://git.frostfs.info/TrueCloudLab/frostfs-s3-gw/src/commit/cc34f659d17c314cc3273023e874b6c73d1744fe/internal/frostfs/frostfs.go#L256-L258). Probably we should do the same for other methods. It must be fair enough because when request is authenticated it must have bearer token, otherwise we always should use gate key to do frostfs requests ## Steps to Reproduce (for bugs) 1. `aws s3api --endpoint http://localhost:8084 create-bucket --bucket test public-read-write` 2. `aws s3api --endpoint http://localhost:8084 put-object --bucket test --key tmp --no-sign-request` ``` An error occurred (InternalError) when calling the PutObject operation (reached max retries: 0): We encountered an internal error, please try again. ``` ## Regression Probably yes. ## Your Environment  * Version used: https://git.frostfs.info/TrueCloudLab/frostfs-s3-gw/commit/cc34f659d17c314cc3273023e874b6c73d1744fe * Server setup and configuration: devenv