* Add notifications when a reblogged status has been updated
* Change wording to say "edit" instead of "update" and add missing controls
* Replace previous update notifications with the most up-to-date one
Conflicts:
- `app/controllers/api/v1/statuses_controller.rb`:
Upstream moved things around in a place where glitch-soc had support for
an extra parameter (`content_type`).
Follow upstream but reintroduce `content_type`.
* Add editing for published statuses
* Fix change of multiple-choice boolean in poll not resetting votes
* Remove the ability to update existing media attachments for now
Conflicts:
- `app/views/settings/preferences/appearance/show.html.haml`:
Upstream renamed some helper functions that were used in a part of the
settings page which glitch-soc slightly changed the layout of.
Ported the change.
* Fix Sidekiq warnings about JSON serialization
This occurs on every symbol argument we pass, and every symbol key in hashes,
because Sidekiq expects strings instead.
See https://github.com/mperham/sidekiq/pull/5071
We do not need to change how workers parse their arguments because this has
not changed and we were already converting to symbols adequately or using
`with_indifferent_access`.
* Set Sidekiq to raise on unsafe arguments in test mode
In order to more easily catch issues that would produce warnings in production
code.
Fixes#1649
This requires setting `HCAPTCHA_SECRET_KEY` and `HCAPTCHA_SITE_KEY`, then
enabling the admin setting at
`/admin/settings/edit#form_admin_settings_captcha_enabled`
Subsequently, a hCaptcha widget will be displayed on `/about` and
`/auth/sign_up` unless:
- the user is already signed-up already
- the user has used an invite link
- the user has already solved the captcha (and registration failed for another
reason)
The Content-Security-Policy headers are altered automatically to allow the
third-party hCaptcha scripts on `/about` and `/auth/sign_up` following the same
rules as above.
* Fix error-prone SQL queries in Account search
While this code seems to not present an actual vulnerability, one could
easily be introduced by mistake due to how the query is built.
This PR parameterises the `to_tsquery` input to make the query more robust.
* Harden code for Status#tagged_with_all and Status#tagged_with_none
Those two scopes aren't used in a way that could be vulnerable to an SQL
injection, but keeping them unchanged might be a hazard.
* Remove unneeded spaces surrounding tsquery term
* Please CodeClimate
* Move advanced_search_for SQL template to its own function
This avoids one level of indentation while making clearer that the SQL template
isn't build from all the dynamic parameters of advanced_search_for.
* Add tests covering tagged_with, tagged_with_all and tagged_with_none
* Rewrite tagged_with_none to avoid multiple joins and make it more robust
* Remove obsolete brakeman warnings
* Revert "Remove unneeded spaces surrounding tsquery term"
The two queries are not strictly equivalent.
This reverts commit 86f16c537e06c6ba4a8b250f25dcce9f049023ff.
Conflicts:
- `app/lib/activitypub/activity/create.rb`:
Upstream refactored how `Create` activities are handled and how values are
extracted from `Create`d objects. This conflicted with how glitch-soc
supported the `directMessage` flag to explicitly distinguish between
limited and direct messages.
Ported glitch-soc's changes to latest upstream changes.
- `app/services/fan_out_on_write_service.rb`:
Upstream largely refactored that file and changed some of the logic.
This conflicted with glitch-soc's handling of the direct timeline and
the options to allow replies and boosts in public feeds.
Ported those glitch-soc changes on top of latest upstream changes.
- `app/services/process_mentions_service.rb`:
Upstream refactored to move mention-related ActivityPub deliveries to
`ActivityPub::DeliveryWorker`, while glitch-soc contained an extra check
to not send local-only toots to remote mentioned users.
Took upstream's version, as the check is not needed anymore, since it is
performed at the `ActivityPub::DeliveryWorker` call site already.
- `app/workers/feed_insert_worker.rb`:
Upstream added support for `update` toot events, while glitch-soc had
support for an extra timeline support, `direct`.
Ported upstream changes and extended them to the `direct` timeline.
Additional changes:
- `app/lib/activitypub/parser/status_parser.rb`:
Added code to handle the `directMessage` flag and take it into account
to compute visibility.
- `app/lib/feed_manager.rb`:
Extended upstream's support of `update` toot events to glitch-soc's
`direct` timeline.
* Add support for editing for published statuses
* Fix references to stripped-out code
* Various fixes and improvements
* Further fixes and improvements
* Fix updates being potentially sent to unauthorized recipients
* Various fixes and improvements
* Fix wrong words in test
* Fix notifying accounts that were tagged but were not in the audience
* Fix mistake
Conflicts:
- `README.md`:
We have completely different contents. Kept our version.
- `package.json`:
Not a real conflict, just an upstream dependency udpated
textually too close to a glitch-soc-only dependency.
Updated dependencies like upstream.
- `streaming/index.js`:
Conflict due to code style changes on parts that were
modified in glitch-soc to handle local-only toots.
Changed style according to upstream.
* Add admin option to remove canonical email blocks from a deleted account
* Add tootctl canonical_email_blocks to inspect and remove canonical email blocks
Conflicts:
- `app/views/admin/pending_accounts/index.html.haml`:
Removed upstream, while it had glitch-soc-specific changes to accomodate
for glitch-soc's theming system.
Removed the file.
Additional changes:
- `app/views/admin/accounts/index.html.haml':
Accomodate for glitch-soc's theming system.
Conflicts:
- `.env.production.sample`:
Copied upstream changes.
- `app/controllers/settings/identity_proofs_controller.rb`:
Minor conflict due to glitch-soc's extra “enable_keybase” setting.
Upstream removed keybase support altogether, so did the same.
- `app/controllers/well_known/keybase_proof_config_controller.rb`:
Minor conflict due to glitch-soc's extra “enable_keybase” setting.
Upstream removed keybase support altogether, so did the same.
- `lib/mastodon/statuses_cli.rb`:
Minor conflict due to an optimization that wasn't shared between
the two versions. Copied upstream's version.
Conflicts:
- `app/views/admin/tags/index.html.haml`:
Removed upstream while it had changes in glitch-soc to accomodate for the
theming system.
Additional changes to accomodate for the theming system:
- `app/views/admin/trends/links/preview_card_providers/index.html.haml`
- `app/views/admin/trends/links/index.html.haml`
- `app/views/admin/trends/tags/index.html.haml`
- `app/views/admin/tags/show.html.haml`
* Add trending links
* Add overriding specific links trendability
* Add link type to preview cards and only trend articles
Change trends review notifications from being sent every 5 minutes to being sent every 2 hours
Change threshold from 5 unique accounts to 15 unique accounts
* Fix tests
* Fix error when suspending user with an already-existing canonical email block
Fixes#17033
While attempting to create a `CanonicalEmailBlock` with an existing hash would
raise an `ActiveRecord::RecordNotUnique` error, this being done within a
transaction would cancel the whole transaction. For this reason, checking for
uniqueness in Rails would query the database within the transaction and avoid
invalidating the whole transaction for this reason.
A race condition is still possible, where multiple accounts sharing a canonical
email would be blocked in concurrent transactions, in which only one would
succeed, but that is way less likely to happen that the current issue, and can
always be retried after the first failure, unlike the current situation.
* Add tests
Up until now, we have used Devise's Rememberable mechanism to re-log users
after the end of their browser sessions. This mechanism relies on a signed
cookie containing a token. That token was stored on the user's record,
meaning it was shared across all logged in browsers, meaning truly revoking
a browser's ability to auto-log-in involves revoking the token itself, and
revoking access from *all* logged-in browsers.
We had a session mechanism that dynamically checks whether a user's session
has been disabled, and would log out the user if so. However, this would only
clear a session being actively used, and a new one could be respawned with
the `remember_user_token` cookie.
In practice, this caused two issues:
- sessions could be revived after being closed from /auth/edit (security issue)
- auto-log-in would be disabled for *all* browsers after logging out from one
of them
This PR removes the `remember_token` mechanism and treats the `_session_id`
cookie/token as a browser-specific `remember_token`, fixing both issues.
* Add followed_by? to account_interactions
* Add RemoveFromFollowersService
* Fix AccountBatch to use RemoveFromFollowersService
* Add remove from followers API
Conflicts:
- `app/controllers/admin/dashboard_controller.rb`:
Upstream completely redesigned the admin dashboard.
glitch-soc tracked extra features, but that list is
gone.
Followed upstram.
- `app/views/admin/dashboard/index.html.haml`
Upstream completely redesigned the admin dashboard.
glitch-soc tracked extra features, but that list is
gone.
Followed upstram.
Currently, there is no way for an admin to delete an account record. However,
should that happen in the future, or should an admin mistype an account id,
`/admin/action_logs?target_account_id=<non-existent-account-id>` currently
returns a 404 instead of an empty list.
With this commit, the aforementioned page returns a correct list instead
(potentially non-empty if the account has been manually deleted)
Conflicts:
- `package.json`:
Not really a conflict, just a glitch-soc-only dependency textually too close
to an updated upstream one.
- `yarn.lock`:
Not really a conflict, just a glitch-soc-only dependency textually too close
to an updated upstream one.
* Fix media attachment size validation not correctly accounting for file type
Fixes a regression introduced in #16724 caused by the fact that kt-paperclip
now correctly runs validations before processing, meaning that file size
verification could not rely on our before_post_processing hook.
Moved the `before_post_processing` hooks to `before_validate` to make sure
the media attachment type is set correctly before the file gets validated.
* Add tests
Conflicts:
- `app/models/custom_emoji.rb`:
Slight refactor upstream, next to a line that was different in glitch-soc
because of our local configurable limits on custom emoji size.
Ported upstream changes.
- `yarn.lock`:
Not really a conflict, upstream dependency textually too close to a
glitch-soc-only dependency.
Updated upstream dependency as upstream.
* Switch from unmaintained paperclip to kt-paperclip
* Drop some compatibility monkey-patches not required by kt-paperclip
* Drop media spoof check monkey-patching
It's broken with kt-paperclip and hopefully it won't be needed anymore
* Fix regression introduced by paperclip 6.1.0
* Do not rely on pathname to call FastImage
* Add test for ogg vorbis file with cover art
* Add audio/vorbis to the accepted content-types
This seems erroneous as this would be the content-type for a vorbis stream
without an ogg container, but that's what the `marcel` gem outputs, so…
* Restore missing for_as_default method
* Refactor Attachmentable concern and delay Paperclip's content-type spoof check
Check for content-type spoofing *after* setting the extension ourselves, this
fixes a regression with kt-paperclip's validations being more strict than
paperclip 6.0.0 and rejecting some Pleroma uploads because of unknown
extensions.
* Please CodeClimate
* Add audio/vorbis to the unreliable set
It doesn't correspond to a file format and thus has no extension associated.
* Stop setting a shortcode to newly-created media attachments
The WebUI has stopped using the “short media URL” in ages. This isn't used
anywhere except for mail notifications.
Deprecating it would allow us to eventually get rid of at least a database
column and corruption-prone index, as well as a controller.
* Fix tests
* Fix followers synchronization mechanism not working when URI has empty path
To my knowledge, there is no current implementation on the fediverse
that can use bare domains (e.g., actor is at https://example.org instead of
something like https://example.org/actor) that also plans to support the
followers synchronization mechanism. However, Mastodon's current implementation
would exclude such accounts from followers list.
Also adds tests and rename them to reflect the proper method names.
* Move url prefix regexp to its own constant
Conflicts:
- `Gemfile.lock`:
Not a real conflict, upstream-updated dependency (redis) textually too
close to glitch-soc-only dependecy.
Updated redis gem like upstream did.
* Add account statuses cleanup policy model
* Record last inspected toot to delete to speed up successive calls to statuses_to_delete
* Add service to cleanup a given account's statuses within a budget
* Add worker to go through account policies and delete old toots
* Fix last inspected status id logic
All existing statuses older or equal to last inspected status id must be
kept by the current policy. This is an invariant that must be kept so that
resuming deletion from the last inspected status remains sound.
* Add tests
* Refactor scheduler and add tests
* Add user interface
* Add support for discriminating based on boosts/favs
* Add UI support for min_reblogs and min_favs, rework UI
* Address first round of review comments
* Replace Snowflake#id_at_start with with_random parameter
* Add tests
* Add tests for StatusesCleanupController
* Rework settings page
* Adjust load-avoiding mechanisms
* Please CodeClimate
* Add account_notes relationship
* Add tests
* Fix owned account notes not being deleted when an account is deleted
* Add post-migration to clean up orphaned account notes
Conflicts:
- `app/serializers/rest/instance_serializer.rb`:
Upstream changed the fields returned by /api/v1/instance by adding a
`configuration` field holding a lot of useful information making our
`max_toot_chars` and `poll_limits` fields obsolete.
Keeping those around for now for compatibility.
- `app/validators/status_length_validator.rb`:
No real conflict, just URL_PLACEHOLDER_CHARS introduced too close to
MAX_CHARS which is defined differently in glitch-soc.
Ported upstream changes.
Conflicts:
- `app/helpers/accounts_helper.rb`:
Conflict due to upstream changing how followers count is displayed while we
have an option to hide followers count.
Ported upstream change.
- `app/views/accounts/_header.html.haml`:
Conflict due to upstream changing how followers count is displayed while we
have an option to hide followers count.
Ported upstream change.
- `app/views/directories/index.html.haml`:
Conflict due to upstream changing how followers count is displayed while we
have an option to hide followers count.
Ported upstream change.
3.4.1 dropped account_stats.lock_version, but in a way breaking the usual
upgrade path by requiring services to be reloaded after the post-migrations.
Indeed, `self.locking_column = nil` was not enough for Rails to ignore the
`lock_version` column when preparing statements on application load, resulting
in some ActiveRecord queries (typically those involving
`includes(:account_stat)`) erroring out with:
ActiveRecord::StatementInvalid (PG::UndefinedColumn: ERROR: column account_stats.lock_version does not exist
* Fix account deletion sometimes failing because of optimistic locks
In some rare occasions[1], deleting accounts would fail with a
`StaleObjectError` exception.
Indeed, account deletion manually sets the `AccountStat` values without
handling cases where the optimistic locking on `AccountStat` would fail.
To my knowledge, with the rewrite of account counters in #15913, the
`DeleteAccountService` is now the only place that changes the counters in
a way that is not atomic.
Since in this specific case, we do not care about the previous values of the
account counters, it appears we don't need locking at all for this table
anymore.
[1]: https://discourse.joinmastodon.org/t/account-cant-be-deleted/3602
* Bump MAX_SUPPORTED_VERSION in maintenance script
