Skip to content

Consider filtering abusive requests to Weblate upstream

I see that Weblate gets tons of requests, presumably from security scanners, to random URLs that match the \.php\? regexp. There’s no PHP on this system and I don’t see ourselves adding .php files to translate in Weblate any time soon. It looks like the Weblate Python process spends lots of CPU time figuring out it should reply 404 to these requests. So I would suggest we short-circuit the handling of these requests, by configuring the upstream reverse proxy (nginx on www.lizard) to reject them with some kind of error, before they hit Apache or the WSGI Python process.

Of course, mod_security could do this and much more, but it requires quite some more work to set up and fine tune, so IMO we should not block on that if there’s a simple 3 lines solution that already fixes a great part of the problem. Happy to help on the nginx side if needed.

Parent Task: #16436 (closed)

Original created by @intrigeri on 16135 (Redmine)

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information