The strict-dynamic CSP directive is supported in all our target browsers, and makes for a much simpler configuration. Instead of allowlisting paths, we use a per-request nonce to authorize `<script>` tags, and then those scripts are allowed to load additional scripts (or add additional inline scripts) without restriction.
This becomes especially useful when admins want to add external scripts like Google Tag Manager, or advertising scripts, which then go on to load a ton of other scripts.
All script tags introduced via themes will automatically have the nonce attribute applied, so it should be zero-effort for theme developers. Plugins *may* need some changes if they are inserting their own script tags.
This commit introduces a strict-dynamic-based CSP behind an experimental `content_security_policy_strict_dynamic` site setting.
This commit is the first of a series of commits that will allow themes to define complex settings types by declaring a schema of the setting structure that Discourse core will use to build a UI for the setting automatically. We implement the navigation logic and support for multiple levels of nesting in this commit and we'll continue building this new system gradually in future commits.
Internal topic: t/116870.
Followup to 978d52841a
It's complicated...we have multiple "anonymous" user concepts
in core, and even two classes called the exact same thing --
AnonymousUser.
The first case is Guardian::AnonymousUser, which is used for
people who are browsing the forum without being authenticated.
The second case is the model AnonymousUser, which is used when
a user is liking or posting anonymously via allow_anonymous_likes
or allow_anonymous_posting site settings.
We will untangle this naming nightmare later on...but for the
time being, only authenticated users who are pretending to be
anonymous should be able to like posts if allow_anonymous_likes
is on.
Why this change?
This is a first pass at adding an objects validator which main's job is
to validate an object against a defined schema which we will support. In
this pass, we are simply validating that properties that has been marked
as required are present in the object.
Reactions needs this to be able to filter out likes received
actions, where there is also an associated reaction, since
now most reactions also count as a like.
Why this change?
This is a follow up to c30aeafd9d. The
commit was calling `BlockRequestsMiddleware.allow_requests!` only before
`type: :system` tests but non system type tests could be running as well
and needs the `BlockRequestsMiddleware.allow_requests!` middleware to be
disabled too.
* FEATURE: shift+j and shift+k will scroll entire posts
When scrolling through topics with very long posts we would like to use
`shift+j` and `shift+k` to quickly move between posts.
This allows users to bypass the scroll within post behavior when zooming
through topics with keyboard shortcuts
This overloads the behavior of shift+k and j which can be used to scroll
through sections (new/latest/etc...)
* remove useless tests
These tests are testing nothing, no point carrying them around
When making sensitive changes to an account (adding 2FA or passkeys), we
require users to confirm their password. This is to prevent an attacker
from adding 2FA to an account they have access to.
However, on newly created accounts, we should not require this, it's an
extra step and it doesn't provide extra security (since the account was
just created). This commit makes it so that we don't require session
confirmation for accounts created less than 5 minutes ago.
The `-ping` option significantly speeds up the ImageMagick `identify` command per our testing and the [documentation](https://imagemagick.org/script/command-line-options.php#ping):
> -ping
Efficiently determine these image characteristics: image number, the file name, the width and height of the image, whether the image is colormapped or not, the number of colors in the image, the number of bytes in the image, the format of the image (JPEG, PNM, etc.). Use +ping to ensure accurate image properties.
We already pass the `-ping` option in other places where the `identify` command is used, so it makes sense to use the option everywhere.
Internal topic: t/121431.
Why this change?
We have been debugging flaky system tests and noticed in https://github.com/discourse/discourse/actions/runs/7911902047/job/21596791343?pr=25690
that ActiveRecord connection checkout timeouts are encountered because
the Capybara server thread is processing requests even after
`Capybara.reset_session!` and ActiveRecord's `teardown_fixtures` have already been call.
The theory here is that an inflight request can still hit the Capybara
server even after `Capybara.reset_session!` has been called and end up
eating up an ActiveRecord connection for too long and also messing with
the database outside of a transaction.
What does this change do?
This change adds a `BlockRequestsMiddleware` middleware in the test
environment which is enabled to reject all incoming requests at the end
of each system test and before `Capybara.reset_session!` is called. At
the start of each RSpec test, the middleware is disabled again.
Why this change?
The tests are consistently flaky and failing with the following error:
```
CapybaraTimeoutExtension::CapybaraTimedOut:
This spec passed, but capybara waited for the full wait duration (10s) at least once. This will slow down the test suite. Beware of negating the result of selenium's RSpec matchers.
```
Why this change?
On CI, we have been seeing flaky system tests because ActiveRecord is
unable to checkout a connection. This patch is meant to help us debug
which thread is not returning the connection to the queue.
This would allow a theme component (or an API call) to reset the bump
date of a topic to a given post's created_at date.
I picked `post_id` as the parameter here because it provides a bit of
extra protection against accidentally resetting the bump date to a date
that doesn't make sense.
I attempted to add a test for related topics, as they are untested. This was a massive challenge as related topics are only rendered after
- a user has stopped typing
- there is a timeout after typing
Between system tests, acceptance tests, and stubbing requests, this was difficult. So here is the pr san test.
Why this change?
Backfilling can take a long time on a site with many users. As a
result, the `DistriburedMutex` will warn in the logs when the block takes
more than 60 seconds to complete. We can increase the lock validity but
the method is currently only called from a job which has a
`cluster_concurrency` set to `1`. Therefore, it is actually not
necessary for us to hold a `DistributedMutex` here.
What does this change do?
1. Removes the distributed mutex and adds a comment about the risk of
calling the `SidebarSiteSettingsBackfiller#backfill!` method.a
2. Delete old sidebar category section links in batches for all users
to avoid a single long running query.
In certain cases, chat channels may have empty slugs, it happens when:
1. The `slug_generation_method` setting is set to `None`
2. `slug_generation_method` is set to `ASCII` and a channel with
a Unicode name and an empty slug is created (in this case, the code
that creates channels tries to generate a slug and fallbacks to an empty slug)
At the moment, we have a unique index on the `chat_channels.slug` column
which leads to errors when creating several channels with empty slugs
(Discourse is able to create one such channel, but when trying to create
the second one fails because of the unique constraint). This PR fixes that
by adding a `where` condition to the index. Slugs still have to be unique,
but now many channels may have empty slugs.
This fix is similar to the one we made to the category slugs – 7ba914f1e1.
When we launched the new illegal flag type, there were a few problems with the translations:
The translation for the message in the e-mail was missing and in the review queue, the message read: "Is this it's illegal?"
In this PR the missing translation key has been added. For the review queue there was a coupling of the name rendering to whether the flag is of "custom" type, but this is also used for deciding whether we render the textbox for additional details. I think these two things should not be coupled together. For now I have instead hard-coded the existing "custom" types when formatting the name. We can potentially improve this later.
