Fix zero gpu auth ignoring hf_token

[Saghen]

Description

When sending requests to a ZeroGPU endpoint via the JS client on node, the client would attempt to index window while getting credentials, causing an error. The logic has been changed to prefer the hf_token, falling back to the post_message if the window is available, and finally falling back to null.

I have not included an issue due to the size of the PR, as per the PR template, but will add if needed!

[gradio-pr-bot]

🪼 branch checks and previews

•	Name	Status	URL
	Spaces	ready!	Spaces preview
	Website	ready!	Website preview
🦄	Changes	detecting...

---

Install Gradio from this PR

pip install https://gradio-builds.s3.amazonaws.com/ee05c5e1bb523eae5c8483c0afe00c872d148688/gradio-4.31.4-py3-none-any.whl

Install Gradio Python Client from this PR

pip install "gradio-client @ git+https://github.com/gradio-app/gradio@ee05c5e1bb523eae5c8483c0afe00c872d148688#subdirectory=client/python"

[cbensimon]

Nice catch @Saghen!

One point though: isn't the Authorization header already set elsewhere in the client ? zero_gpu_auth only aims to add additional headers specifically supported by the ZeroGPU Spaces infra.

Otherwise, totally agreed that we should make the code Node compatible so checking the window object seems reasonnable. @abidlabs do you confirm that the JS client should target NodeJS ? Shouldn't the CI somehow check the compatibility with Node then ?

[gradio-pr-bot]

🦄 change detected

This Pull Request includes changes to the following packages.

Package	Version
@gradio/client	minor
gradio	minor

• Maintainers can select this checkbox to manually select packages to update.

With the following changelog entry.

Fix zero gpu auth ignoring hf_token

Maintainers or the PR author can modify the PR title to modify this entry.

Something isn't right?

• Maintainers can change the version label to modify the version bump.
• If the bot has failed to detect any changes, or if this pull request needs to update multiple packages to different versions or requires a more comprehensive changelog entry, maintainers can update the changelog file directly.

[abidlabs]

@abidlabs do you confirm that the JS client should target NodeJS ? Shouldn't the CI somehow check the compatibility with Node then ?

Let me tag @hannahblair who can review this PR better than me

[Saghen]

One point though: isn't the Authorization header already set elsewhere in the client ? zero_gpu_auth only aims to add additional headers specifically supported by the ZeroGPU Spaces infra.

Yep, thanks! Removed that logic

[pngwn]

Beautiful, thank you @Saghen!

[pngwn]

@cbensimon

@abidlabs do you confirm that the JS client should target NodeJS ?

The client should (and will eventually) work on all platforms, not just node + browser but also cf workers, service workers, deno, etc.

Shouldn't the CI somehow check the compatibility with Node then ?

Yes, and it kind of does but we don't have any tests for zero gpu atm.

[cbensimon]

Yes, and it kind of does but we don't have any tests for zero gpu atm.

@pngwn I was talking about static (typing) tests (they should catch this "window is possibly undefined" thing I think)

[pngwn]

Since it has to work in both environments it isn't an error to reference the window as sometimes that is present. We don't run type checks twice (once for each environment).

[cbensimon]

it isn't an error to reference the window as sometimes that is present

Since we want both browser and NodeJS compatibility, to me it is actually an error to not check for existence before using the window object (and I think that typescript can be configured to handle this and make projects both browser and NodeJS compatible but I'm not 100% sure)