-
Notifications
You must be signed in to change notification settings - Fork 619
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
Disable logging in with organization token #780
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the fix @merveenoyan .
Now that you're touching these bits, I realize there's quite a few repetitions. Could you maybe refactor those bits by creating a single _get_token
utility function which us used throughout the codebase instead of having the same logic multiple times?
I'm not attached to the _get_token
function name though.
@adrinjalali that's what I thought tbh when I saw them 😅 sure! |
I refactored & tested but will check if there's nits to do on Monday 🙂 |
src/huggingface_hub/hf_api.py
Outdated
token, name = name, token | ||
if isinstance(token, str): | ||
if token.startswith("api_org"): | ||
raise ValueError("You must use your personal account token for login.") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not just for login, since users might be passing the token as a param
src/huggingface_hub/hf_api.py
Outdated
if name is not None: | ||
return token, name | ||
else: | ||
return token |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you can always return token, name. It would then return None for the second case for name which is fine and will make usage easier
src/huggingface_hub/hf_api.py
Outdated
if token is None: | ||
token = self._validate_or_retrieve_token() | ||
elif not self._is_valid_token(token): | ||
if self._is_valid_token(name): | ||
warnings.warn( | ||
"`create_repo` now takes `token` as an optional positional argument. " | ||
"Be sure to adapt your code!", | ||
FutureWarning, | ||
) | ||
token, name = name, token | ||
else: | ||
raise ValueError("Invalid token passed!") | ||
token = self._validate_or_retrieve_token(function_name="create_repo") | ||
elif isinstance(token, str): | ||
token, name = self._validate_or_retrieve_token( | ||
token, name, function_name="create_repo" | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this can be simplified even further by just doing this:
token, name = self._validate_or_retrieve_token(
token, name, function_name="create_repo"
)
_validate_or_retrieve_token
already handles case in which token is None or string, so no need to do the check here. Same applies for other functions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can move _validate_or_retrieve_token
outside this class, move it to a utils module and use it also in the other file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@adrinjalali I recently pushed a new change but didn't do this yet, there's a repetition in user.py
if we don't do this, I agree. Will push that soon.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@adrinjalali it doesn't make any sense to put _validate_or_retrieve_token
under endpoint helpers, the function depends heavily on other classes and functions in hf_api.py
, so instead I called it in user.py
like hf_api._validate_or_retrieve_token
.
src/huggingface_hub/hf_api.py
Outdated
) | ||
else: | ||
raise ValueError("Invalid token passed!") | ||
token = self._validate_or_retrieve_token(function_name="upload_file") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be updated since the logic below is in validate_or_retrieve_token
?
I don't see anything else to refactor. I just have one question. What is the reason behind this in upload_file? (below is initial version)
Do people pass tokens in paths or files? I refactored assuming that. (it didn't make much sense to me though) @osanseviero |
I believe this is there only for backward compatibility. At some point the order of args were changed, and therefore this makes sure the older order is still accepted. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Otherwise LGTM
Co-authored-by: Adrin Jalali <[email protected]>
The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. |
src/huggingface_hub/hf_api.py
Outdated
name (``str``, `optional`): | ||
Name of the repository. | ||
function_name (``str``, `optional`): | ||
If called from a function, name of that function for deprecation warning. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing Returns
and Raises
sections.
It would also be nice to explain why name
and function_name
are required and that they'd be removed in a future version (in v0.7 maybe?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done!
…e_hub into disable_org_token
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This ended up being quite a bit more than the original issue (it's probably my fault 🙈 ). But I really like the improvement here. Thanks @merveenoyan
@adrinjalali what would you rather have, I really wonder 🙂 |
One could argue that the refactoring could or should have been a separate PR. But I'm glad this is done now. |
Note that this PR reverts docstrings changes needed for the new documentation (e.g. using |
Hello 👋 This PR solves this issue #658. I looked into code to see where the user might login and where tokens are checked. I've seen three cases:
We also check inside validate_or_retrieve token in case the token pulled is organization token.
So I added checks there and wrote tests for those three cases too.
cc: @osanseviero