Add internal support for ratelimiting.

[kashalls]

When I wrote this 12 hours ago, I planned for most people to use an external source of ratelimiting like NGINX or Cloudflare. Some people are calling it tacky and overcomplicated, so I need to figure out a way to put it in the already condensed app.

I figured out how to middleware it, its just that its difficult to figure out what the real clients ip is for the sake of ratelimiting. You have to trust the proxy thats forwarding to the app to make sure it trusts the X-Forwarded-For or X-Real-Ip or CF-Connecting-IP, plus these IPs have a chance to be non-rfc compliant often having the forwarded ips seperated with commas like: 192.168.1.1,192,168.1.2,etc.

I guess I could set it up so that in the config, you have to specify which header to retrieve the connecting ip with? The http.Request.RemoteAddr in Go has been told to be very very unreliable as per stackoverflow.

[MrMarble]

This does not necessarily fix the issue, but if the intent of this program is to create badges for README files, shields.io default cache is 5 minutes (can be extended, but that's the minimum), so having a simple in-memory cache to avoid querying Prometheus every time could be useful as a simple rate limiting

[kashalls]

You're right, I did find out that some of the people using this already have instead pointed their Prometheus endpoint to the Thanos query frontend where you can use redis to cache the query for just enough time.

The ratelimit feature was intended as a solution for people who grab the url from the shields io image and try to spam the url. I think after further conversation we might decide to let the user to use a proxy that support this as this server is in no way recommended to be put on an edge server but rather behind nginx ingress or traefik.