* Don't allow URLs that contain non-normalized paths to be verified
This stops things like https://example.com/otheruser/../realuser where
"/otheruser" appears to be the verified URL, but the actual URL being
verified is "/realuser" due to the "/../".
Also fix a test to use 'https', so it is testing the right thing, now
that since #20304 https is required.
* missing do
* Test blank account field verifiability
This change tests the need for #20428, which ensures that we guard against a situation in which `at_xpath` returns `nil`.
* Test verifiability of blank fields for remote account profiles
This adds a counterpart test for remote account profiles' fields' verifiability when those fields are blank. I previously added the same test for local accounts.
- Change verification to happen in `default` queue
- Change verification worker to only be queued if there's something to do
- Add `link` tags from metadata fields to page header of profiles
Found via `codespell -q 3 -S ./yarn.lock,./CHANGELOG.md,./AUTHORS.md,./config/locales,./app/javascript/mastodon/locales -L ba,followings,keypair,medias,pattens,pixelx,rememberable,ro,te`
In the absence of an opt-in to multiple specific languages in the
preferences, it makes more sense to filter by the user's presumed
language only (interface language or `lang` override)
* Add model for custom filter keywords
* Use CustomFilterKeyword internally
Does not change the API
* Fix /filters/edit and /filters/new
* Add migration tests
* Remove whole_word column from custom_filters (covered by custom_filter_keywords)
* Redesign /filters
Instead of a list, present a card that displays more information and handles
multiple keywords per filter.
* Redesign /filters/new and /filters/edit to add and remove keywords
This adds a new gem dependency: cocoon, as well as a npm dependency:
cocoon-js-vanilla. Those are used to easily populate and remove form fields
from the user interface when manipulating multiple keyword filters at once.
* Add /api/v2/filters to edit filter with multiple keywords
Entities:
- `Filter`: `id`, `title`, `filter_action` (either `hide` or `warn`), `context`
`keywords`
- `FilterKeyword`: `id`, `keyword`, `whole_word`
API endpoits:
- `GET /api/v2/filters` to list filters (including keywords)
- `POST /api/v2/filters` to create a new filter
`keywords_attributes` can also be passed to create keywords in one request
- `GET /api/v2/filters/:id` to read a particular filter
- `PUT /api/v2/filters/:id` to update a new filter
`keywords_attributes` can also be passed to edit, delete or add keywords in
one request
- `DELETE /api/v2/filters/:id` to delete a particular filter
- `GET /api/v2/filters/:id/keywords` to list keywords for a filter
- `POST /api/v2/filters/:filter_id/keywords/:id` to add a new keyword to a
filter
- `GET /api/v2/filter_keywords/:id` to read a particular keyword
- `PUT /api/v2/filter_keywords/:id` to edit a particular keyword
- `DELETE /api/v2/filter_keywords/:id` to delete a particular keyword
* Change from `irreversible` boolean to `action` enum
* Remove irrelevent `irreversible_must_be_within_context` check
* Fix /filters/new and /filters/edit with update for filter_action
* Fix Rubocop/Codeclimate complaining about task names
* Refactor FeedManager#phrase_filtered?
This moves regexp building and filter caching to the `CustomFilter` class.
This does not change the functional behavior yet, but this changes how the
cache is built, doing per-custom_filter regexps so that filters can be matched
independently, while still offering caching.
* Perform server-side filtering and output result in REST API
* Fix numerous filters_changed events being sent when editing multiple keywords at once
* Add some tests
* Use the new API in the WebUI
- use client-side logic for filters we have fetched rules for.
This is so that filter changes can be retroactively applied without
reloading the UI.
- use server-side logic for filters we haven't fetched rules for yet
(e.g. network error, or initial timeline loading)
* Minor optimizations and refactoring
* Perform server-side filtering on the streaming server
* Change the wording of filter action labels
* Fix issues pointed out by linter
* Change design of “Show anyway” link in accordence to review comments
* Drop “irreversible” filtering behavior
* Move /api/v2/filter_keywords to /api/v1/filters/keywords
* Rename `filter_results` attribute to `filtered`
* Rename REST::LegacyFilterSerializer to REST::V1::FilterSerializer
* Fix systemChannelId value in streaming server
* Simplify code by removing client-side filtering code
The simplifcation comes at a cost though: filters aren't retroactively
applied anymore.
* Change unapproved and unconfirmed account to not be accessible in the REST API
* Change Account#searchable? to reject unconfirmed and unapproved users
* Disable search for unapproved and unconfirmed users in Account.search_for
* Disable search for unapproved and unconfirmed users in Account.advanced_search_for
* Remove unconfirmed and unapproved accounts from Account.searchable scope
* Prevent mentions to unapproved/unconfirmed accounts
* Fix some old tests for Account.advanced_search_for
* Add some Account.advanced_search_for tests for existing behaviors
* Add some tests for Account.search_for
* Add Account.advanced_search_for tests unconfirmed and unapproved accounts
* Add Account.searchable tests
* Fix Account.without_unapproved scope potentially messing with previously-applied scopes
* Allow lookup of unconfirmed/unapproved accounts through /api/v1/accounts/lookup
This is so that the API can still be used to check whether an username is free
to use.
* Fix edits with no actual changes being allowed locally
* Fix edits with no actual changes being allowed through ActivityPub
* Fix false positive changes caused by description processing in model
* Fix not recording poll expiration update
* Fix test
* Revert changes to ProcessStatusUpdateService
* Various fixes and improvements
* Fix code style issues
* Various changes and improvements
* Add guard clause
* Change how changes to media attachments are stored for edits
Fix not being able to re-order media attachments
* Fix not broadcasting updates when polls/media is changed through ActivityPub
* Various fixes and improvements
* Update app/models/report.rb
Co-authored-by: Claire <claire.github-309c@sitedethib.com>
* Add tracking of media attachment description changes
* Change poll in status edit to have a structure closer to the real one
Co-authored-by: Claire <claire.github-309c@sitedethib.com>
* Fix performance of account timelines
* Various fixes and improvements
* Fix duplicate results being returned
Co-authored-by: Claire <claire.github-309c@sitedethib.com>
* Fix grouping for pinned statuses scope
Co-authored-by: Claire <claire.github-309c@sitedethib.com>
* Add trending statuses
* Fix dangling items with stale scores in localized sets
* Various fixes and improvements
- Change approve_all/reject_all to approve_accounts/reject_accounts
- Change Trends::Query methods to not mutate the original query
- Change Trends::Query#skip to offset
- Change follow recommendations to be refreshed in a transaction
* Add tests for trending statuses filtering behaviour
* Fix not applying filtering scope in controller
* Add appeals
* Add ability to reject appeals and ability to browse pending appeals in admin UI
* Add strikes to account page in settings
* Various fixes and improvements
- Add separate notification setting for appeals, separate from reports
- Fix style of links in report/strike header
- Change approving an appeal to not restore statuses (due to federation complexities)
- Change style of successfully appealed strikes on account settings page
- Change account settings page to only show unappealed or recently appealed strikes
* Change appealed_at to overruled_at
* Fix missing method error
* Change account and user fabricators to simplify and improve tests
- `Fabricate(:account)` implicitly fabricates an associated `user` if
no `domain` attribute is given (an account with `domain: nil` is
considered a local account, but no user record was created), unless
`user: nil` is passed
- `Fabricate(:account, user: Fabricate(:user))` should still be possible
but is discouraged.
* Fix and refactor tests
- avoid passing unneeded attributes to `Fabricate(:user)` or
`Fabricate(:account)`
- avoid embedding `Fabricate(:user)` into a `Fabricate(:account)` or the other
way around
- prefer `Fabricate(:user, account_attributes: …)` to
`Fabricate(:user, account: Fabricate(:account, …)`
- also, some tests were using remote accounts with local user records, which is
not representative of production code.
* 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.
* 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
* 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
Nick Schonning