I get a fair number of "forgot password" emails where the person is
actually trying to log in with the wrong username. Normally, a login
system shouldn't display whether the username or password was the
incorrect part, but since it's already public information which
usernames exist on Tildes (simply by visiting /user/<username>), this
really isn't meaningfully hiding anything. It would only have any effect
on the most absolutely naive attackers. I think it's an acceptable
trade-off to help out people that are inadvertently trying to log in
with the wrong username instead.
Adding the info about the coronavirus views overrode this block, so we
can just show either (or both, which probably shouldn't happen, but
could) by doing this.
This is a prometheus exporter that allows checking IPv4 and IPv6
responses, among other things. This sets it up to make sure that the
site is responding over both IPv4 and IPv6, so that I can monitor and
set up an alert if either stops working.
This probably isn't particularly safe, but it's fine since I'm the only
one that can create or edit scheduled topics for now. The only available
variable so far is current_time_utc.
This is kind of hacky again (and shouldn't contain the coronavirus tag
over the long term), but makes sure that the "spoiler", "nsfw", and
"coronaviruses.covid19" tags are always offered as autocomplete options,
no matter how common they are in the topic's group.
This adds two links at the top of the home page that go to different
"views" - one includes only topics related to the coronavirus, while the
other filters out all coronavirus topics.
For the purposes of these views, a "coronavirus topic" is one that is
either in the ~health.coronavirus group, or has coronaviruses.covid19
tag.
This is very hacky and will only work on the main tildes.net site due to
hardcoded group name and tag. I'm okay with that.
This replaces the groups page with a new list style that doesn't include
the ability to subscribe/unsubscribe directly on the page, and also
shows approximate activity statistics (daily topics/comments) for each
group.
Let's try this again without the regex.
Clicking the X button in an autocomplete chip could inadvertently remove
the wrong tag (and cause a weird "merging" behavior) if another tag
ended with the same text as the one being removed. For example, if a
post had both "one.two" and "two" tags and you clicked the X button on
the "two".
Clicking the X button in an autocomplete chip could inadvertently remove
the wrong tag (and cause a weird "merging" behavior) if another tag
ended with the same text as the one being removed. For example, if a
post had both "one.two" and "two" tags and you clicked the X button on
the "two".
Just a couple relatively minor updates to the financial stuff:
* Removed the "is_approximate" column on the table and just added a more
general note about most of the amounts being approximate. It was more
annoying to worry about than meaningful.
* Some style/layout/wording tweaks to the donation goal to try to make
it a little more obvious that this is a long-term sustainability goal.
This is a major rework of the permissions system to enable various new
capabilities and clean up some of the oddities that were there.
Highlights:
- The concept of "admin" permission is removed. All permissions must be
granted individually.
- Permissions can now be granted on a group-specific level, such as
giving a user the ability to tag topics only in a specific group.
- Permissions can also be denied for a specific group (or all groups),
enabling uses like "tag topics in all groups except ~music".
- Removed the two cases where "all permissions" were granted: users on
themselves and the sender and recipient on messages. This was
dangerous, we should always grant permissions explicitly.
- Eliminated all the granular permissions for changing a user's settings
(which were all granted implicitly), and replaced with an overall
"change_settings" permission.
This is a bit of an odd commit: it adds a user_permissions table that
has capabilities that are not yet usable. Specifically, the table allows
setting DENY permissions as well as restricting permissions to an
individual group, but neither of those work yet. I want to make sure
that the existing, limited permission system seems to transfer over
properly before adding the additional complexity for those.
The Alembic data migrations for this commit is fairly ugly, but seem to
work okay.
Note that this will also prevent a title from ending with "...". I did a
search for all titles that ended in that, and none of them seemed
essential (and probably should have been removed), so I think this
should be fine.
This starts using webassets for the site-icons.css file inside the base
template so that a cache-busting "version" string is added after the
filename as a query variable (as was already being done with the other
CSS and JS files).
It also creates a new service that's triggered by a "path changed" event
on site-icons.css, which causes gunicorn to reload. This should mean
that whenever the site-icons.css file is updated by the cronjob that
generates it, gunicorn will automatically reload and update the
cache-busting string for the CSS file, causing users' browsers to update
to the newest version.
The new version of Salt ("3000") seems to have a number of bugs,
including not being able to handle "unless" checks, which the Tildes
states use frequently. Because of this, creating a new dev environment
currently doesn't work. This pins Salt to the previous stable version
for now.
Here's the relevant bug for "unless" specifically:
https://github.com/saltstack/salt/issues/56131
And the overall release notes:
https://docs.saltstack.com/en/latest/topics/releases/3000.html
If a user can edit a post, they don't need the ability to view the
markdown separately, so the button doesn't need to be shown in those
cases. I'm not sure if this should be a separate permission defined
inside the ACL or not.
Deimos
Shahzaib Sahibzada
dougmellon
Timo
Bauke