Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Add helpers to handle OAuth in a FastAPI app #2684

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

Open
wants to merge 8 commits into
base: main
Choose a base branch
from

Conversation

Wauplin
Copy link
Contributor

@Wauplin Wauplin commented Nov 29, 2024

This PR imports the code to handle OAuth in gradio to huggingface_hub. Goal is to make it available for non-Gradio apps (say autotrain-advanced for instance @abhishekkrthakur).

I also added tests to make sure the workflow still works correctly. Thanks @coyotte508 for huggingface/huggingface.js#1050 and advices :)

Missing parts:

  • docstrings and documentation

I have flagged this feature as "experimental" to be able to introduce breaking changes in the future.
Note that for now, the integration only works for Spaces integrations but the same codebase could be tweaked to handle any kind of websites. That's lower priority though (the JS integration is much better for that).


Demo: https://huggingface.co/spaces/Wauplin/fastapi-oauth

@HuggingFaceDocBuilderDev

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

Copy link
Contributor

@hanouticelina hanouticelina left a comment

Choose a reason for hiding this comment

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

thanks a lot @Wauplin for the detailed code comments and the test suite ❤️ i guess this will be ready to merge after adding the documentation and fixing the test. also, let's open a PR in Gradio to remove the duplicated code after the release!

The org's profile picture URL. OpenID Connect field.
is_enterprise (`bool`):
Whether the org is an enterprise org. Hugging Face field.
can_pay (`Optional[bool]`, *optional*):
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
can_pay (`Optional[bool]`, *optional*):
can_pay (`bool`, *optional*):

same for the other optional attributes in this dataclass and OAuthUserInfo dataclass

from starlette.middleware.sessions import SessionMiddleware
except ImportError as e:
raise ImportError(
"Cannot initialize OAuth to due a missing library. Please run `pip install huggingface_hub[oauth]` or add "
Copy link
Contributor

Choose a reason for hiding this comment

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

(nit)

Suggested change
"Cannot initialize OAuth to due a missing library. Please run `pip install huggingface_hub[oauth]` or add "
"Cannot initialize OAuth due to a missing library. Please run `pip install huggingface_hub[oauth]` or add "

Comment on lines +65 to +67
# Little hack for the tests to work
# On staging, the redirect_url can be only "http://localhost:3000". Here I'm simply mocking the URL to work and
# remove any query parameters from the URL. In the test after the Hub call, we will replace back the URL with the
Copy link
Contributor

Choose a reason for hiding this comment

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

👍

Comment on lines +161 to +162
def test_get_mocked_oauth_info():
oauth_info = _get_mocked_oauth_info()
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
def test_get_mocked_oauth_info():
oauth_info = _get_mocked_oauth_info()
def test_get_mocked_oauth_info(monkeypatch):
monkeypatch.setenv("HF_TOKEN", TOKEN)
oauth_info = _get_mocked_oauth_info()

This should fix the failing test. Alternatively, one can patch the get_token() function

@echatzikyriakidis
Copy link

echatzikyriakidis commented Apr 25, 2025

Hi @Wauplin @hanouticelina and team 👋,

Thanks a lot for this great addition! 🙌
I noticed there are a few failing tests and merge conflicts currently blocking this PR.

Would it be possible to fix the failing checks and resolve the conflicts so this can be merged? My optimal scenario would be to have this included in the next huggingface_hub PyPI release (could this be done this week? 😜), as I need this feature urgently for a FastAPI integration.

Let me know if there's anything I can do to help speed things up! 🚀

@Wauplin Also, one small note: I noticed the same_site="none" setting for the OAuth session cookie. Just wanted to check if that’s intentional. While it enables cross-site requests (which might be needed), it’s also the least secure option and must be used with https_only=True. If full cross-site behavior isn't required, maybe same_site="lax" or even same_site="strict" could offer better security with minimal downsides?

Really appreciate all the work being done here.

Thanks again!

cc @coyotte508 @abidlabs

@Wauplin
Copy link
Contributor Author

Wauplin commented May 1, 2025

Hi @echatzikyriakidis, thanks for your feedback and glad to know you're interested in this feature! I would be keen to know what's your use case for HF+OAuth?

Regarding the timeline, I have to admit that we lowered its priority since I first worked on it. Short term I won't be able to work on it (ongoing parental leave 🤗). That been said, I'd be very open to an external contribution if you're up for it! Would you like to open a PR on top of my PR to push this to the finish line?

I just resolved the conflicts and hopefully it's a matter of documenting how to use it (+1 test to fix but can't remember why). If you already have a use case waiting for it, it'd be good to try it on your side as well (using pip install git+https://github.com/huggingface/huggingface_hub.git@add-oauth-helpers) and tell us if it suits your needs. Always easier to modify things before it's merged :)

