2023-02-22 11:55:31 +11:00
|
|
|
# frozen_string_literal: true
|
|
|
|
|
2016-03-07 22:42:33 +11:00
|
|
|
require 'rails_helper'
|
|
|
|
|
2024-09-04 15:12:25 +10:00
|
|
|
RSpec.describe '/api/v1/statuses' do
|
2017-04-19 05:58:57 +10:00
|
|
|
context 'with an oauth token' do
|
2023-11-17 22:36:04 +11:00
|
|
|
let(:user) { Fabricate(:user) }
|
|
|
|
let(:client_app) { Fabricate(:application, name: 'Test app', website: 'http://testapp.com') }
|
|
|
|
let(:token) { Fabricate(:accessible_access_token, resource_owner_id: user.id, application: client_app, scopes: scopes) }
|
|
|
|
let(:headers) { { 'Authorization' => "Bearer #{token.token}" } }
|
|
|
|
|
2024-05-29 19:19:17 +10:00
|
|
|
describe 'GET /api/v1/statuses?id[]=:id' do
|
2024-05-07 01:19:15 +10:00
|
|
|
let(:status) { Fabricate(:status) }
|
|
|
|
let(:other_status) { Fabricate(:status) }
|
|
|
|
let(:scopes) { 'read:statuses' }
|
|
|
|
|
|
|
|
it 'returns expected response' do
|
2024-05-29 19:19:17 +10:00
|
|
|
get '/api/v1/statuses', headers: headers, params: { id: [status.id, other_status.id, 123_123] }
|
2024-05-07 01:19:15 +10:00
|
|
|
|
|
|
|
expect(response).to have_http_status(200)
|
2024-09-20 23:13:04 +10:00
|
|
|
expect(response.content_type)
|
|
|
|
.to start_with('application/json')
|
2024-09-06 19:58:46 +10:00
|
|
|
expect(response.parsed_body).to contain_exactly(
|
2024-05-07 01:19:15 +10:00
|
|
|
hash_including(id: status.id.to_s),
|
|
|
|
hash_including(id: other_status.id.to_s)
|
|
|
|
)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2023-11-17 22:36:04 +11:00
|
|
|
describe 'GET /api/v1/statuses/:id' do
|
|
|
|
subject do
|
|
|
|
get "/api/v1/statuses/#{status.id}", headers: headers
|
|
|
|
end
|
2016-03-20 23:03:06 +11:00
|
|
|
|
2018-07-06 02:31:35 +10:00
|
|
|
let(:scopes) { 'read:statuses' }
|
2017-04-19 05:58:57 +10:00
|
|
|
let(:status) { Fabricate(:status, account: user.account) }
|
2016-03-20 23:03:06 +11:00
|
|
|
|
2023-11-17 22:36:04 +11:00
|
|
|
it_behaves_like 'forbidden for wrong scope', 'write write:statuses'
|
|
|
|
|
2017-04-19 05:58:57 +10:00
|
|
|
it 'returns http success' do
|
2023-11-17 22:36:04 +11:00
|
|
|
subject
|
|
|
|
|
2018-04-22 05:35:07 +10:00
|
|
|
expect(response).to have_http_status(200)
|
2024-09-20 23:13:04 +10:00
|
|
|
expect(response.content_type)
|
|
|
|
.to start_with('application/json')
|
2017-04-19 05:58:57 +10:00
|
|
|
end
|
Revamp post filtering system (#18058)
* 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.
2022-06-28 17:42:13 +10:00
|
|
|
|
|
|
|
context 'when post includes filtered terms' do
|
|
|
|
let(:status) { Fabricate(:status, text: 'this toot is about that banned word') }
|
|
|
|
|
|
|
|
before do
|
|
|
|
user.account.custom_filters.create!(phrase: 'filter1', context: %w(home), action: :hide, keywords_attributes: [{ keyword: 'banned' }, { keyword: 'irrelevant' }])
|
|
|
|
end
|
|
|
|
|
2023-10-13 23:42:09 +11:00
|
|
|
it 'returns filter information', :aggregate_failures do
|
2023-11-17 22:36:04 +11:00
|
|
|
subject
|
2023-10-13 23:42:09 +11:00
|
|
|
|
|
|
|
expect(response).to have_http_status(200)
|
2024-09-20 23:13:04 +10:00
|
|
|
expect(response.content_type)
|
|
|
|
.to start_with('application/json')
|
2024-09-06 19:58:46 +10:00
|
|
|
expect(response.parsed_body[:filtered][0]).to include({
|
Revamp post filtering system (#18058)
* 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.
2022-06-28 17:42:13 +10:00
|
|
|
filter: a_hash_including({
|
|
|
|
id: user.account.custom_filters.first.id.to_s,
|
|
|
|
title: 'filter1',
|
|
|
|
filter_action: 'hide',
|
|
|
|
}),
|
|
|
|
keyword_matches: ['banned'],
|
|
|
|
})
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2022-08-25 12:27:47 +10:00
|
|
|
context 'when post is explicitly filtered' do
|
|
|
|
let(:status) { Fabricate(:status, text: 'hello world') }
|
|
|
|
|
|
|
|
before do
|
|
|
|
filter = user.account.custom_filters.create!(phrase: 'filter1', context: %w(home), action: :hide)
|
|
|
|
filter.statuses.create!(status_id: status.id)
|
|
|
|
end
|
|
|
|
|
2023-10-13 23:42:09 +11:00
|
|
|
it 'returns filter information', :aggregate_failures do
|
2023-11-17 22:36:04 +11:00
|
|
|
subject
|
2023-10-13 23:42:09 +11:00
|
|
|
|
|
|
|
expect(response).to have_http_status(200)
|
2024-09-20 23:13:04 +10:00
|
|
|
expect(response.content_type)
|
|
|
|
.to start_with('application/json')
|
2024-09-06 19:58:46 +10:00
|
|
|
expect(response.parsed_body[:filtered][0]).to include({
|
2022-08-25 12:27:47 +10:00
|
|
|
filter: a_hash_including({
|
|
|
|
id: user.account.custom_filters.first.id.to_s,
|
|
|
|
title: 'filter1',
|
|
|
|
filter_action: 'hide',
|
|
|
|
}),
|
|
|
|
status_matches: [status.id.to_s],
|
|
|
|
})
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
Revamp post filtering system (#18058)
* 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.
2022-06-28 17:42:13 +10:00
|
|
|
context 'when reblog includes filtered terms' do
|
|
|
|
let(:status) { Fabricate(:status, reblog: Fabricate(:status, text: 'this toot is about that banned word')) }
|
|
|
|
|
|
|
|
before do
|
|
|
|
user.account.custom_filters.create!(phrase: 'filter1', context: %w(home), action: :hide, keywords_attributes: [{ keyword: 'banned' }, { keyword: 'irrelevant' }])
|
|
|
|
end
|
|
|
|
|
2023-10-13 23:42:09 +11:00
|
|
|
it 'returns filter information', :aggregate_failures do
|
2023-11-17 22:36:04 +11:00
|
|
|
subject
|
2023-10-13 23:42:09 +11:00
|
|
|
|
|
|
|
expect(response).to have_http_status(200)
|
2024-09-20 23:13:04 +10:00
|
|
|
expect(response.content_type)
|
|
|
|
.to start_with('application/json')
|
2024-09-06 19:58:46 +10:00
|
|
|
expect(response.parsed_body[:reblog][:filtered][0]).to include({
|
Revamp post filtering system (#18058)
* 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.
2022-06-28 17:42:13 +10:00
|
|
|
filter: a_hash_including({
|
|
|
|
id: user.account.custom_filters.first.id.to_s,
|
|
|
|
title: 'filter1',
|
|
|
|
filter_action: 'hide',
|
|
|
|
}),
|
|
|
|
keyword_matches: ['banned'],
|
|
|
|
})
|
|
|
|
end
|
|
|
|
end
|
2016-03-20 23:03:06 +11:00
|
|
|
end
|
2016-03-07 22:42:33 +11:00
|
|
|
|
2023-11-17 22:36:04 +11:00
|
|
|
describe 'GET /api/v1/statuses/:id/context' do
|
2018-07-06 02:31:35 +10:00
|
|
|
let(:scopes) { 'read:statuses' }
|
2017-04-19 05:58:57 +10:00
|
|
|
let(:status) { Fabricate(:status, account: user.account) }
|
2016-09-16 08:27:09 +10:00
|
|
|
|
2017-04-19 05:58:57 +10:00
|
|
|
before do
|
|
|
|
Fabricate(:status, account: user.account, thread: status)
|
|
|
|
end
|
2016-09-16 08:27:09 +10:00
|
|
|
|
2017-04-19 05:58:57 +10:00
|
|
|
it 'returns http success' do
|
2023-11-17 22:36:04 +11:00
|
|
|
get "/api/v1/statuses/#{status.id}/context", headers: headers
|
|
|
|
|
2018-04-22 05:35:07 +10:00
|
|
|
expect(response).to have_http_status(200)
|
2024-09-20 23:13:04 +10:00
|
|
|
expect(response.content_type)
|
|
|
|
.to start_with('application/json')
|
2017-04-19 05:58:57 +10:00
|
|
|
end
|
2016-09-16 08:27:09 +10:00
|
|
|
end
|
|
|
|
|
2023-11-17 22:36:04 +11:00
|
|
|
describe 'POST /api/v1/statuses' do
|
|
|
|
subject do
|
|
|
|
post '/api/v1/statuses', headers: headers, params: params
|
|
|
|
end
|
|
|
|
|
2018-07-06 02:31:35 +10:00
|
|
|
let(:scopes) { 'write:statuses' }
|
2023-11-17 22:36:04 +11:00
|
|
|
let(:params) { { status: 'Hello world' } }
|
2018-07-06 02:31:35 +10:00
|
|
|
|
2023-11-17 22:36:04 +11:00
|
|
|
it_behaves_like 'forbidden for wrong scope', 'read read:statuses'
|
2020-03-09 01:17:39 +11:00
|
|
|
|
2023-11-17 22:36:04 +11:00
|
|
|
context 'with a basic status body' do
|
2023-10-13 23:42:09 +11:00
|
|
|
it 'returns rate limit headers', :aggregate_failures do
|
2023-11-17 22:36:04 +11:00
|
|
|
subject
|
|
|
|
|
2020-03-09 01:17:39 +11:00
|
|
|
expect(response).to have_http_status(200)
|
2024-09-20 23:13:04 +10:00
|
|
|
expect(response.content_type)
|
|
|
|
.to start_with('application/json')
|
2020-03-09 01:17:39 +11:00
|
|
|
expect(response.headers['X-RateLimit-Limit']).to eq RateLimiter::FAMILIES[:statuses][:limit].to_s
|
|
|
|
expect(response.headers['X-RateLimit-Remaining']).to eq (RateLimiter::FAMILIES[:statuses][:limit] - 1).to_s
|
|
|
|
end
|
2017-04-19 05:58:57 +10:00
|
|
|
end
|
2016-09-05 09:26:08 +10:00
|
|
|
|
2023-02-14 02:36:29 +11:00
|
|
|
context 'with a safeguard' do
|
|
|
|
let!(:alice) { Fabricate(:account, username: 'alice') }
|
|
|
|
let!(:bob) { Fabricate(:account, username: 'bob') }
|
|
|
|
|
2023-11-17 22:36:04 +11:00
|
|
|
let(:params) { { status: '@alice hm, @bob is really annoying lately', allowed_mentions: [alice.id] } }
|
2023-02-14 02:36:29 +11:00
|
|
|
|
2023-10-13 23:42:09 +11:00
|
|
|
it 'returns serialized extra accounts in body', :aggregate_failures do
|
2023-11-17 22:36:04 +11:00
|
|
|
subject
|
|
|
|
|
2023-02-14 02:36:29 +11:00
|
|
|
expect(response).to have_http_status(422)
|
2024-09-20 23:13:04 +10:00
|
|
|
expect(response.content_type)
|
|
|
|
.to start_with('application/json')
|
2024-09-06 19:58:46 +10:00
|
|
|
expect(response.parsed_body[:unexpected_accounts].map { |a| a.slice(:id, :acct) }).to match [{ id: bob.id.to_s, acct: bob.acct }]
|
2023-02-14 02:36:29 +11:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2020-03-09 01:17:39 +11:00
|
|
|
context 'with missing parameters' do
|
2023-11-17 22:36:04 +11:00
|
|
|
let(:params) { {} }
|
2020-03-09 01:17:39 +11:00
|
|
|
|
2023-10-13 23:42:09 +11:00
|
|
|
it 'returns rate limit headers', :aggregate_failures do
|
2023-11-17 22:36:04 +11:00
|
|
|
subject
|
|
|
|
|
2020-03-09 01:17:39 +11:00
|
|
|
expect(response).to have_http_status(422)
|
2024-09-20 23:13:04 +10:00
|
|
|
expect(response.content_type)
|
|
|
|
.to start_with('application/json')
|
2020-03-09 01:17:39 +11:00
|
|
|
expect(response.headers['X-RateLimit-Limit']).to eq RateLimiter::FAMILIES[:statuses][:limit].to_s
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
context 'when exceeding rate limit' do
|
|
|
|
before do
|
|
|
|
rate_limiter = RateLimiter.new(user.account, family: :statuses)
|
2023-11-22 00:05:59 +11:00
|
|
|
RateLimiter::FAMILIES[:statuses][:limit].times { rate_limiter.record! }
|
2020-03-09 01:17:39 +11:00
|
|
|
end
|
|
|
|
|
2023-10-13 23:42:09 +11:00
|
|
|
it 'returns rate limit headers', :aggregate_failures do
|
2023-11-17 22:36:04 +11:00
|
|
|
subject
|
|
|
|
|
2020-03-09 01:17:39 +11:00
|
|
|
expect(response).to have_http_status(429)
|
2024-09-20 23:13:04 +10:00
|
|
|
expect(response.content_type)
|
|
|
|
.to start_with('application/json')
|
2020-03-09 01:17:39 +11:00
|
|
|
expect(response.headers['X-RateLimit-Limit']).to eq RateLimiter::FAMILIES[:statuses][:limit].to_s
|
|
|
|
expect(response.headers['X-RateLimit-Remaining']).to eq '0'
|
|
|
|
end
|
2017-04-19 05:58:57 +10:00
|
|
|
end
|
2024-02-20 00:35:58 +11:00
|
|
|
|
|
|
|
context 'with missing thread' do
|
|
|
|
let(:params) { { status: 'Hello world', in_reply_to_id: 0 } }
|
|
|
|
|
|
|
|
it 'returns http not found' do
|
|
|
|
subject
|
|
|
|
|
|
|
|
expect(response).to have_http_status(404)
|
2024-09-20 23:13:04 +10:00
|
|
|
expect(response.content_type)
|
|
|
|
.to start_with('application/json')
|
2024-02-20 00:35:58 +11:00
|
|
|
end
|
|
|
|
end
|
2024-06-10 23:33:48 +10:00
|
|
|
|
|
|
|
context 'when scheduling a status' do
|
|
|
|
let(:params) { { status: 'Hello world', scheduled_at: 10.minutes.from_now } }
|
|
|
|
let(:account) { user.account }
|
|
|
|
|
|
|
|
it 'returns HTTP 200' do
|
|
|
|
subject
|
|
|
|
|
|
|
|
expect(response).to have_http_status(200)
|
2024-09-20 23:13:04 +10:00
|
|
|
expect(response.content_type)
|
|
|
|
.to start_with('application/json')
|
2024-06-10 23:33:48 +10:00
|
|
|
end
|
|
|
|
|
|
|
|
it 'creates a scheduled status' do
|
|
|
|
expect { subject }.to change { account.scheduled_statuses.count }.from(0).to(1)
|
|
|
|
end
|
|
|
|
|
|
|
|
context 'when the scheduling time is less than 5 minutes' do
|
|
|
|
let(:params) { { status: 'Hello world', scheduled_at: 4.minutes.from_now } }
|
|
|
|
|
|
|
|
it 'does not create a scheduled status', :aggregate_failures do
|
|
|
|
subject
|
|
|
|
|
|
|
|
expect(response).to have_http_status(422)
|
2024-09-20 23:13:04 +10:00
|
|
|
expect(response.content_type)
|
|
|
|
.to start_with('application/json')
|
2024-06-10 23:33:48 +10:00
|
|
|
expect(account.scheduled_statuses).to be_empty
|
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
2016-09-05 09:26:08 +10:00
|
|
|
end
|
2016-03-19 22:13:47 +11:00
|
|
|
|
2023-11-17 22:36:04 +11:00
|
|
|
describe 'DELETE /api/v1/statuses/:id' do
|
|
|
|
subject do
|
|
|
|
delete "/api/v1/statuses/#{status.id}", headers: headers
|
|
|
|
end
|
|
|
|
|
2018-07-06 02:31:35 +10:00
|
|
|
let(:scopes) { 'write:statuses' }
|
2017-04-19 05:58:57 +10:00
|
|
|
let(:status) { Fabricate(:status, account: user.account) }
|
2016-09-27 07:55:21 +10:00
|
|
|
|
2023-11-17 22:36:04 +11:00
|
|
|
it_behaves_like 'forbidden for wrong scope', 'read read:statuses'
|
2016-09-27 07:55:21 +10:00
|
|
|
|
2023-10-13 23:42:09 +11:00
|
|
|
it 'removes the status', :aggregate_failures do
|
2023-11-17 22:36:04 +11:00
|
|
|
subject
|
|
|
|
|
2018-04-22 05:35:07 +10:00
|
|
|
expect(response).to have_http_status(200)
|
2024-09-20 23:13:04 +10:00
|
|
|
expect(response.content_type)
|
|
|
|
.to start_with('application/json')
|
2023-02-17 23:45:27 +11:00
|
|
|
expect(Status.find_by(id: status.id)).to be_nil
|
2017-04-19 05:58:57 +10:00
|
|
|
end
|
2016-09-27 07:55:21 +10:00
|
|
|
end
|
2022-02-10 10:15:30 +11:00
|
|
|
|
2023-11-17 22:36:04 +11:00
|
|
|
describe 'PUT /api/v1/statuses/:id' do
|
|
|
|
subject do
|
|
|
|
put "/api/v1/statuses/#{status.id}", headers: headers, params: { status: 'I am updated' }
|
|
|
|
end
|
|
|
|
|
2022-02-10 10:15:30 +11:00
|
|
|
let(:scopes) { 'write:statuses' }
|
|
|
|
let(:status) { Fabricate(:status, account: user.account) }
|
|
|
|
|
2023-11-17 22:36:04 +11:00
|
|
|
it_behaves_like 'forbidden for wrong scope', 'read read:statuses'
|
2022-02-10 10:15:30 +11:00
|
|
|
|
2023-10-13 23:42:09 +11:00
|
|
|
it 'updates the status', :aggregate_failures do
|
2023-11-17 22:36:04 +11:00
|
|
|
subject
|
|
|
|
|
2022-02-10 10:15:30 +11:00
|
|
|
expect(response).to have_http_status(200)
|
2024-09-20 23:13:04 +10:00
|
|
|
expect(response.content_type)
|
|
|
|
.to start_with('application/json')
|
2022-02-10 10:15:30 +11:00
|
|
|
expect(status.reload.text).to eq 'I am updated'
|
|
|
|
end
|
|
|
|
end
|
2017-04-19 05:58:57 +10:00
|
|
|
end
|
2016-09-27 07:55:21 +10:00
|
|
|
|
2017-04-19 05:58:57 +10:00
|
|
|
context 'without an oauth token' do
|
|
|
|
context 'with a private status' do
|
2023-11-17 22:36:04 +11:00
|
|
|
let(:status) { Fabricate(:status, visibility: :private) }
|
2017-04-19 05:58:57 +10:00
|
|
|
|
2023-11-17 22:36:04 +11:00
|
|
|
describe 'GET /api/v1/statuses/:id' do
|
2022-03-07 08:51:40 +11:00
|
|
|
it 'returns http unauthorized' do
|
2023-11-17 22:36:04 +11:00
|
|
|
get "/api/v1/statuses/#{status.id}"
|
|
|
|
|
2018-04-22 05:35:07 +10:00
|
|
|
expect(response).to have_http_status(404)
|
2024-09-20 23:13:04 +10:00
|
|
|
expect(response.content_type)
|
|
|
|
.to start_with('application/json')
|
2017-04-19 05:58:57 +10:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2023-11-17 22:36:04 +11:00
|
|
|
describe 'GET /api/v1/statuses/:id/context' do
|
2017-04-19 05:58:57 +10:00
|
|
|
before do
|
2023-11-17 22:36:04 +11:00
|
|
|
Fabricate(:status, thread: status)
|
2017-04-19 05:58:57 +10:00
|
|
|
end
|
|
|
|
|
2022-03-07 08:51:40 +11:00
|
|
|
it 'returns http unauthorized' do
|
2023-11-17 22:36:04 +11:00
|
|
|
get "/api/v1/statuses/#{status.id}/context"
|
|
|
|
|
2018-04-22 05:35:07 +10:00
|
|
|
expect(response).to have_http_status(404)
|
2024-09-20 23:13:04 +10:00
|
|
|
expect(response.content_type)
|
|
|
|
.to start_with('application/json')
|
2017-04-19 05:58:57 +10:00
|
|
|
end
|
|
|
|
end
|
2016-09-27 07:55:21 +10:00
|
|
|
end
|
|
|
|
|
2017-04-19 05:58:57 +10:00
|
|
|
context 'with a public status' do
|
2023-11-17 22:36:04 +11:00
|
|
|
let(:status) { Fabricate(:status, visibility: :public) }
|
2017-04-19 05:58:57 +10:00
|
|
|
|
2023-11-17 22:36:04 +11:00
|
|
|
describe 'GET /api/v1/statuses/:id' do
|
2017-04-19 05:58:57 +10:00
|
|
|
it 'returns http success' do
|
2023-11-17 22:36:04 +11:00
|
|
|
get "/api/v1/statuses/#{status.id}"
|
|
|
|
|
2018-04-22 05:35:07 +10:00
|
|
|
expect(response).to have_http_status(200)
|
2024-09-20 23:13:04 +10:00
|
|
|
expect(response.content_type)
|
|
|
|
.to start_with('application/json')
|
2017-04-19 05:58:57 +10:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2023-11-17 22:36:04 +11:00
|
|
|
describe 'GET /api/v1/statuses/:id/context' do
|
2017-04-19 05:58:57 +10:00
|
|
|
before do
|
2023-11-17 22:36:04 +11:00
|
|
|
Fabricate(:status, thread: status)
|
2017-04-19 05:58:57 +10:00
|
|
|
end
|
|
|
|
|
|
|
|
it 'returns http success' do
|
2023-11-17 22:36:04 +11:00
|
|
|
get "/api/v1/statuses/#{status.id}/context"
|
|
|
|
|
2018-04-22 05:35:07 +10:00
|
|
|
expect(response).to have_http_status(200)
|
2024-09-20 23:13:04 +10:00
|
|
|
expect(response.content_type)
|
|
|
|
.to start_with('application/json')
|
2017-04-19 05:58:57 +10:00
|
|
|
end
|
|
|
|
end
|
2016-09-27 07:55:21 +10:00
|
|
|
end
|
|
|
|
end
|
2016-03-07 22:42:33 +11:00
|
|
|
end
|