Spaces:

---

ICML-2026-agent-repro

/

certificate-generator

Like 7

Running

+1 I’m also running into the same login issue with the certificate generator, and it looks like a few other participants have reported similar behavior as well:
https://huggingface.co/spaces/ICML-2026-agent-repro/certificate-generator/discussions/4
https://huggingface.co/spaces/ICML-2026-agent-repro/certificate-generator/discussions/2
https://huggingface.co/spaces/ICML-2026-agent-repro/challenge/discussions/39

It seems like this may be a broader authentication issue. Would the ICML Open Reproductions organizers be able to take a look when possible, or share an alternative way for eligible participants to generate their certificates in the meantime? CC: @abidlabs

Thanks so much for your help and for organizing the initiative!

Yes, it is happening to me as well

@ICML-2026 look into this issue please

made a PR to try and fix this. https://huggingface.co/spaces/ICML-2026-agent-repro/certificate-generator/discussions/8

Thanks for reporting, PR above has been merged.

Still have problem not same problem but now it is just blank.

I am also suffering from this problem.

After deployment of ed2b0a4, the Space displays only the heading and footer. The sign-in control, eligibility result, name field, and certificate generator never appear.

Observed

• Space root: HTTP 200
• /config: HTTP 200
• All /_app/immutable/... JS/CSS assets: HTTP 404
• Browser reports 77 failed asset requests
• /oauth-login: HTTP 303
• /login/huggingface: HTTP 302 to Hugging Face OAuth

Root cause

The OAuth fix replaced demo.launch() with:

app = gr.mount_gradio_app(app, demo, path="/")

Hugging Face enables SSR. In Gradio 5.49.1, SSR routing removes custom_mount_path using string replacement. When the mount path is /, this strips every slash from asset paths and creates invalid URLs such as:

Invalid port: '7868_appimmutableassets...'

The request then falls back to FastAPI and returns 404. Relevant Gradio routing code: routes.py (https://github.com/gradio-app/gradio/blob/gradio%405.49.1/gradio/routes.py#L419-L456).

Recommended fix

app = gr.mount_gradio_app(app, demo, path="/", ssr_mode=False)

Locally verified with the deployed source and Gradio 5.49.1:

• Root: 200
• Frontend JS asset: 200
• Config: 200
• on_load: returns sign-in control and status
• Queue endpoints: 200

Acceptance criteria

• No 404 responses for frontend assets.
• Logged-out users see the Hugging Face sign-in button.
• OAuth completes without a redirect loop.
• Eligible users can generate and download a certificate.
• Add an integration test that loads / and verifies its referenced frontend asset returns 200.
  @nielsr

Fixed by #8 and now deployed. OAuth login is launched in the top-level browser context, and stale session cookies are cleared before a new login attempt. The live Space is running the merged fix and the login route has been verified. Please reopen this discussion if the problem persists.

Reopening: the OAuth redirect is fixed, but the merged mounting change exposed a Gradio 5.49.1 SSR asset-routing regression that can leave the UI blank. I am applying the SSR correction and will re-verify frontend assets before closing this again.

Resolved in two parts: #8 fixed the OAuth redirect loop and stale-session handling; commit 11e61ce fixed the subsequent blank-page regression by disabling Gradio 5.49.1 SSR for the root-mounted app. The live deployment has been verified: root page 200, referenced frontend JS/CSS assets 200, queue/on-load requests 200, and /oauth-login clears stale state and redirects correctly. A regression test for frontend asset serving was added (3 tests passing). Please reopen if authentication still fails in a fresh attempt.