* Make IP bans soft deletable.
* Add a hit counter to track how many times an IP ban has blocked someone.
* Add a last hit timestamp to track when the IP ban last blocked someone.
* Add a new type of IP ban, the signup ban. Signup bans restrict new
signups from editing anything until they've verified their email
address.
Use validations instead of raising an exception when the password is
incorrect so that the controller can display errors sensibly.
Also fix users being logged out even when the deletion attempt failed
due to an incorrect password.
- "Current" is now most like the old format
-- It is therefore now the default for post versions
- Only show the actual edits in their own column
- Show the current state at that version in another column
- On the "previous" view, don't double-show full list of tags for
the first post versions, so leave edits blank
When random mode is enabled @post_set.posts returns an array, which
caused `authorize` to try to lookup the wrong policy.
This only happens when `authorize` is given an array with more than one
element, which is why it wasn't caught by the tests.
* Make authentication methods into User instance methods instead of
class methods.
* Fix API key authentication to use a secure string comparison. Fixes a
hypothetical (unlikely to be exploitable) timing attack.
* Move login logic from SessionCreator to SessionLoader.
Require users who signup using proxies to verify their email addresses
before they can perform any edits. For verification purposes, the email
must be a nondisposable address from a whitelist of trusted email
providers.
Pull the password reauthentication logic out of the user model and put
it in the password update controller where it belongs.
This fixes an issue where when a new user was created the user model had
an incorrect password error set on it by `encrypt_password_on_update`.
It was trying to verify the old password even though we don't have one
when creating a new user. This error caused the user create action to
redirect back to the signup page because `respond_with` thought that
creating the user failed.
Reject email addresses that known to be undeliverable during signup.
Some users signup with invalid email addresses, which causes the welcome
email (which contains the email confirmation link) to bounce. Too many
bounces hurt our ability to send mail.
We check that an email address is undeliverable by checking if the
domain has a mail server and if the server returns an invalid address
error when attempting to send mail. This isn't foolproof since some
servers don't return an error if the address doesn't exist. If the
checks fail we know the address is bad, but if the checks pass that
doesn't guarantee the address is good. However, this is still good
enough to filter out bad addresses for popular providers like Gmail and
Microsoft that do return nonexistent address errors.
The address existence check requires being able to connect to mail
servers over port 25. This may fail if your network blocks port 25,
which many home ISPs and hosting providers do by default.
Side effects:
* The data-current-user-is-voter <body> attribute has been removed.
* {{upvote:self}} no longer works. {{upvote:<name>}} should be used instead.
