Last modified: 2007-12-05 06:58:00 UTC
Currently, when you block a username and check the "account creation blocked" field, it only prevents that username from creating accounts. Therefore, blocked users can simply log out, create a new account, and edit from that one to evade pretty much every block thrown at them. I am proposing, therefore, that the functionality should be changed to blocking the user's last-used IP from creating new accounts when a username is being blocked instead of it's current dysfunctional method.
There's a checkbox in the block form that says "Automatically block the last IP address used by this user, and any subsequent IPs they try to edit from". If you check that one also, it *should* work.
On a personal wiki, I blocked a vandal using the "Automatically block the last IP address used by this user, and any subsequent IPs they try to edit from" option. The user was subsequently able to create a new account and vandalize again. The recentchanges table indicates the IP address was identical for both accounts. Other users have reported the same issue, and Special:Userlogin has a comment indicating that this behavior may be intended: # Let's be nice about this, it's likely that this feature will be used # for blocking large numbers of innocent people, e.g. range blocks on # schools. Don't blame it on the user. There's a small chance that it # really is the user's fault, i.e. the username is blocked and they # haven't bothered to log out before trying to create an account to # evade it, but we'll leave that to their guilty conscience to figure # out. The option is pretty useless, especially on wikis in which direct database access isn't possible, if the user can simply log out and create a new account. In my opinion, the option should either be "fixed" to work as it says it will (i.e., blocking new account creation based on the last IP address used), or it should be modified / clarified / removed.
Marking WORKSFORME. If the autoblock is tripped, account creation fails as expected. If it's not tripped, creation succeeds. Seems to work according to spec; this was just an issue of autoblock either not be triggered by the user or autoblock being incorrectly configured.
