* 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.
* Remove support for OAUTH_REDIRECT_AT_SIGN_IN
Fixes#15959
Introduced in #6540, OAUTH_REDIRECT_AT_SIGN_IN allowed skipping the log-in form
to instead redirect to the external OmniAuth login provider.
However, it did not prevent the log-in form on /about introduced by #10232 from
appearing, and completely broke with the introduction of #15228.
As I restoring that previous log-in flow without introducing a security
vulnerability may require extensive care and knowledge of how OmniAuth works,
this commit removes support for OAUTH_REDIRECT_AT_SIGN_IN instead for the time
being.
* Add OMNIAUTH_ONLY environment variable to enforce external log-in only
* Disable user registration when OMNIAUTH_ONLY is set to true
* Replace log-in links When OMNIAUTH_ONLY is set with exactly one OmniAuth provider
Fixes#15959
Introduced in #6540, OAUTH_REDIRECT_AT_SIGN_IN allowed skipping the log-in form
to instead redirect to the external OmniAuth login provider.
However, it did not prevent the log-in form on /about introduced by #10232 from
appearing, and completely broke with the introduction of #15228.
As I restoring that previous log-in flow without introducing a security
vulnerability may require extensive care and knowledge of how OmniAuth works,
this commit removes support for OAUTH_REDIRECT_AT_SIGN_IN instead for the time
being.
* 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 admin option to remove canonical email blocks from a deleted account
* Add tootctl canonical_email_blocks to inspect and remove canonical email blocks
Changes from “Retention” to “User retention rate by month after sign-up”.
This should make it much clearer to people not familiar with retention charts
what it actually means.
* ignore hashtag suggestions if they vary only in case
* remove console.logs and unused args
* consistently add space when dismissing suggestions
* linting
* 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
Eugen Rochko