@Wauplin
Copy link
Contributor Author

Wauplin commented May 1, 2025

Regarding same_site="none" we are indeed using it with https_only=True to mitigate security issues:

    app.add_middleware(
        SessionMiddleware,
        secret_key=hashlib.sha256(session_secret.encode()).hexdigest(),
        same_site="none",
        https_only=True,
    )

The problem is that we're using it for HF Spaces which are running under xxx.hf.space but the users are navigating to it on https://huggingface/co/spaces/xxx. Using same_site="none" is the only way we've found to work around third-party cookies issues on most browsers for the Gradio+Spaces integration (from which this PR comes from).

@echatzikyriakidis
Copy link

Hi @Wauplin, thanks so much for your reply and support!

I would be keen to know what's your use case for HF+OAuth?

At Medoid AI, we’ve built a new open-source project and we want to try publishing its demo as a HF Space. We’re using HF+OAuth to leverage users’ identities for rate limiting, since the app has a backend service and we need to manage usage. We also plan to release more open-source projects and demos with the same rate limiting setup on HF Spaces. So, not having this feature is currently a blocker for us when it comes to deploying demos with HF+OAuth.

Regarding the timeline, I have to admit that we lowered its priority since I first worked on it. Short term I won't be able to work on it (ongoing parental leave 🤗)

First of all, wishing you all the best on this incredible journey of becoming a parent! I hope everything goes smoothly for you.

Regarding the feature — were you the only one working on this? If others can help, is there a chance we could give it higher priority? I’m more than happy to check it, but I’m not sure what would be expected of me, and my time is also limited. I’m a bit concerned that if I take it on without the proper context or understanding of the process, it might actually cause more delays. Could you clarify how much effort is involved? Is this mainly a code review, documentation review, new code to be implemented, or something like integration or unit testing?

Regarding its usage, I’ve been using it for the past two weeks in a Space (a Dockerized web app based on FastAPI) by adding it in the requirements.txt file like this:

git+https://github.com/huggingface/huggingface_hub.git@add-oauth-helpers

It’s been working as expected, even with the latest commits from today after merging the main branch. However, I’m not sure if it will continue to work in the future, since we can’t lock the version with a PyPI package (this relates to HF_HUB_DISABLE_EXPERIMENTAL_WARNING). That’s why this is currently a blocker for us. Maybe we could go ahead and publish it, and just set a reminder to check for the official release so we can update the version then.

Regarding the same_site="none" setting — I understand it now. I also noticed in the browser’s inspect tools that the cookie is marked as Secure. Nice!

After performing thorough testing across the following dimensions:

  • Browsers (Brave, Firefox, Chrome, Edge)
  • Public and private Spaces
  • Access via hf.space and huggingface.co links
  • Normal and incognito/private browsing modes

I can say that it works smooth in the majority of the 32 test cases I ran. There are a few cases that I think are worth discussing, though I believe they are probably corner cases without security impact:

  • Accessing as private Space via hf.space links, I get a 404 HF page, which I believe is expected behavior.
  • If the end user clicks Sign In with Hugging Face → OAuth Form → Deny, the app returns an Internal Server Error.
  • In incognito mode and only in Chrome + huggingface.co link:
    • Accessing as public Space → Sign In with Hugging Face → OAuth Form → Authorize → results in a “huggingface.co redirected you too many times” error.
    • Accessing as private Space → Sign In with Hugging Face → results in a 404 HF page.

For us, all of the above, aren’t blockers for releasing the demo, and we can likely address them later — perhaps after the new PyPI version is released.

Hope this information help. What can we do from here to finalize this?

cc @coyotte508 @abidlabs @hanouticelina

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.

4 participants