LoginButton does not work with SSR

[CISC]

Describe the bug

Even though it should have been fixed in #9659 it does not work for me in Chat Template Editor. I've tried both with and without SSR.

It logs the following warning, but it did that already in 4.x and it works fine there, so not sure if it's releated:

UserWarning: LoginButton created outside of a Blocks context. May not work unless you call its `activate()` method manually.

Have you searched existing issues? 🔎

• I have searched and found no existing issues

Reproduction

import gradio as gr

with gr.Blocks(
) as blocks:
    with gr.Row():
        gr.LoginButton(
            "Sign in for write access or gated/private repos",
            scale = 1,
        )


if __name__ == "__main__":
    blocks.queue(
        max_size = 10,
        default_concurrency_limit = 10,
    )
    blocks.launch()

Screenshot

No response

Logs

No response

System Info

Gradio Environment Information:
------------------------------
gradio version: 5.3.0
gradio_client version: 1.4.2

------------------------------------------------
gradio dependencies in your environment:

aiofiles: 23.2.1
anyio: 4.6.0
fastapi: 0.115.3
ffmpy: 0.4.0
gradio-client==1.4.2 is not installed.
httpx: 0.27.2
huggingface-hub: 0.26.1
jinja2: 3.1.4
markupsafe: 2.1.5
numpy: 2.1.2
orjson: 3.10.7
packaging: 24.1
pandas: 2.2.3
pillow: 10.4.0
pydantic: 2.9.2
pydub: 0.25.1
python-multipart: 0.0.12
pyyaml: 6.0.2
ruff: 0.6.9
semantic-version: 2.10.0
starlette: 0.41.0
tomlkit==0.12.0 is not installed.
typer: 0.12.5
typing-extensions: 4.12.2
urllib3: 2.2.3
uvicorn: 0.31.0
authlib; extra == 'oauth' is not installed.
itsdangerous; extra == 'oauth' is not installed.


gradio_client dependencies in your environment:

fsspec: 2024.9.0
httpx: 0.27.2
huggingface-hub: 0.26.1
packaging: 24.1
typing-extensions: 4.12.2
websockets: 12.0

Severity

Blocking usage of gradio

[Wauplin]

duplicate of #8349? cc @abidlabs @hysts

[CISC]

duplicate of #8349?

Not really, it works in 4.x, even though it logs that warning, it does not work in 5.3.0.

[abidlabs]

Hmm it should have been fixed, but indeed it does't work for me either: https://huggingface.co/spaces/abidlabs/login-test

Will take a look sorry about that @CISC!

[abidlabs]

Ah I think the issue is SSR. If you explicitly disable SSR, then it works: https://huggingface.co/spaces/abidlabs/login-test-without-ssr

[abidlabs]

@dawoodkhan82 would you be able to take a look at this? My hunch is that some of the Oauth routes here are being rerouted to the Node server when SSR is enabled instead of being handled by the Python server.

[CISC]

Ah I think the issue is SSR. If you explicitly disable SSR, then it works: https://huggingface.co/spaces/abidlabs/login-test-without-ssr

Funny thing is I tried that, and it didn't work when I tested, but it works now, weird.

However there's now a new issue when you try to use the token I get the following error:

Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/gradio/queueing.py", line 624, in process_events
    response = await route_utils.call_process_api(
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/gradio/route_utils.py", line 323, in call_process_api
    output = await app.get_blocks().process_api(
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/gradio/blocks.py", line 2018, in process_api
    result = await self.call_function(
             ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/gradio/blocks.py", line 1567, in call_function
    prediction = await anyio.to_thread.run_sync(  # type: ignore
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/anyio/to_thread.py", line 56, in run_sync
    return await get_async_backend().run_sync_in_worker_thread(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/anyio/_backends/_asyncio.py", line 2441, in run_sync_in_worker_thread
    return await future
           ^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/anyio/_backends/_asyncio.py", line 943, in run
    result = context.run(func, *args)
             ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/gradio/utils.py", line 846, in wrapper
    response = f(*args, **kwargs)
               ^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/gradio/utils.py", line 846, in wrapper
    response = f(*args, **kwargs)
               ^^^^^^^^^^^^^^^^^^
  File "/home/user/app/app.py", line 985, in template_data_from_model_files
    if info and oauth_token and hfapi.get_token_permission(oauth_token.token) == "write":
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/huggingface_hub/hf_api.py", line 1691, in get_token_permission
    return self.whoami(token=token)["auth"]["accessToken"]["role"]
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^
KeyError: 'accessToken'

[abidlabs]

Hmm can you share a minimal repro?

[CISC]

I guess just calling hfapi.get_token_permission(oauth_token.token) is enough. To check that it's not a problem with this function I disabled it, but I get 403s later on, so it seems the problem is that the token is not valid somehow.

Nevermind, I was requesting the wrong permissions, the token works now, however it's weird that whoami seems to return incorrect data, not sure who/where to report that?

[Wauplin]

Hey, thanks for reporting this. The issue is different and related to huggingface_hub (see PR huggingface/huggingface_hub#2631 that I just opened). In practice, there is no need to check the permissions of the token before making the call as all oauth tokens of a given Space will have the same permissions (based on Spaces settings).

[abidlabs]

Great thanks @Wauplin! If the next version of huggingface_hub is released, @dawoodkhan82 let's bump the version in our requirements

[Wauplin]

@abidlabs you can but to be honest this fix is a very minor fix I'd say. The helper get_token_permission is almost never used (and shouldn't be)

[abidlabs]

Ah sorry I didn't read through the whole thread, I thought it was blocking the use of gr.LoginButton, nvm then!

[CISC]

Ah sorry I didn't read through the whole thread, I thought it was blocking the use of gr.LoginButton, nvm then!

Nope, just blocked in SSR mode, I'm fine with disabling it for now.