-
Notifications
You must be signed in to change notification settings - Fork 10
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
Playground API #14
Comments
To a certain extent this API already exists, but not quite in the form you describe:
The challenge refreshes every 24h; the point of that is to prevent stray POST requests from misconfigured crawlers. How high this risk actually is, I don't know, but I recall being recommended to do this by someone. |
@divarvel @frasertweedale We could really use your input on the subject of the API challenge token |
It doesn't give you any defence against a threat actor, but maybe it's reasonable for thwarting wayward crawlers? |
I don't think it's even possible to defend against threat actors here; the playground web interface needs to be able to start jobs, and anything that the website can do, anyone can do. So indeed the only point is to prevent misconfigured crawlers from submitting wayward jobs. I guess if no-one has had issues with this happening than it isn't important to have this "protection". |
Yeah, if the token delivery API does not perform any sort of checks whose results need to be remembered across requests, i don't see the value, outside of preventing crawlers from trigerring jobs (but the same effect could be achieved in various ways). One possible improvement would be to have something akin to CSRF protection. This would tie code execution requests to the actual page that displayed the code input. |
@divarvel What would CSRF protection actually do here? There is no concept of an account here, so I don't see what the difference would be with the current "challenge" setup. But I'm probably missing something because I have zero experience with CSRF tokens. :) |
it would not be a "real" CSRF token is the sense that it would not be there to prevent cross-site requests, but the implementation would be close to how CSRF tokens are usually implemented: the HTML payload contains a token that is used in requests emitted from the page. So yeah since there is no concept of user, the only thing this achieves is making harder to send a code execution request without actually displaying and interpreting the page. Since there is no authentication phase, any solution using tokens will only be there to make automated calls harder, but won't give any proper security guarantee. In that sense, IP-address based quotas would bring more guarantees (but not much against the aforementioned misbehaving crawler, since they tend to already use IP address pools to evade restrictions anyway). My suggestion would be to spend effort on monitoring first, and then put restrictions in place that protect against actually observed issues. |
I guess this is the right answer. I do have IP-address based spam protection already, so I guess it's unclear whether the current challenge system actually solves anything. Now the monitoring could also be improved... Anyway, the conclusion is that an API as specified by @Kleidukos would be fine. |
As discussed in #14, exact format slightly changed
With e85dd89 and 989cdc3 I believe this issue can be closed. @Kleidukos? |
@tomsmeding yes |
Loosely based on the same model as the Rust Playground's API, we can have an API to submit code to be evaluated and get the result back.
The payload would look like this:
Its usage would be integrated to the spam score.
The text was updated successfully, but these errors were encountered: