Borrows code from the upstream which has been working in production
reliably for ~months. Also, most of it was literally copy-pasted,
and the casted ID values aren't used later in the route functions.
While checking for the key in the Request object is highly inelegant,
it is consistent with how we determine elsewhere if rendered comments
are being shown as a context.
PR #374 removed `@auth_required` from a number of routes and changed
those which used their `v` parameters to `v=None` and removed the `v`
parameter from those which didn't internally use it. 1841134b47
PR #392 re-added `@auth_desired` to those routes to ensure the
templates rendered with awareness of the current logged-in user
(matters for search, header bar, etc). 9f042c1aeb
However, 500 errors occurred on /random_post, /random_user, /id/<uid>,
and /u/<username>. Those were the four which had their `v` parameter
removed entirely. This has been re-added, which fixes the bug.
The way to understand auth_required vs auth_desired is that they are
nearly identical, with the sole difference than auth_required
checks if v is None and aborts with 401 if so. This means that
auth_desired routes must handle the v=None case. They are the same in
that they always try to give a `v` kwarg to the decorated function,
which was the root cause of those four routes erroring.
Recommended style: the vast majority of routes which return a rendered
template should be auth_desired, because the top-level templates often
draw extensively from `v` state even when the route handler does not.
When a route is either auth_desired or auth_required, it should have a
`v` parameter, which we typically give as the first positional
parameter.
This commit adds the @auth_desired decorator to
routes that previous had the @auth_required decorator,
but had it removed in #374. This should cause
the user to remain logged in on these routes.
The `linefeeds_regex` doubles every newline character. However, when
that happens, it turns tight numbered lists into loose numbered lists.
Context: https://stackoverflow.com/a/43505265
Going with solution proposed by @TLSM since the forum already has
production traffic.
Fixes#321. Due to the extremely large quantity of comments on a
typical Motte post, 'hot' sorting logic underflowed an intermediate
value. Roughly:
|(-1 000 000) * (103 [votes] + 1 + 2723 [comments] / 1)| > 2^31
We resolve this by reducing the coefficient from 1e6 to 1e5, which
reduces precision of intermediate calculations somewhat, and by
dividing #comments by 10 rather than 1, which better matches Motte
user behavior regardless: Users comment much more often than vote.
This buys us two orders of magnitude more headroom before out-of-
bounds. Shouldn't be an issue until the CW thread reaches ~200k
comments.
