Embedding Spaces with auth for public models counter-intuitive?

Spaces
1

I think I must be missing something. Can someone tell me what?

  1. Embedding spaces is a great option - but only available for public spaces
  2. The gradio instructions even show how to add authentication - awesome!
  3. But as your space is now public (because 1), you have to remember to add your auth credentials in a secret, otherwise anyone can just see it in your code
  4. Also, you have to make your space public to use the Embed option, while you may not have been ready to do so

My take: One of the clear use cases to use ā€œEmbed your spaceā€ is to share the app without sharing the code (e.g. prototype for something that is in stealth), but by only allowing the option for public spaces, that use case wonā€™t fly.

Am I missing something? Is there a better way to do this?

3 Likes
2

For anyone else reading this: I couldnā€™t find a good solution this for my situation, so I ended up running my Gradio application on one of the well known PaaS providers. Works quite well with github integration, just had to set a few environment settings.

I do want to stress that Iā€™m still a huge fan of Huggingface, and it may not make sense for the platform to support the ā€œstealthā€ scenario I describe above.

1 Like
3

Hello @EtheE, thank you for your feedback. We have received similar requests in the past, we might implement a solution it in the future. However, we have previously suggested different workarounds depending on the specific use case:

  • To hide sensitive source code on Space, you can create a private Space and a second public Space which only loads the private Space using the ā€˜gr.Interface.load()ā€™ method. This method can load a Space even if it is private. Check more her Gradio Docs.

  • To hide specific files only, you can create a private dataset/model and use the ā€˜huggingface_hubā€™ client to load your dataset/model using the hub token via Space settings.

  • You can also use our Inference Endpoints PaaS service which is fully integrated with HF tools and our hub. This service provides a way to deploy a Space as a REST API. You can learn more about it here Inference Endpoints - Hugging Face

4

Thanks @radames! Even though I searched, I hadnā€™t come across that first answer! While it introduces a bit of overhead, itā€™s definitely a good option and something Iā€™ll give another try in the near future.

1 Like
5

Thanks for the feedback, Iā€™ll update our Space docs

6

Hello @radames, thank you for the suggestions. I just tried the first option (load Space from a private Space), but the app throws this error if the source code Space is private:

File "/home/user/.local/lib/python3.8/site-packages/websockets/legacy/client.py", line 329, in handshake
    raise InvalidStatusCode(status_code, response_headers)
websockets.exceptions.InvalidStatusCode: server rejected WebSocket connection: HTTP 404

Maybe something change lately within Spaces?

IĀ“m using Gradio Blocks instead of directly use gr.load(), according to their documentation. Would this cause the problem?

7

However, using ā€˜gr.load()ā€™ method need user_token, which will be public in the second space.

8

hi @germanp, can you please make sure youā€™re on the latest Gradio version?, checking on the metadata on README.md

sdk: gradio
sdk_version: 3.27.0
1 Like
9

you can use the Spaces secrets to share your user_token, that will be on the server side on your Gradio app, Spaces Overview

10

Thank you for your response! I just tried it and it worked, but the output is empty while the referenced space works well. It takes the same amount of time as the referenced space, so I think it should have actually run, but there was no expected output.
My take: I use ā€˜gr.load().launch()ā€™, my spaceā€™s input is a image and output is a video.

11

another alternative is to try our new gradio client library, it also supports loading from a private Space

13

I guess that the video is stored in the referenced space, the output component use the path of the video, when it comes to the second space, it canā€™t find the video path in his own space, so the output is empty.

1 Like
14

I solved my problem perfectly with this solution. Thank you very much

1 Like
15

very cool @o0o0o00o0 , cc @freddyaboulton since Gradio client solved the issue :raised_hands:

16

@o0o0o00o0 @radames I tried this the gradio_client solution to call a private HF space of mine, but the API link I got (in the format of xxx-yyy.hf.space) is not sharable and can only be used by me. Is there a way make it sharable to others?
Using the gr.load() method I got into the same issue as @o0o0o00o0, where the output images are empty.

1 Like
17

Have you make the space which uses the gradio_client solution public?

18

Hi there, I get the following error when I try launching a public space.

for fn_index, dependency in enumerate(self.config["dependencies"])

KeyError: ā€˜dependenciesā€™

Would you know why this is happening?

19

Thanks for responding @o0o0o00o0 . I have made it public.
Just in case I misunderstood the instruction, hereā€™s my code for the new HF space, which should take image inputs from users and output images:

import os
from gradio_client import Client
HF_token = os.environ.get('HF_token')
client = Client('xxx/yyy', hf_token=HF_token )

The new space actually resulted in a runtime error:

Loaded as API: https://xxx-yyy.hf.space

and this API above is what I was referring to as not sharable.

2 Likes
20

Hi there, did you solve this?
I also got this error but donā€™t know what happened.

21

I am also getting the same error. Not able to load private space from public space with HF token