An Admin should be able to ban a user by IP address

[skord]

Fake email registrations are easy, even if you use devise's :confirmable option, it won't stop abusers or spammers.

Suggesting time-span configurable bans by IP address.

[mikegee]

I'm thinking this would require a new model (Ban?), that has an IP field and an expiration timestamp. Then, we would need a before_filter in controllers that checks if the client is banned. Admins could create a Ban based on the target user's current_sign_in_ip and/or last_sign_in_ip.

How's that sound?

[mikegee]

Would we want to delete or redact all the content from that user?

[mdarby]

Yeah, I'd have a Ban (Blacklist) model, and I would flag their content as "deleted", but I wouldn't actually delete it.

[mikegee]

Upon ban expiration, would we change the affected user(s) from banned back to contributor? Or is the user banned permanently, but the IP only temporarily?

[mdarby]

That sounds like an excellent admin option!

[skord]

In the imageboard I wrote a while back (https://github.com/skord/badhoc) I opted to allow redacting of content optionally. I'd imagine it'd be trivial to write a "redactor" into the user admin section, it's probably a better place to put such a thing. There are different cases for why a user would be banned. If it's someone who's just spamming, yeah, you'd want to delete or redact the content, but if someone who's a good contributor screws up and posts something illegal once you'd want to just redact the one thing and not ruin everything, such as positive contributions.

When a ban expires, I'd change the role from banned to contributor. This get a little tricky however because someone can sign up again with a secondary throw away email account from the same IP and be back in business if they are really persistent. Perhaps a validation in the User model against the blacklist would do the trick.

I'd say the IP's are banned separately from the user. Permabanning an IP is bad business, permabanning an account is not so bad.

I'd forked some rack middleware that consults the project honeypot blacklist and blocks at the rack level, it might be worth a look.

I'd consulted some imageboard admins when I'd created my own, which was meant to fix some fundamental flaws in the way they work, and there's yet another purpose for the Ban model that I got out of this -- banning access completely. It's trivial and I guess common to suck down as much bandwidth as you can from a site/forum to increase the bills. This is dealt with in the average imageboard by using .htaccess files, but well, that isn't going to work on Heroku.

So initially my thoughts are as such:

1. A Ban model that has the duration and start time of an IP ban.
2. Validations in Devise to keep IP bans from registering.
3. Booleans for read_banned and write_banned in the Ban model, perhaps different nomenclature, but the idea is the same.
4. Finding a way to enforce the read ban at the rack level dynamically (currently I don't know of such a solution)

[mikegee]

I don't see the need for the read_banned boolean. We don't even allow the banned IP to visit the site?

Rack-level Ban check sounds neat, but a controller before_filter might suffice.

I haven't tried adding validations to Devise, but again a before_filter in ApplicationController (or in Rack) might make that unnecessary.

[mdarby]

I'm tackling this today.

[mdarby]

Users can now be banned via @user.ban! in f84caf3 -- note that that User's last_sign_in_ip will also be banned. UI features will be added next.