* Refactor various user limit methods to class methods from instance
methods so they can be used outside the context of a single user.
* Remove the Danbooru.config.base_tag_query_limit option.
Add a model to store the status of user upgrades.
* Store the upgrade purchaser and the upgrade receiver (these are
different for a gifted upgrade, the same for a self upgrade).
* Store the upgrade type: gold, platinum, or gold-to-platinum upgrades.
* Store the upgrade status:
** pending: User is still on the Stripe checkout page, no payment
received yet.
** processing: User has completed checkout, but the checkout status in
Stripe is still 'unpaid'.
** complete: We've received notification from Stripe that the payment
has gone through and the user has been upgraded.
* Store the Stripe checkout ID, to cross-reference the upgrade record on
Danbooru with the checkout record on Stripe.
This is the upgrade flow:
* When the user clicks the upgrade button on the upgrade page, we call
POST /user_upgrades and create a pending UserUpgrade.
* We redirect the user to the checkout page on Stripe.
* When the user completes checkout on Stripe, Stripe sends us a webhook
notification at POST /webhooks/receive.
* When we receive the webhook, we check the payment status, and if it's
paid we mark the UserUpgrade as complete and upgrade the user.
* After Stripe sees that we have successfully processed the webhook,
they redirect the user to the /user_upgrades/:id page, where we show
the user their upgrade receipt.
New rules for user promotions:
* Moderators can no longer promote other users to moderator level. Only
Admins can promote users to Mod level. Mods can only promote up to Builder level.
* Admins can no longer promote other users to Admin level. Only Owners
can promote users to Admin. Admins can only promote up to Mod level.
* Admins can no longer demote themselves or other admins.
These rules are being changed to account for the new Owner user level.
Also change it so that when a user upgrades their account, the promotion
is done by DanbooruBot. This means that the inviter and the mod action
will show DanbooruBot as the promoter instead of the user themselves.
Add a new Owner user level for the site owner. Highly sensitive
operations like manually changing the passwords of other users will be
restricted to the site owner.
The old flag limits were:
* 1 flag per day for regular members.
* 10 flags per day for Gold users.
* Unlimited flags for approvers.
The new flag limits are:
* 10 flags in the modqueue at once for regular users.
* Unlimited flags for approvers.
* Unlimited flags for users with a high enough flag success rate. If you
have at least 30 flags in the last 3 months, and you have at least a
70% flag success rate, then you get unlimited flags.
10 flags at once means you can have up to 10 flagged posts in the
modqueue at the same time. Because flags stay in the modqueue for 3
days, this means you can flag on average 10 posts every 3 days, or just
over 3 posts per day.
The old limit was one appeal per day. The new limit is based on your
upload limit. Each appeal costs 3 upload slots. If you have 15 upload
slots, then you can appeal up to 5 posts at once, but you won't be able
to appeal or upload more until your appeals are approved or rejected. If
you have unlimited uploads, then you have unlimited appeals.
* Show a banner if the user is restricted because they signed up from a
proxy or VPN.
* Add an option to resend the confirmation email if your account has an
unverified email address.
Refactor models so that we define attribute API permissions in policy
files instead of directly in models.
This is cleaner because a) permissions are better handled by policies
and b) which attributes are visible to the API is an API-level concern
that models shouldn't have to care about.
This fixes an issue with not being able to precompile CSS/JS assets
unless the database was up and running. This was a problem when building
Docker images because we don't have a database at build time. We needed
the database because `api_attributes` was a class-level macro in some
places, which meant it ran at boot time, but this triggered a database
call because api_attributes used database introspection to get the list
of allowed API attributes.
Partial fix for #4389.
* Fix invalid username searches returning all posts instead of no posts.
* Fix "user:A user:B" returning results for user:B instead of no results.
* Fix "approver:A approver:B" returning results for approver:B instead of no results.
* Add support for negated -commenter, -noter, -noteupdater, -upvote, -downvote metatags.
* Add support for "any" and "none" values for all username metatags,
including negated metatags that didn't support "any" or "none" before.
* Change noter:any and commenter:any to include posts with deleted notes
or comments. Note that commenter:<username> already included deleted
comments before. This is so that commenter:any has the same behavior
as commenter:<username>
Remove the ability to authenticate to the API with the `login` and
`password_hash` url parameters. This is a legacy authentication method
from Danbooru 1. How to actually generate the password_hash for this
method hasn't been fully documented for many years now. It required
taking the SHA1 hash of your password combined with an undocumented salt
value (i.e., password_hash = sha1("choujin-steiner--#{password}")).
This authentication method was also slow because it required checking
the password on every API call. Checking passwords is deliberately slow
because passwords are hashed with BCrypt. BCrypt takes about ~200ms per
request, so using this method effectively limited you to ~5 requests per
second in a single thread.
* 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.
Side effects:
* The data-current-user-is-voter <body> attribute has been removed.
* {{upvote:self}} no longer works. {{upvote:<name>}} should be used instead.
Fix discrepancy between index action and show action. The index
action allowed members to see name changes for undeleted users, but the
show action didn't.
* Move emails from users table to email_addresses table.
* Validate that addresses are formatted correctly and are unique across
users. Existing invalid emails are grandfathered in.
* Add is_verified flag (the address has been confirmed by the user).
* Add is_deliverable flag (an undeliverable address is an address that bounces).
* Normalize addresses to prevent registering multiple accounts with the
same email address (using tricks like Gmail's plus addressing).
The old password reset flow:
* User requests a password reset.
* Danbooru generates a password reset nonce.
* Danbooru emails user a password reset confirmation link.
* User follows link to password reset confirmation page.
* The link contains a nonce authenticating the user.
* User confirms password reset.
* Danbooru resets user's password to a random string.
* Danbooru emails user their new password in plaintext.
The new password reset flow:
* User requests a password reset.
* Danbooru emails user a password reset link.
* User follows link to password edit page.
* The link contains a signed_user_id param authenticating the user.
* User changes their own password.
