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

Try anon=True if no credentials are supplied or found #823

Merged
merged 6 commits into from
Dec 3, 2023

Conversation

BENR0
Copy link
Contributor

@BENR0 BENR0 commented Nov 14, 2023

This PR tries to use anon=True if no credentials are supplied or found in config files

The print statement should probably be changed to a warning also help with the tests would be appreciated.

Copy link
Member

@martindurant martindurant left a comment

Choose a reason for hiding this comment

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

Actually, it looks simpler that I has feared.

You should be able to make a test by monkeypatch on ProfileProviderBuilder.load_credentials() to make sure anon gets selected.

s3fs/core.py Outdated Show resolved Hide resolved
s3fs/core.py Outdated
@@ -137,6 +138,12 @@ async def _error_wrapper(func, *, args=(), kwargs=None, retries):
except Exception as e:
err = e
err = translate_boto_error(err)

s3 = func.__self__
if isinstance(err, PermissionError) and s3._client_config.signature_version == botocore.UNSIGNED:
Copy link
Member

Choose a reason for hiding this comment

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

Other exceptions might be possible, such as credentials that exist but have expired. I'll test this later (since our corp account has expiring tokens).
Is s3._client_config.signature_version == botocore.UNSIGNED guaranteed to be the same as self.anon ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Were you able to test this?

I am not sure if anon is guaranteed to be the same as botocore.UNSIGNED but as far as I could see it seems like it. It would be nice though if somebody with more experience with botocore can confirm this.

Copy link
Member

Choose a reason for hiding this comment

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

I am suggesting

Suggested change
if isinstance(err, PermissionError) and s3._client_config.signature_version == botocore.UNSIGNED:
if isinstance(err, PermissionError) and self.anon:

s3fs/core.py Outdated Show resolved Hide resolved
s3fs/core.py Outdated
if credentials is None and self.key is None and self.secret is None and self.token is None and not self.anon:
self.anon = True
else:
self.key = credentials.access_key
Copy link
Member

Choose a reason for hiding this comment

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

Is there a reason to set these values? They will never get used again.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I added this because the values are used a couple of lines below in the init_kwargs dict. I think it should also work without because somewhere down the line it should be tried to load the credentials from configs like I did above with the credential_resolver but my reasoning was that credentials get loaded from configs here they can directly be supplied and don't need to be checked again later with the credentials resolver.

Copy link
Member

Choose a reason for hiding this comment

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

Oh wait, but what if the user supplied key/secret/token as kwargs, didn't they get lost here? The kwargs passed to Session above don't include these.

Copy link
Member

Choose a reason for hiding this comment

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

Actually, is anon=True and there really are no creds, we get to this path too, and

AttributeError: 'NoneType' object has no attribute 'access_key'

Copy link
Member

@martindurant martindurant left a comment

Choose a reason for hiding this comment

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

I'm going to look into this...

s3fs/core.py Outdated
if credentials is None and self.key is None and self.secret is None and self.token is None and not self.anon:
self.anon = True
else:
self.key = credentials.access_key
Copy link
Member

Choose a reason for hiding this comment

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

Oh wait, but what if the user supplied key/secret/token as kwargs, didn't they get lost here? The kwargs passed to Session above don't include these.

s3fs/core.py Outdated
if credentials is None and self.key is None and self.secret is None and self.token is None and not self.anon:
self.anon = True
else:
self.key = credentials.access_key
Copy link
Member

Choose a reason for hiding this comment

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

Actually, is anon=True and there really are no creds, we get to this path too, and

AttributeError: 'NoneType' object has no attribute 'access_key'

@martindurant
Copy link
Member

I ended up only doing the lookup when we are certain the user has no creds of their own. How does this look?

@BENR0
Copy link
Contributor Author

BENR0 commented Nov 23, 2023

Yes I think that should work. Nice refactor of the PermissionError :-).

So only unittests missing now right?

@martindurant martindurant merged commit 8a87309 into fsspec:main Dec 3, 2023
21 checks passed
@BENR0 BENR0 deleted the feat_anon_true_default branch December 4, 2023 09:33
martindurant added a commit to martindurant/s3fs that referenced this pull request Dec 5, 2023
@martindurant martindurant mentioned this pull request Dec 5, 2023
martindurant added a commit that referenced this pull request Dec 5, 2023
* Revert "Don't assume attributes after connect (#832)"

This reverts commit cc6663f.

* Revert "Try anon=True if no credentials are supplied or found (#823)"

This reverts commit 8a87309.
@bsipocz
Copy link

bsipocz commented Jun 8, 2024

I was so happy to see this feature, but then saw that it got reverted. So just leave this message, that we run into this same problem, too. (But I expect most of the anon=True cases can be hidden away in the client library rather than telling our users to directly work with the parquet files)

@martindurant
Copy link
Member

I'm sorry: unfortunately, it led to far more problems than it solved. I'd be happy to see a more solid implementation, if some wants to try.

@BENR0
Copy link
Contributor Author

BENR0 commented Jun 12, 2024

@bsipocz I still really would like this also. I am willing to work on this again but I think it seems like I might not have enough knowledge to foresee possible problems as was apparent. I someone is willing to step in and point me in the right direction it would be appreciated. I think the solution itself is not really bad but needs some more refinement.

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.

ENH: Eliminate the need for anon=True when you might be opening a public bucket & object.
3 participants