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

[#65] Allow no sign requests #79

Merged
merged 3 commits into from
Jun 15, 2021
Merged

[#65] Allow no sign requests #79

merged 3 commits into from
Jun 15, 2021

Conversation

KirillovDenis
Copy link
Contributor

closes #65

Signed-off-by: Denis Kirillov denis@nspcc.ru

Signed-off-by: Denis Kirillov <denis@nspcc.ru>
@KirillovDenis
Copy link
Contributor Author

KirillovDenis commented Jun 11, 2021

I do not know if it is necessary to restrict the access rights of owner (neofs-key) when no sign request is provided

@roman-khimov
Copy link
Member

I do not know if it is necessary to restrict the access rights of owner (neofs-key) when no sign request is provided

A good question, actually. But I think in current scheme it's unavoidable, every NeoFS request is signed and signer automatically has all the rights he has, otherwise why signing it. So it comes down to deployment/key management, an open gateway should just use some unique keys (maybe even ephemeral ones like HTTP gateway).

list, err := n.containerList(ctx)
if err != nil {
containerID := new(cid.ID)
if err := containerID.Parse(name); err != nil {
Copy link
Member

Choose a reason for hiding this comment

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

Not sure why do you do this change?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

containerList(ctx) returns containers whose owner is request sender. If we interact with some public container but sender is not its owner returned list will be empty

Copy link
Member

Choose a reason for hiding this comment

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

It only works if we're using container ID as name, but we might as well use the name from attribute, so we need some logic to do that too. Your current code is at the same time an optimization for CID, so we can leave it, but instead of returning an error on the next line it should still try to fetch the container via listing (as was done by the old code). This way CIDs will work for public unauthenticated containers, but authenticated users could still access containers via names from attributes.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

What should we do if a public container is requested by name?

Copy link
Member

Choose a reason for hiding this comment

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

Return error, you can't list all containers to find the one with proper name.

Signed-off-by: Denis Kirillov <denis@nspcc.ru>
Looking container up using the owner list if its name is not cid

Signed-off-by: Denis Kirillov <denis@nspcc.ru>
@roman-khimov roman-khimov merged commit df150fb into nspcc-dev:master Jun 15, 2021
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.

Gateway doesn't process requests without credentials
2 participants