People are still continuing to try to abuse the donate page to check
stolen credit card numbers, and last night there was a massive burst of
attempts coming from many IPs, so the current rate-limiting wasn't able
to block most of it. Luckily Stripe blocked all of the charges this
time, but I can't keep risking another incident where Tildes is the
source of a bunch of fraudulent charges.
This adds a global rate-limit to the donate page that should never get
hit during normal usage. Hopefully this will be enough to keep the abuse
away from the page when it stops working for them relatively quickly.
Previously, rate limits had to apply to a particular user or a
particular IP address, or both. This adds support for global
rate-limits, where the limit will apply to everyone trying to perform
the action. This probably won't be used much overall, but might be
necessary for certain cases where something abusive is happening and it
can't be easily blocked by user or IP.
This is a bit ugly and would probably be better implemented by having a
separate class that inherits from RateLimitedAction or something
similar, but it will do the job.
This adds the backend pieces (no interface yet) to configure Lua scripts
that will be applied to topics and comments due to different events.
Initially, it only supports running a script when a new topic or comment
is posted. For example, here is a Lua script that would prepend a new
topic's title with "[Text] " or "[Link] " depending on its type, as well
as replace its tags with either "text" or "link":
function on_topic_post (topic)
if (topic.is_text_type) then
topic.title = "[Text] " .. topic.title
topic.tags = {"text"}
elseif (topic.is_link_type) then
topic.title = "[Link] " .. topic.title
topic.tags = {"link"}
end
end
There can be a global script as well as group-specific scripts, and the
scripts are sandboxed, with limited access to data as well as being
restricted to a subset of Lua's built-in functions. The Lua sandboxing
code comes from Splash (https://github.com/scrapinghub/splash). It will
need to be modified, but this commit keeps it unmodified so that future
changes can be more easily tracked by comparing to the original state of
the file.
The sandboxing also includes some restrictions on number of instructions
and memory usage, but this might be more effectively managed on the OS
level. More research will still need to be done on security and resource
restrictions before this feature can be safely opened to users.
This adds an "Edit title" choice in the actions dropdown for topics on
listing pages, instead of needing to go to the comments page.
Some pieces of this feel a little hack-ish (like needing to reduce the
bottom padding because of the usually-empty div that the title-editing
input gets put into), so I'll probably want to try and find a better
overall approach to this eventually, but it should do the job for now.
Just rearranges the module so the functions are in alphabetical order
(except web_server_reload, which has to be earlier so it can be called
as a post-task).
I think this is going to be a better way to name invoke tasks. The
previous naming where a verb was often first made it much harder for
anyone to figure out the name of a task that affects a certain thing
without always looking through the entire list.
For example, if someone is looking for a task that affects the web
server, it's much easier to find web-server-reload than
reload-web-server.
The changes were:
- check-code-style -> code-style-check
- reload-web-server -> web-server-reload
- renew-tls-certificate -> tls-certificate-renew
- type-checking -> type-check
- update-pip-requirements -> pip-requirements-update
I should have just done this all along, these have been way more trouble
than they're worth.
If the information is needed, it's always possible to just do a temp run
of pip-compile without --no-annotate or use a dedicated tool like
pipdeptree.
This is simpler than needing to know that --html-validation is the flag
to use to make sure that all tests are run, and can stay constant even
if we add other types of excluded-by-default tests in the future.
These were set up to redirect the original locations of the development
pages to their new locations inside the instructions folder, but can't
be used any more now that we're creating a development folder.
If a topic title has multiple sentences in it, it looks strange to strip
the trailing period off it, so we only want to do that automatically
when it's a single sentence.
Updates the Black code-formatter for Python to the latest version, and
applies it to some files that had formatting that the new version does
differently (splitting collections with trailing commas across lines).
This enables tab-completion for the new invoke tasks in the dev version.
So for example, you can type "invoke ty<Tab>" and it will complete to
"type-checking".
This way, instead of needing to know that you run "pytest" and knowing
tricks like "pytest -m ''" to run webtests and HTML validation, you can
now just run "invoke test", with more intuitive flags. This also reduces
the output in quiet mode even more.
After adding invoke tasks for some of the other tools/checks, I'll be
able to switch the git hooks to use these instead.
First invoke task: uses pip-compile to update the versions of all the
pip packages in requirements.txt and requirements-dev.txt. It also
post-processes the output file and removes any comments that have a "-r"
reference in them, since those currently cause Salt to break (and are
kind of redundant anyway).
Unfortunately, as part of writing this I discovered that invoke can't
handle type annotations in the definitions of its task functions, so I
had to exclude tasks.py from being checked by mypy. That makes me a
little nervous about whether invoke is still being maintained. Relevant
issue (over 4 years old): https://github.com/pyinvoke/invoke/issues/357
This isn't perfectly equivalent in some cases, but it's a barely
noticeable difference, and it's nice to not have all of these extra
custom properties like "--button-darkened-8-color" for an extremely
niche usage.
Now that we've switched to CSS custom properties, all the color rules
don't need to be repeated for each theme via a mixin, so the
_theme_base.scss could be split up with all its rules going into the
expected modules/locations along with all the other associated styles.
I think it's best to be specific that all of these are colors, otherwise
there could be some confusing usages (and potential collisions) with
ones like --border.
Sorry @Bauke (and probably some others), I know this will most likely
mess with any changes you've already made to override these properties,
but I wanted to do it eventually and it's only going to get worse the
longer I wait.
This should allow users with browsers that don't support CSS custom
properties to still have some minimal theme support. There will be
various issues with the themes (and that's fine), but it will at least
set the main colors for their chosen theme.
With the switch to CSS custom properties for the themes, old browsers
with no support are ending up with a transparent background on the
sidebar. This makes the site especially difficult to use on mobile.
I'm going to do something more extensive to allow browsers with no
support for custom properties to still get basic theming, but it's
dependent on a @supports query. For browsers that don't support that
query either, we need this line to give the sidebar a background.
This is probably just temporary, but I'm going to leave the donation
goal meter off the sidebar for now, so I don't want the confusing
section in the middle of the Financials page saying that the goal is $0
and so on.
This starts showing the Exemplary badge to all users again (but only the
author can see the count still).
It also changes the "priority" of the .is-comment-exemplary and
.is-comment-new classes so that the stripe will show the new color when
a comment is both new and exemplary.
We've been using pts_lbsearch on the text file for a few weeks now, and
it's working fine. Checks generally seem to take about 10 ms, and that's
totally fine for the relatively uncommon events of registrations and
password changes.
This removes everything related to the previous Redis-based method,
which means we no longer need the second Redis server or the ReBloom
module.
Deimos
Cassidy Dingenskirchen
Bauke