> For unauthenticated requests, the rate limit allows you to make up to 60 requests per hour. Unauthenticated requests are associated with your IP address, and not the user making requests.
In this case, all the comments for an issue are returned with a single API call, making the limit a nonissue (unless someone is binge-reading more than a post a minute)
Also, it may be a good idea to sanitize the comment.body_html. That seems XSS abuseable.
> Also, it may be a good idea to sanitize the comment.body_html. That seems XSS abuseable.
GitHub handles sanitizing comment HTML automatically. They use a fairly strict[1] whitelist of tags/attributes that are allowed through. Anything that's not allowed gets escaped.
Is the rate limit per API key, or per IP address sending the request? If it's counted by API key (which it sounds like it is), then the comments should stop working after 60 site visitors in an hour... But, if that's the case, wouldn't the influx of visitors from HN have already broken it?
It's per IP so if the loading is done in a distributed fashion, say via AJAX, it'll work fine.
I'm not aware of rate limits for individual repos. I think they can set it up if they want but it's not enabled by default. I remember a package manager hammering GitHub with anonymous requests that they limited but that was a special case.
> making the limit a nonissue (unless someone is binge-reading more than a post a minute)
The one issue that jumps to mind is for CGNAT'ed users if that rate limit is for site wide un-authed requests. CGNATing cell users is pretty popular here in the UK.
> For unauthenticated requests, the rate limit allows you to make up to 60 requests per hour. Unauthenticated requests are associated with your IP address, and not the user making requests.
In this case, all the comments for an issue are returned with a single API call, making the limit a nonissue (unless someone is binge-reading more than a post a minute)
Also, it may be a good idea to sanitize the comment.body_html. That seems XSS abuseable.