| Rate limiting (if by that you mean at the firewall or the web server) is not the way to do it. That shifts the problem somewhere else in the stack, into a place that isn't under version control in the same repository. Consider: If you moved this on to another server, would you remember to enable rate limiting there? If someone else uses your code, will they know to enable rate limiting? Rate limiting isn't a bad idea, but your security should not depend on it, especially as you have a way of securing it in your application. base64.b16encode(os.urandom(8)) will give you a 64-bit, filename-safe, as-close-to-random-as-reasonable suffix that should be long enough to make it brute-force-proof :) The same reasoning applies to the cron job (I presume) that is cleaning your files - that's something you have to remember to set up for future (re-)deployments. Edit: I'd also like to add that showing your code on HN takes bravery and this is, in fact, a neat tool that solves a problem I really wish didn't exist. So, good work on both counts :) |