Skip to content
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

A flag to restrict predictions to come from the same domain where the server is running #2517

Open
abidlabs opened this issue Oct 24, 2022 · 3 comments
Labels
enhancement New feature or request
Milestone

Comments

@abidlabs
Copy link
Member

abidlabs commented Oct 24, 2022

It would be nice if a user could set a flag to only allow prediction requests to come from the same domain as where the web server is running. In particular, if a user is hosting their model on Spaces, they may only want requests to come from other Spaces.

Internal discussion: https://huggingface.slack.com/archives/C02136Y252P/p1666630955157749?thread_ts=1666447456.974249&cid=C02136Y252P

cc @freddyaboulton @aliabid94 @osanseviero @radames @apolinario

@abidlabs abidlabs added the enhancement New feature or request label Oct 24, 2022
@abidlabs abidlabs changed the title Make it possible to restrict prediction request to come from the same domain where the server is running Oct 24, 2022
@freddyaboulton freddyaboulton self-assigned this Feb 13, 2023
@abidlabs abidlabs added this to the 4.0 milestone Sep 29, 2023
@abidlabs
Copy link
Member Author

abidlabs commented Sep 29, 2023

We could consider re-working the api_open parameter to do this in 4.0

See https://huggingface.slack.com/archives/C02QZLG8GMN/p1695985205587149 (internal)

@abidlabs
Copy link
Member Author

abidlabs commented Oct 4, 2023

There are two ways we could implement this. Any preferences?

(1) Look at the referer header and ensure its the same as the server URL. This would not prevent Spaces to be called from another Space. These headers can also be spoofed pretty easily. (so doesn't completely prevent API usage).

(2) A more robust implementation would be to send a token from the backend to the frontend when the Gradio app is loaded. Making a prediction requires the frontend to send this token along with the prediction. These tokens have an expiry date (maybe 24 hours), so that someone can't simply read the token and hardcode it in the downstream application.

cc @osanseviero @apolinario @Wauplin @pngwn @freddyaboulton

@abidlabs
Copy link
Member Author

Won't have a chance to do this for 4.0, but we can do this after 4.0 by adding another parameter. Moving to the 4.x milestone

@abidlabs abidlabs modified the milestones: 4.0, 4.x Oct 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
2 participants