OK, so some notes on this: The is_active flag on a user account isn't always reliable, because ultimately it's up to the auth backend to decide whether that's something worth looking at. The BrowserID auth stuff we use does *not* check for is_active, though we could probably have it do so. That would disable the ability of a banned account to log in. The solution Les brought up yesterday of doing this through permissions might be a far better option, though: things like the existing hooks for allowing editing could easily be expanded to disallow banned accounts even if they're still logged in (say, off a pre-existing session). For full functionality, though, we want the ability to ban an IP address, too. That's a bit more complicated; the existing rate-limiting apps available for Django, and quite a few ban-related middlewares floating around, are mostly geared toward shutting down *all* requests from an IP, and we just want to disable those that create/alter data. Probably the simplest solution would be a basic model with fields for an IP address and a couple of timestamps; that gets us the idea of "ban this IP from now to that future date" (since end-user IPs tend to be a bit dynamic), and is easy enough to check for from the relevant code.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Component: Docs Platform → Editing
Product: Mozilla Developer Network → Mozilla Developer Network
You need to log in before you can comment on or make changes to this bug.