3 ms·
I'm stoked to see the webhooks get an overhaul. I was just about to use them for a project, and this'll be a great help. I wish they'd do similarly for the ser
by akerl_ 13y ago
I'm stoked to see the webhooks get an overhaul. I was just about to use them for a project, and this'll be a great help.
I wish they'd do similarly for the services. Currently, editing multiple services across repos is a bit of a pain, due to the length of the list and how it jumps you to the top on any interactions. (Originally, I thought this announcement meant they'd revamped that as well)
Out of curiosity, is there a generally-accepted best practice for rate-limiting / authenticating webhook pushes? I'm planning to run a daemon that listens for them, and while the effect of somebody finding the URL and hammering it isn't likely to be catastrophic, I'd still like to rate limit it if I can. Alternately, are GitHub's webhook-sending IPs static enough to put in an IP set and add to my firewall?
- atmos 13y agoYou can always get an updated list from http://developer.github.com/v3/meta/ http://developer.github.com/v3/meta/ but they're pretty static right now.
- jon-wood 13y agoIf I were building something to handle webhooks I'd probably have a really minimal API which just takes the message as it comes in and then queues it for later processing - that way you can either decide to let the queue back up, or add some more workers. Having said that, I'm pretty sure GitHub publish a list of their public IPs, so you could also limit what is allowed to call your API.