Require the user to re-enter their password before they can view,
create, update, or delete their API keys.
This works by tracking the timestamp of the user's last password
re-entry in a `last_authenticated_at` session cookie, and redirecting
the user to a password confirmation page if they haven't re-entered
their password in the last hour.
This is modeled after Github's Sudo mode.
Track when an API key was last used, which IP address last used it, and
how many times it's been used overall.
This is so you can tell when an API key was last used, so you know if
the key is safe to delete, and so you can tell if an unrecognized IP has
used your key.
Add the ability to restrict API keys so that they can only be used with
certain IP addresses or certain API endpoints.
Restricting your key is useful to limit damage in case it gets leaked or
stolen. For example, if your key is on a remote server and it gets
hacked, or if you accidentally check-in your key to Github.
Restricting your key's API permissions is useful if a third-party app or
script wants your key, but you don't want to give full access to your
account.
If you're an app or userscript developer, and your app needs an API key
from the user, you should only request a key with the minimum
permissions needed by your app.
If you have a privileged account, and you have scripts running under
your account, you are highly encouraged to restrict your key to limit
damage in case your key gets leaked or stolen.
* Add an explanation of what an API key is and how to use it.
* Make it possible for the site owner to view all API keys.
* Remove the requirement to re-enter your password before you can view
your API key (to be reworked).
* Move the API key controller from maintenance/user/api_keys_controller.rb
to a top level controller.
Regression caused by the switch from the mobile API to the Ajax API. In
the Ajax API, commentaries have /jump.php?<url> links that we have to strip out.
Fix the Pixiv API no longer working by rewriting the Pixiv strategy to
use the Ajax API instead of the mobile API.
Before we could authenticate in the mobile API by using the OAuth 2.0
grant_type=password authentication flow. This no longer works. Now it
requires logging in through a HTML page, which is protected by Google
reCaptcha. This makes using the mobile API infeasible.
Instead we switch to the Ajax API, which only needs a PHPSESSID to
authenticate. This can be obtained by logging in manually and using the
devtools to extract the cookie.
This also temporarily removes support for Pixiv novels. This should be
moved to a separate source strategy.
Pixiv API client is currently broken. Temporarily disable Pixiv source
strategy so direct image Pixiv uploads can still go through. The
posts.pixiv_id field will need to be backfilled later.
Some of these pages were accidentally crawled because rules like `Allow:
/artist` allowed `/artist_versions` to be crawled (Allow rules are
prefix matches).
Regression caused by the upgrade to Webpacker 6.0 in 90cd3293e. This
caused various Javascript errors in old versions of Chrome, which
somehow resulted in the keyboard shortcut for visiting the next page
being triggered when you pressed any key.
Specifically, the mobx library (used by the TagCounter component) called
`Object.entries`, which isn't available in Chrome 49, and for some
unknown reason this triggered the buggy shortcut behavior.
`Object.entries` is supposed to be automatically polyfilled by Babel to
support old browsers, but something changed in Webpacker 6 that broke
this and I couldn't get it working again. The probable cause is that
Webpacker 6 no longer transpiles code inside ./node_modules by default,
which means that any libraries we use that use new Javascript features
won't get transpiled down to support old browsers, but even after fixing
that it still didn't work. The workaround is to just drop mobx and
preact entirely to avoid the issue.
6d867de20 caused an exception in the ApiKeysController, which calls
respond_with with two arguments: `respond_with(CurrentUser.user, @api_key)`.
`options[0]` referred to the second argument, which was incorrect.
On the post show page, define the next page / previous page keyboard
shortcuts in html using data-shortcut attributes instead of in
Javascript. This is consistent with how these shortcuts are defined on
the post index page.
* Factor out the post navbar into a component. The post navbar is the
part of the post containing the current search, the list of pools, and
the list of favgroups, along with next/prev navigation links.
* Change navbar markup: remove various unused CSS classes/IDs, change
pools to use same markup as favgroups, replace nested <div>'s with
flat <ul>/<li> list.
* Use CSS to truncate long searches/pool names/favgroup names if they're
too wide for the screen (especially on mobile).
Like 9efb374ae, allow users to toggle between upvoting and downvoting a
post without raising an error or having to manually remove the vote
first. If you upvote a post, then downvote it, the upvote is
automatically removed and replaced by the downvote.
Other changes:
* Tagging a post with `upvote:self` or `downvote:self` is now silently
ignored when the user doesn't have permission to vote, instead of
raising an error.
* Undoing a vote that doesn't exist now does nothing instead of
returning an error. This can happen if you open the same post in two
tabs, undo the vote in tab 1, then try to undo the vote again in tab 2.
Changes to the /post_votes API:
* `POST /post_votes` and `DELETE /post_votes` now return a post vote
instead of a post.
* The `score` param in `POST /post_votes` is now 1 or -1, not `up` or
`down`.
Change post votes to work the same way as comment votes:
* Make the upvote arrow blue if you've upvoted the post, or grey if you
haven't. Likewise for the downvote arrow.
* Make it so you can click the upvote or downvote arrows to undo the vote.
* Don't show any notices when you vote on a post.
Also fix it so that votes work the same way on the posts page, the
comments page, and in the modqueue. Before it wasn't possible to undo
votes on the comments page or in the modqueue.
When an anonymous users tries to go to the new upload page, direct them
to the login page instead of showing them an "Access Denied" error.
Fixes complaints from SEO tools about linking to pages that return a 403
error.
Broken in 49bc2364 by the use of @extend.
Here's what happened. There are two CSS rules that both apply to pool links:
* a:link { color: var(--link-color); }
* .pool-category-series a { color: var(--series-pool-color); }
These rules have equal specificity (0-1-1). This means the rule that is
defined last takes priority. This means the order in which CSS files are
included matters. 49bc2364 used the @extend directive in a rule for
popup menus, which required an @import, which changed the order of the
CSS files, which made the a:link rule suddenly take priority over the
series pool rule.
The proper fix would be to use Sass's new @use directive instead of
@import, but that requires the latest version of Sass, which requires
the latest version of Webpacker, which we can't upgrade to yet because
of breaking changes.
The real moral of the story is: our CSS is very fragile because of
specificity rules. It's very important that rules are defined in a
certain order, otherwise our CSS will break.
* https://sass-lang.com/documentation/at-rules/use
* https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity
