2019-04-29 20:27:42 -04:00
|
|
|
# frozen_string_literal: true
|
|
|
|
|
2018-10-30 18:08:57 -04:00
|
|
|
require 'discourse_ip_info'
|
2021-09-14 08:19:28 -04:00
|
|
|
require 'rotp'
|
2018-02-20 01:44:51 -05:00
|
|
|
|
|
|
|
RSpec.describe Admin::UsersController do
|
2019-05-06 23:12:20 -04:00
|
|
|
fab!(:admin) { Fabricate(:admin) }
|
|
|
|
fab!(:user) { Fabricate(:user) }
|
2021-12-15 12:41:14 -05:00
|
|
|
fab!(:coding_horror) { Fabricate(:coding_horror) }
|
2018-02-20 01:44:51 -05:00
|
|
|
|
2018-06-08 00:42:06 -04:00
|
|
|
it 'is a subclass of AdminController' do
|
|
|
|
expect(Admin::UsersController < Admin::AdminController).to eq(true)
|
|
|
|
end
|
|
|
|
|
|
|
|
before do
|
|
|
|
sign_in(admin)
|
|
|
|
end
|
|
|
|
|
|
|
|
describe '#index' do
|
|
|
|
it 'returns success with JSON' do
|
|
|
|
get "/admin/users/list.json"
|
|
|
|
expect(response.status).to eq(200)
|
2020-05-07 11:04:12 -04:00
|
|
|
expect(response.parsed_body).to be_present
|
2018-06-08 00:42:06 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
context 'when showing emails' do
|
|
|
|
it "returns email for all the users" do
|
|
|
|
get "/admin/users/list.json", params: { show_emails: "true" }
|
|
|
|
expect(response.status).to eq(200)
|
2020-05-07 11:04:12 -04:00
|
|
|
data = response.parsed_body
|
2018-06-08 00:42:06 -04:00
|
|
|
data.each do |user|
|
|
|
|
expect(user["email"]).to be_present
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2021-05-20 21:43:47 -04:00
|
|
|
it "logs only 1 entry" do
|
2018-06-08 00:42:06 -04:00
|
|
|
expect do
|
|
|
|
get "/admin/users/list.json", params: { show_emails: "true" }
|
|
|
|
end.to change { UserHistory.where(action: UserHistory.actions[:check_email], acting_user_id: admin.id).count }.by(1)
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
end
|
2022-05-04 13:07:22 -04:00
|
|
|
|
|
|
|
it "can be ordered by emails" do
|
|
|
|
get "/admin/users/list.json", params: { show_emails: "true", order: "email" }
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
end
|
2018-06-08 00:42:06 -04:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
describe '#show' do
|
|
|
|
context 'an existing user' do
|
|
|
|
it 'returns success' do
|
|
|
|
get "/admin/users/#{user.id}.json"
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
end
|
2022-03-03 11:17:02 -05:00
|
|
|
|
|
|
|
it 'includes associated accounts' do
|
|
|
|
user.user_associated_accounts.create!(provider_name: 'pluginauth', provider_uid: 'pluginauth_uid')
|
|
|
|
|
|
|
|
get "/admin/users/#{user.id}.json"
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
expect(response.parsed_body['external_ids'].size).to eq(1)
|
|
|
|
expect(response.parsed_body['external_ids']['pluginauth']).to eq('pluginauth_uid')
|
|
|
|
end
|
2018-06-08 00:42:06 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
context 'a non-existing user' do
|
|
|
|
it 'returns 404 error' do
|
|
|
|
get "/admin/users/0.json"
|
|
|
|
expect(response.status).to eq(404)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
describe '#approve' do
|
2019-04-16 14:42:47 -04:00
|
|
|
let(:evil_trout) { Fabricate(:evil_trout) }
|
2019-01-03 12:03:01 -05:00
|
|
|
before do
|
|
|
|
SiteSetting.must_approve_users = true
|
|
|
|
end
|
|
|
|
|
2018-06-08 00:42:06 -04:00
|
|
|
it "raises an error when the user doesn't have permission" do
|
|
|
|
sign_in(user)
|
|
|
|
put "/admin/users/#{evil_trout.id}/approve.json"
|
|
|
|
expect(response.status).to eq(404)
|
|
|
|
evil_trout.reload
|
|
|
|
expect(evil_trout.approved).to eq(false)
|
|
|
|
end
|
|
|
|
|
2019-04-16 14:42:47 -04:00
|
|
|
it "will create a reviewable if one does not exist" do
|
|
|
|
evil_trout.update!(active: true)
|
|
|
|
expect(ReviewableUser.find_by(target: evil_trout)).to be_blank
|
|
|
|
put "/admin/users/#{evil_trout.id}/approve.json"
|
|
|
|
expect(response.code).to eq("200")
|
|
|
|
expect(ReviewableUser.find_by(target: evil_trout)).to be_present
|
|
|
|
expect(evil_trout.reload).to be_approved
|
|
|
|
end
|
|
|
|
|
2018-06-08 00:42:06 -04:00
|
|
|
it 'calls approve' do
|
2019-04-03 12:04:05 -04:00
|
|
|
Jobs.run_immediately!
|
|
|
|
evil_trout.activate
|
2018-06-08 00:42:06 -04:00
|
|
|
put "/admin/users/#{evil_trout.id}/approve.json"
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
evil_trout.reload
|
|
|
|
expect(evil_trout.approved).to eq(true)
|
2019-03-12 04:16:56 -04:00
|
|
|
expect(UserHistory.where(action: UserHistory.actions[:approve_user], target_user_id: evil_trout.id).count).to eq(1)
|
2018-06-08 00:42:06 -04:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
describe '#approve_bulk' do
|
2019-01-03 12:03:01 -05:00
|
|
|
before do
|
|
|
|
SiteSetting.must_approve_users = true
|
|
|
|
end
|
|
|
|
|
|
|
|
let(:evil_trout) { Fabricate(:evil_trout) }
|
2018-06-08 00:42:06 -04:00
|
|
|
|
2021-05-20 21:43:47 -04:00
|
|
|
it "does nothing without users" do
|
2018-06-08 00:42:06 -04:00
|
|
|
put "/admin/users/approve-bulk.json"
|
|
|
|
evil_trout.reload
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
expect(evil_trout.approved).to eq(false)
|
|
|
|
end
|
|
|
|
|
|
|
|
it "won't approve the user when not allowed" do
|
|
|
|
sign_in(user)
|
|
|
|
put "/admin/users/approve-bulk.json", params: { users: [evil_trout.id] }
|
|
|
|
expect(response.status).to eq(404)
|
|
|
|
evil_trout.reload
|
|
|
|
expect(evil_trout.approved).to eq(false)
|
|
|
|
end
|
|
|
|
|
|
|
|
it "approves the user when permitted" do
|
2019-04-03 12:04:05 -04:00
|
|
|
Jobs.run_immediately!
|
|
|
|
evil_trout.activate
|
2018-06-08 00:42:06 -04:00
|
|
|
put "/admin/users/approve-bulk.json", params: { users: [evil_trout.id] }
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
evil_trout.reload
|
|
|
|
expect(evil_trout.approved).to eq(true)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
describe '#suspend' do
|
2020-04-21 23:44:19 -04:00
|
|
|
fab!(:created_post) { Fabricate(:post) }
|
2018-06-08 00:42:06 -04:00
|
|
|
let(:suspend_params) do
|
|
|
|
{ suspend_until: 5.hours.from_now,
|
|
|
|
reason: "because of this post",
|
2020-04-21 23:44:19 -04:00
|
|
|
post_id: created_post.id }
|
2018-06-08 00:42:06 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
it "works properly" do
|
|
|
|
expect(user).not_to be_suspended
|
2021-04-12 11:03:10 -04:00
|
|
|
|
|
|
|
expect do
|
|
|
|
put "/admin/users/#{user.id}/suspend.json", params: {
|
|
|
|
suspend_until: 5.hours.from_now,
|
|
|
|
reason: "because I said so"
|
|
|
|
}
|
|
|
|
end.to change { Jobs::CriticalUserEmail.jobs.size }.by(0)
|
2018-06-08 00:42:06 -04:00
|
|
|
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
|
|
|
|
user.reload
|
|
|
|
expect(user).to be_suspended
|
|
|
|
expect(user.suspended_at).to be_present
|
|
|
|
expect(user.suspended_till).to be_present
|
|
|
|
|
|
|
|
log = UserHistory.where(target_user_id: user.id).order('id desc').first
|
|
|
|
expect(log.details).to match(/because I said so/)
|
|
|
|
end
|
|
|
|
|
2020-11-03 10:38:56 -05:00
|
|
|
it "checks if user is suspended" do
|
|
|
|
put "/admin/users/#{user.id}/suspend.json", params: {
|
|
|
|
suspend_until: 5.hours.from_now,
|
|
|
|
reason: "because I said so"
|
|
|
|
}
|
|
|
|
|
|
|
|
put "/admin/users/#{user.id}/suspend.json", params: {
|
|
|
|
suspend_until: 5.hours.from_now,
|
|
|
|
reason: "because I said so too"
|
|
|
|
}
|
|
|
|
|
|
|
|
expect(response.status).to eq(409)
|
|
|
|
expect(response.parsed_body["message"]).to eq(
|
|
|
|
I18n.t(
|
|
|
|
"user.already_suspended",
|
|
|
|
staff: admin.username,
|
|
|
|
time_ago: FreedomPatches::Rails4.time_ago_in_words(user.suspend_record.created_at, true, scope: :'datetime.distance_in_words_verbose')
|
|
|
|
)
|
|
|
|
)
|
|
|
|
end
|
|
|
|
|
2020-08-26 21:05:33 -04:00
|
|
|
it "requires suspend_until and reason" do
|
|
|
|
expect(user).not_to be_suspended
|
|
|
|
put "/admin/users/#{user.id}/suspend.json", params: {}
|
|
|
|
expect(response.status).to eq(400)
|
|
|
|
user.reload
|
|
|
|
expect(user).not_to be_suspended
|
|
|
|
|
|
|
|
expect(user).not_to be_suspended
|
|
|
|
put "/admin/users/#{user.id}/suspend.json", params: {
|
|
|
|
suspend_until: 5.hours.from_now
|
|
|
|
}
|
|
|
|
expect(response.status).to eq(400)
|
|
|
|
user.reload
|
|
|
|
expect(user).not_to be_suspended
|
|
|
|
end
|
|
|
|
|
2018-06-08 00:42:06 -04:00
|
|
|
context "with an associated post" do
|
|
|
|
it "can have an associated post" do
|
|
|
|
put "/admin/users/#{user.id}/suspend.json", params: suspend_params
|
|
|
|
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
|
|
|
|
log = UserHistory.where(target_user_id: user.id).order('id desc').first
|
2020-04-21 23:44:19 -04:00
|
|
|
expect(log.post_id).to eq(created_post.id)
|
2018-06-08 00:42:06 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
it "can delete an associated post" do
|
|
|
|
put "/admin/users/#{user.id}/suspend.json", params: suspend_params.merge(post_action: 'delete')
|
2020-04-21 23:44:19 -04:00
|
|
|
created_post.reload
|
|
|
|
expect(created_post.deleted_at).to be_present
|
2018-06-08 00:42:06 -04:00
|
|
|
expect(response.status).to eq(200)
|
|
|
|
end
|
|
|
|
|
2019-05-30 16:42:59 -04:00
|
|
|
it "won't delete a category topic" do
|
2019-08-06 06:26:54 -04:00
|
|
|
c = Fabricate(:category_with_definition)
|
2019-05-30 16:42:59 -04:00
|
|
|
cat_post = c.topic.posts.first
|
|
|
|
put(
|
|
|
|
"/admin/users/#{user.id}/suspend.json",
|
|
|
|
params: suspend_params.merge(
|
|
|
|
post_action: 'delete',
|
|
|
|
post_id: cat_post.id
|
|
|
|
)
|
|
|
|
)
|
|
|
|
cat_post.reload
|
|
|
|
expect(cat_post.deleted_at).to be_blank
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
end
|
|
|
|
|
|
|
|
it "won't delete a category topic by replies" do
|
2019-08-06 06:26:54 -04:00
|
|
|
c = Fabricate(:category_with_definition)
|
2019-05-30 16:42:59 -04:00
|
|
|
cat_post = c.topic.posts.first
|
|
|
|
put(
|
|
|
|
"/admin/users/#{user.id}/suspend.json",
|
|
|
|
params: suspend_params.merge(
|
|
|
|
post_action: 'delete_replies',
|
|
|
|
post_id: cat_post.id
|
|
|
|
)
|
|
|
|
)
|
|
|
|
cat_post.reload
|
|
|
|
expect(cat_post.deleted_at).to be_blank
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
end
|
|
|
|
|
2019-05-27 12:27:16 -04:00
|
|
|
it "can delete an associated post and its replies" do
|
|
|
|
reply = PostCreator.create(
|
|
|
|
Fabricate(:user),
|
|
|
|
raw: 'this is the reply text',
|
2020-04-21 23:44:19 -04:00
|
|
|
reply_to_post_number: created_post.post_number,
|
|
|
|
topic_id: created_post.topic_id
|
2019-05-27 12:27:16 -04:00
|
|
|
)
|
|
|
|
nested_reply = PostCreator.create(
|
|
|
|
Fabricate(:user),
|
|
|
|
raw: 'this is the reply text2',
|
|
|
|
reply_to_post_number: reply.post_number,
|
2020-04-21 23:44:19 -04:00
|
|
|
topic_id: created_post.topic_id
|
2019-05-27 12:27:16 -04:00
|
|
|
)
|
|
|
|
put "/admin/users/#{user.id}/suspend.json", params: suspend_params.merge(post_action: 'delete_replies')
|
2020-04-21 23:44:19 -04:00
|
|
|
expect(created_post.reload.deleted_at).to be_present
|
2019-05-27 12:27:16 -04:00
|
|
|
expect(reply.reload.deleted_at).to be_present
|
|
|
|
expect(nested_reply.reload.deleted_at).to be_present
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
end
|
|
|
|
|
2018-06-08 00:42:06 -04:00
|
|
|
it "can edit an associated post" do
|
|
|
|
put "/admin/users/#{user.id}/suspend.json", params: suspend_params.merge(
|
|
|
|
post_action: 'edit',
|
|
|
|
post_edit: 'this is the edited content'
|
|
|
|
)
|
|
|
|
|
|
|
|
expect(response.status).to eq(200)
|
2020-04-21 23:44:19 -04:00
|
|
|
created_post.reload
|
|
|
|
expect(created_post.deleted_at).to be_blank
|
|
|
|
expect(created_post.raw).to eq("this is the edited content")
|
2018-06-08 00:42:06 -04:00
|
|
|
expect(response.status).to eq(200)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
it "can send a message to the user" do
|
|
|
|
put "/admin/users/#{user.id}/suspend.json", params: {
|
|
|
|
suspend_until: 10.days.from_now,
|
|
|
|
reason: "short reason",
|
|
|
|
message: "long reason"
|
|
|
|
}
|
|
|
|
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
|
|
|
|
expect(Jobs::CriticalUserEmail.jobs.size).to eq(1)
|
|
|
|
job_args = Jobs::CriticalUserEmail.jobs.first["args"].first
|
|
|
|
expect(job_args["type"]).to eq("account_suspended")
|
|
|
|
expect(job_args["user_id"]).to eq(user.id)
|
|
|
|
|
|
|
|
log = UserHistory.where(target_user_id: user.id).order('id desc').first
|
|
|
|
expect(log).to be_present
|
|
|
|
expect(log.details).to match(/short reason/)
|
|
|
|
expect(log.details).to match(/long reason/)
|
|
|
|
end
|
|
|
|
|
2019-11-05 09:10:23 -05:00
|
|
|
it "also prevents use of any api keys" do
|
|
|
|
api_key = Fabricate(:api_key, user: user)
|
2020-04-21 23:44:19 -04:00
|
|
|
post "/bookmarks.json", params: {
|
|
|
|
post_id: Fabricate(:post).id
|
2020-04-06 18:55:44 -04:00
|
|
|
}, headers: { HTTP_API_KEY: api_key.key }
|
2019-11-05 09:10:23 -05:00
|
|
|
expect(response.status).to eq(200)
|
|
|
|
|
|
|
|
put "/admin/users/#{user.id}/suspend.json", params: suspend_params
|
2018-06-08 00:42:06 -04:00
|
|
|
expect(response.status).to eq(200)
|
|
|
|
|
2019-11-05 09:10:23 -05:00
|
|
|
user.reload
|
2018-06-08 00:42:06 -04:00
|
|
|
expect(user).to be_suspended
|
2019-11-05 09:10:23 -05:00
|
|
|
|
2020-04-21 23:44:19 -04:00
|
|
|
post "/bookmarks.json", params: {
|
|
|
|
post_id: Fabricate(:post).id
|
|
|
|
}, headers: { HTTP_API_KEY: api_key.key }
|
2019-11-05 09:10:23 -05:00
|
|
|
expect(response.status).to eq(403)
|
2018-06-08 00:42:06 -04:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
describe '#revoke_admin' do
|
2019-05-06 23:12:20 -04:00
|
|
|
fab!(:another_admin) { Fabricate(:admin) }
|
2018-06-08 00:42:06 -04:00
|
|
|
|
|
|
|
it 'raises an error unless the user can revoke access' do
|
|
|
|
sign_in(user)
|
|
|
|
put "/admin/users/#{another_admin.id}/revoke_admin.json"
|
|
|
|
expect(response.status).to eq(404)
|
|
|
|
another_admin.reload
|
|
|
|
expect(another_admin.admin).to eq(true)
|
|
|
|
end
|
|
|
|
|
|
|
|
it 'updates the admin flag' do
|
|
|
|
put "/admin/users/#{another_admin.id}/revoke_admin.json"
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
another_admin.reload
|
|
|
|
expect(another_admin.admin).to eq(false)
|
|
|
|
end
|
FIX: Revoking admin or moderator status doesn't require refresh to delete/anonymize/merge user (#14073)
* FIX: Revoking admin or moderator status doesn't require refresh to delete/anonymize/merge user
On the /admin/users/<id>/<username> page, there are action buttons that are either visible or hidden depending on a few fields from the AdminDetailsSerializer: `can_be_deleted`, `can_be_anonymized`, `can_be_merged`, `can_delete_all_posts`.
These fields are updated when granting/revoking admin or moderator status. However, those updates were not being reflected on the page. E.g. if a user is granted moderation privileges, the 'anonymize user' and 'merge' buttons still appear on the page, which is inconsistent with the backend state of the user. It requires refreshing the page to update the state.
This commit fixes that issue, by syncing the client model state with the server state when handling a successful response from the server. Now, when revoking privileges, the buttons automatically appear without refreshing the page. Similarly, when granting moderator privileges, the buttons automatically disappear without refreshing the page.
* Add detailed user response to spec for changed routes.
Add tests to verify that the revoke_moderation, grant_moderation, and revoke_admin routes return a response formatted according to the AdminDetailedUserSerializer.
2021-08-18 21:57:16 -04:00
|
|
|
|
|
|
|
it 'returns detailed user schema' do
|
|
|
|
put "/admin/users/#{another_admin.id}/revoke_admin.json"
|
|
|
|
expect(response.parsed_body['can_be_merged']).to eq(true)
|
|
|
|
expect(response.parsed_body['can_be_deleted']).to eq(true)
|
|
|
|
expect(response.parsed_body['can_be_anonymized']).to eq(true)
|
|
|
|
expect(response.parsed_body['can_delete_all_posts']).to eq(true)
|
|
|
|
end
|
2018-06-08 00:42:06 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
describe '#grant_admin' do
|
2021-12-15 12:41:14 -05:00
|
|
|
fab!(:another_user) { coding_horror }
|
2018-06-08 00:42:06 -04:00
|
|
|
|
|
|
|
after do
|
2020-05-23 00:56:13 -04:00
|
|
|
Discourse.redis.flushdb
|
2018-06-08 00:42:06 -04:00
|
|
|
end
|
|
|
|
|
FEATURE: Centralized 2FA page (#15377)
2FA support in Discourse was added and grown gradually over the years: we first
added support for TOTP for logins, then we implemented backup codes, and last
but not least, security keys. 2FA usage was initially limited to logging in,
but it has been expanded and we now require 2FA for risky actions such as
adding a new admin to the site.
As a result of this gradual growth of the 2FA system, technical debt has
accumulated to the point where it has become difficult to require 2FA for more
actions. We now have 5 different 2FA UI implementations and each one has to
support all 3 2FA methods (TOTP, backup codes, and security keys) which makes
it difficult to maintain a consistent UX for these different implementations.
Moreover, there is a lot of repeated logic in the server-side code behind these
5 UI implementations which hinders maintainability even more.
This commit is the first step towards repaying the technical debt: it builds a
system that centralizes as much as possible of the 2FA server-side logic and
UI. The 2 main components of this system are:
1. A dedicated page for 2FA with support for all 3 methods.
2. A reusable server-side class that centralizes the 2FA logic (the
`SecondFactor::AuthManager` class).
From a top-level view, the 2FA flow in this new system looks like this:
1. User initiates an action that requires 2FA;
2. Server is aware that 2FA is required for this action, so it redirects the
user to the 2FA page if the user has a 2FA method, otherwise the action is
performed.
3. User submits the 2FA form on the page;
4. Server validates the 2FA and if it's successful, the action is performed and
the user is redirected to the previous page.
A more technically-detailed explanation/documentation of the new system is
available as a comment at the top of the `lib/second_factor/auth_manager.rb`
file. Please note that the details are not set in stone and will likely change
in the future, so please don't use the system in your plugins yet.
Since this is a new system that needs to be tested, we've decided to migrate
only the 2FA for adding a new admin to the new system at this time (in this
commit). Our plan is to gradually migrate the remaining 2FA implementations to
the new system.
For screenshots of the 2FA page, see PR #15377 on GitHub.
2022-02-17 04:12:59 -05:00
|
|
|
it "returns a 404 when the acting user doesn't have permission" do
|
|
|
|
sign_in(user)
|
|
|
|
put "/admin/users/#{another_user.id}/grant_admin.json"
|
|
|
|
expect(response.status).to eq(404)
|
|
|
|
expect(AdminConfirmation.exists_for?(another_user.id)).to eq(false)
|
|
|
|
end
|
|
|
|
|
|
|
|
it "returns a 404 when the acting user doesn't have permission even if they have 2FA enabled" do
|
|
|
|
Fabricate(:user_second_factor_totp, user: user)
|
2018-06-08 00:42:06 -04:00
|
|
|
sign_in(user)
|
|
|
|
put "/admin/users/#{another_user.id}/grant_admin.json"
|
|
|
|
expect(response.status).to eq(404)
|
|
|
|
expect(AdminConfirmation.exists_for?(another_user.id)).to eq(false)
|
|
|
|
end
|
|
|
|
|
2018-12-14 19:01:35 -05:00
|
|
|
it "returns a 404 if the username doesn't exist" do
|
2018-06-08 00:42:06 -04:00
|
|
|
put "/admin/users/123123/grant_admin.json"
|
2018-12-14 19:01:35 -05:00
|
|
|
expect(response.status).to eq(404)
|
2018-06-08 00:42:06 -04:00
|
|
|
end
|
|
|
|
|
FEATURE: Centralized 2FA page (#15377)
2FA support in Discourse was added and grown gradually over the years: we first
added support for TOTP for logins, then we implemented backup codes, and last
but not least, security keys. 2FA usage was initially limited to logging in,
but it has been expanded and we now require 2FA for risky actions such as
adding a new admin to the site.
As a result of this gradual growth of the 2FA system, technical debt has
accumulated to the point where it has become difficult to require 2FA for more
actions. We now have 5 different 2FA UI implementations and each one has to
support all 3 2FA methods (TOTP, backup codes, and security keys) which makes
it difficult to maintain a consistent UX for these different implementations.
Moreover, there is a lot of repeated logic in the server-side code behind these
5 UI implementations which hinders maintainability even more.
This commit is the first step towards repaying the technical debt: it builds a
system that centralizes as much as possible of the 2FA server-side logic and
UI. The 2 main components of this system are:
1. A dedicated page for 2FA with support for all 3 methods.
2. A reusable server-side class that centralizes the 2FA logic (the
`SecondFactor::AuthManager` class).
From a top-level view, the 2FA flow in this new system looks like this:
1. User initiates an action that requires 2FA;
2. Server is aware that 2FA is required for this action, so it redirects the
user to the 2FA page if the user has a 2FA method, otherwise the action is
performed.
3. User submits the 2FA form on the page;
4. Server validates the 2FA and if it's successful, the action is performed and
the user is redirected to the previous page.
A more technically-detailed explanation/documentation of the new system is
available as a comment at the top of the `lib/second_factor/auth_manager.rb`
file. Please note that the details are not set in stone and will likely change
in the future, so please don't use the system in your plugins yet.
Since this is a new system that needs to be tested, we've decided to migrate
only the 2FA for adding a new admin to the new system at this time (in this
commit). Our plan is to gradually migrate the remaining 2FA implementations to
the new system.
For screenshots of the 2FA page, see PR #15377 on GitHub.
2022-02-17 04:12:59 -05:00
|
|
|
it 'sends a confirmation email if the acting admin does not have a second factor method enabled' do
|
2018-06-08 00:42:06 -04:00
|
|
|
expect(AdminConfirmation.exists_for?(another_user.id)).to eq(false)
|
|
|
|
put "/admin/users/#{another_user.id}/grant_admin.json"
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
expect(AdminConfirmation.exists_for?(another_user.id)).to eq(true)
|
|
|
|
end
|
2021-09-14 08:19:28 -04:00
|
|
|
|
FEATURE: Centralized 2FA page (#15377)
2FA support in Discourse was added and grown gradually over the years: we first
added support for TOTP for logins, then we implemented backup codes, and last
but not least, security keys. 2FA usage was initially limited to logging in,
but it has been expanded and we now require 2FA for risky actions such as
adding a new admin to the site.
As a result of this gradual growth of the 2FA system, technical debt has
accumulated to the point where it has become difficult to require 2FA for more
actions. We now have 5 different 2FA UI implementations and each one has to
support all 3 2FA methods (TOTP, backup codes, and security keys) which makes
it difficult to maintain a consistent UX for these different implementations.
Moreover, there is a lot of repeated logic in the server-side code behind these
5 UI implementations which hinders maintainability even more.
This commit is the first step towards repaying the technical debt: it builds a
system that centralizes as much as possible of the 2FA server-side logic and
UI. The 2 main components of this system are:
1. A dedicated page for 2FA with support for all 3 methods.
2. A reusable server-side class that centralizes the 2FA logic (the
`SecondFactor::AuthManager` class).
From a top-level view, the 2FA flow in this new system looks like this:
1. User initiates an action that requires 2FA;
2. Server is aware that 2FA is required for this action, so it redirects the
user to the 2FA page if the user has a 2FA method, otherwise the action is
performed.
3. User submits the 2FA form on the page;
4. Server validates the 2FA and if it's successful, the action is performed and
the user is redirected to the previous page.
A more technically-detailed explanation/documentation of the new system is
available as a comment at the top of the `lib/second_factor/auth_manager.rb`
file. Please note that the details are not set in stone and will likely change
in the future, so please don't use the system in your plugins yet.
Since this is a new system that needs to be tested, we've decided to migrate
only the 2FA for adding a new admin to the new system at this time (in this
commit). Our plan is to gradually migrate the remaining 2FA implementations to
the new system.
For screenshots of the 2FA page, see PR #15377 on GitHub.
2022-02-17 04:12:59 -05:00
|
|
|
it 'asks the acting admin for second factor if it is enabled' do
|
|
|
|
Fabricate(:user_second_factor_totp, user: admin)
|
2021-09-14 08:19:28 -04:00
|
|
|
|
2022-04-13 08:04:09 -04:00
|
|
|
put "/admin/users/#{another_user.id}/grant_admin.json", xhr: true
|
2021-09-14 08:19:28 -04:00
|
|
|
|
FEATURE: Centralized 2FA page (#15377)
2FA support in Discourse was added and grown gradually over the years: we first
added support for TOTP for logins, then we implemented backup codes, and last
but not least, security keys. 2FA usage was initially limited to logging in,
but it has been expanded and we now require 2FA for risky actions such as
adding a new admin to the site.
As a result of this gradual growth of the 2FA system, technical debt has
accumulated to the point where it has become difficult to require 2FA for more
actions. We now have 5 different 2FA UI implementations and each one has to
support all 3 2FA methods (TOTP, backup codes, and security keys) which makes
it difficult to maintain a consistent UX for these different implementations.
Moreover, there is a lot of repeated logic in the server-side code behind these
5 UI implementations which hinders maintainability even more.
This commit is the first step towards repaying the technical debt: it builds a
system that centralizes as much as possible of the 2FA server-side logic and
UI. The 2 main components of this system are:
1. A dedicated page for 2FA with support for all 3 methods.
2. A reusable server-side class that centralizes the 2FA logic (the
`SecondFactor::AuthManager` class).
From a top-level view, the 2FA flow in this new system looks like this:
1. User initiates an action that requires 2FA;
2. Server is aware that 2FA is required for this action, so it redirects the
user to the 2FA page if the user has a 2FA method, otherwise the action is
performed.
3. User submits the 2FA form on the page;
4. Server validates the 2FA and if it's successful, the action is performed and
the user is redirected to the previous page.
A more technically-detailed explanation/documentation of the new system is
available as a comment at the top of the `lib/second_factor/auth_manager.rb`
file. Please note that the details are not set in stone and will likely change
in the future, so please don't use the system in your plugins yet.
Since this is a new system that needs to be tested, we've decided to migrate
only the 2FA for adding a new admin to the new system at this time (in this
commit). Our plan is to gradually migrate the remaining 2FA implementations to
the new system.
For screenshots of the 2FA page, see PR #15377 on GitHub.
2022-02-17 04:12:59 -05:00
|
|
|
expect(response.parsed_body["second_factor_challenge_nonce"]).to be_present
|
2021-09-14 08:19:28 -04:00
|
|
|
expect(another_user.reload.admin).to eq(false)
|
|
|
|
end
|
|
|
|
|
|
|
|
it 'grants admin if second factor is correct' do
|
|
|
|
user_second_factor = Fabricate(:user_second_factor_totp, user: admin)
|
|
|
|
|
2022-04-13 08:04:09 -04:00
|
|
|
put "/admin/users/#{another_user.id}/grant_admin.json", xhr: true
|
FEATURE: Centralized 2FA page (#15377)
2FA support in Discourse was added and grown gradually over the years: we first
added support for TOTP for logins, then we implemented backup codes, and last
but not least, security keys. 2FA usage was initially limited to logging in,
but it has been expanded and we now require 2FA for risky actions such as
adding a new admin to the site.
As a result of this gradual growth of the 2FA system, technical debt has
accumulated to the point where it has become difficult to require 2FA for more
actions. We now have 5 different 2FA UI implementations and each one has to
support all 3 2FA methods (TOTP, backup codes, and security keys) which makes
it difficult to maintain a consistent UX for these different implementations.
Moreover, there is a lot of repeated logic in the server-side code behind these
5 UI implementations which hinders maintainability even more.
This commit is the first step towards repaying the technical debt: it builds a
system that centralizes as much as possible of the 2FA server-side logic and
UI. The 2 main components of this system are:
1. A dedicated page for 2FA with support for all 3 methods.
2. A reusable server-side class that centralizes the 2FA logic (the
`SecondFactor::AuthManager` class).
From a top-level view, the 2FA flow in this new system looks like this:
1. User initiates an action that requires 2FA;
2. Server is aware that 2FA is required for this action, so it redirects the
user to the 2FA page if the user has a 2FA method, otherwise the action is
performed.
3. User submits the 2FA form on the page;
4. Server validates the 2FA and if it's successful, the action is performed and
the user is redirected to the previous page.
A more technically-detailed explanation/documentation of the new system is
available as a comment at the top of the `lib/second_factor/auth_manager.rb`
file. Please note that the details are not set in stone and will likely change
in the future, so please don't use the system in your plugins yet.
Since this is a new system that needs to be tested, we've decided to migrate
only the 2FA for adding a new admin to the new system at this time (in this
commit). Our plan is to gradually migrate the remaining 2FA implementations to
the new system.
For screenshots of the 2FA page, see PR #15377 on GitHub.
2022-02-17 04:12:59 -05:00
|
|
|
nonce = response.parsed_body["second_factor_challenge_nonce"]
|
|
|
|
expect(nonce).to be_present
|
|
|
|
expect(another_user.reload.admin).to eq(false)
|
|
|
|
|
|
|
|
post "/session/2fa.json", params: {
|
|
|
|
nonce: nonce,
|
2021-09-14 08:19:28 -04:00
|
|
|
second_factor_token: ROTP::TOTP.new(user_second_factor.data).now,
|
|
|
|
second_factor_method: UserSecondFactor.methods[:totp]
|
|
|
|
}
|
FEATURE: Centralized 2FA page (#15377)
2FA support in Discourse was added and grown gradually over the years: we first
added support for TOTP for logins, then we implemented backup codes, and last
but not least, security keys. 2FA usage was initially limited to logging in,
but it has been expanded and we now require 2FA for risky actions such as
adding a new admin to the site.
As a result of this gradual growth of the 2FA system, technical debt has
accumulated to the point where it has become difficult to require 2FA for more
actions. We now have 5 different 2FA UI implementations and each one has to
support all 3 2FA methods (TOTP, backup codes, and security keys) which makes
it difficult to maintain a consistent UX for these different implementations.
Moreover, there is a lot of repeated logic in the server-side code behind these
5 UI implementations which hinders maintainability even more.
This commit is the first step towards repaying the technical debt: it builds a
system that centralizes as much as possible of the 2FA server-side logic and
UI. The 2 main components of this system are:
1. A dedicated page for 2FA with support for all 3 methods.
2. A reusable server-side class that centralizes the 2FA logic (the
`SecondFactor::AuthManager` class).
From a top-level view, the 2FA flow in this new system looks like this:
1. User initiates an action that requires 2FA;
2. Server is aware that 2FA is required for this action, so it redirects the
user to the 2FA page if the user has a 2FA method, otherwise the action is
performed.
3. User submits the 2FA form on the page;
4. Server validates the 2FA and if it's successful, the action is performed and
the user is redirected to the previous page.
A more technically-detailed explanation/documentation of the new system is
available as a comment at the top of the `lib/second_factor/auth_manager.rb`
file. Please note that the details are not set in stone and will likely change
in the future, so please don't use the system in your plugins yet.
Since this is a new system that needs to be tested, we've decided to migrate
only the 2FA for adding a new admin to the new system at this time (in this
commit). Our plan is to gradually migrate the remaining 2FA implementations to
the new system.
For screenshots of the 2FA page, see PR #15377 on GitHub.
2022-02-17 04:12:59 -05:00
|
|
|
res = response.parsed_body
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
expect(res["ok"]).to eq(true)
|
|
|
|
expect(res["callback_method"]).to eq("PUT")
|
|
|
|
expect(res["callback_path"]).to eq("/admin/users/#{another_user.id}/grant_admin.json")
|
2022-04-13 08:04:09 -04:00
|
|
|
expect(res["redirect_url"]).to eq("/admin/users/#{another_user.id}/#{another_user.username}")
|
FEATURE: Centralized 2FA page (#15377)
2FA support in Discourse was added and grown gradually over the years: we first
added support for TOTP for logins, then we implemented backup codes, and last
but not least, security keys. 2FA usage was initially limited to logging in,
but it has been expanded and we now require 2FA for risky actions such as
adding a new admin to the site.
As a result of this gradual growth of the 2FA system, technical debt has
accumulated to the point where it has become difficult to require 2FA for more
actions. We now have 5 different 2FA UI implementations and each one has to
support all 3 2FA methods (TOTP, backup codes, and security keys) which makes
it difficult to maintain a consistent UX for these different implementations.
Moreover, there is a lot of repeated logic in the server-side code behind these
5 UI implementations which hinders maintainability even more.
This commit is the first step towards repaying the technical debt: it builds a
system that centralizes as much as possible of the 2FA server-side logic and
UI. The 2 main components of this system are:
1. A dedicated page for 2FA with support for all 3 methods.
2. A reusable server-side class that centralizes the 2FA logic (the
`SecondFactor::AuthManager` class).
From a top-level view, the 2FA flow in this new system looks like this:
1. User initiates an action that requires 2FA;
2. Server is aware that 2FA is required for this action, so it redirects the
user to the 2FA page if the user has a 2FA method, otherwise the action is
performed.
3. User submits the 2FA form on the page;
4. Server validates the 2FA and if it's successful, the action is performed and
the user is redirected to the previous page.
A more technically-detailed explanation/documentation of the new system is
available as a comment at the top of the `lib/second_factor/auth_manager.rb`
file. Please note that the details are not set in stone and will likely change
in the future, so please don't use the system in your plugins yet.
Since this is a new system that needs to be tested, we've decided to migrate
only the 2FA for adding a new admin to the new system at this time (in this
commit). Our plan is to gradually migrate the remaining 2FA implementations to
the new system.
For screenshots of the 2FA page, see PR #15377 on GitHub.
2022-02-17 04:12:59 -05:00
|
|
|
expect(another_user.reload.admin).to eq(false)
|
2021-09-14 08:19:28 -04:00
|
|
|
|
FEATURE: Centralized 2FA page (#15377)
2FA support in Discourse was added and grown gradually over the years: we first
added support for TOTP for logins, then we implemented backup codes, and last
but not least, security keys. 2FA usage was initially limited to logging in,
but it has been expanded and we now require 2FA for risky actions such as
adding a new admin to the site.
As a result of this gradual growth of the 2FA system, technical debt has
accumulated to the point where it has become difficult to require 2FA for more
actions. We now have 5 different 2FA UI implementations and each one has to
support all 3 2FA methods (TOTP, backup codes, and security keys) which makes
it difficult to maintain a consistent UX for these different implementations.
Moreover, there is a lot of repeated logic in the server-side code behind these
5 UI implementations which hinders maintainability even more.
This commit is the first step towards repaying the technical debt: it builds a
system that centralizes as much as possible of the 2FA server-side logic and
UI. The 2 main components of this system are:
1. A dedicated page for 2FA with support for all 3 methods.
2. A reusable server-side class that centralizes the 2FA logic (the
`SecondFactor::AuthManager` class).
From a top-level view, the 2FA flow in this new system looks like this:
1. User initiates an action that requires 2FA;
2. Server is aware that 2FA is required for this action, so it redirects the
user to the 2FA page if the user has a 2FA method, otherwise the action is
performed.
3. User submits the 2FA form on the page;
4. Server validates the 2FA and if it's successful, the action is performed and
the user is redirected to the previous page.
A more technically-detailed explanation/documentation of the new system is
available as a comment at the top of the `lib/second_factor/auth_manager.rb`
file. Please note that the details are not set in stone and will likely change
in the future, so please don't use the system in your plugins yet.
Since this is a new system that needs to be tested, we've decided to migrate
only the 2FA for adding a new admin to the new system at this time (in this
commit). Our plan is to gradually migrate the remaining 2FA implementations to
the new system.
For screenshots of the 2FA page, see PR #15377 on GitHub.
2022-02-17 04:12:59 -05:00
|
|
|
put res["callback_path"], params: {
|
|
|
|
second_factor_nonce: nonce
|
|
|
|
}
|
|
|
|
expect(response.status).to eq(200)
|
2021-09-14 08:19:28 -04:00
|
|
|
expect(another_user.reload.admin).to eq(true)
|
|
|
|
end
|
FEATURE: Centralized 2FA page (#15377)
2FA support in Discourse was added and grown gradually over the years: we first
added support for TOTP for logins, then we implemented backup codes, and last
but not least, security keys. 2FA usage was initially limited to logging in,
but it has been expanded and we now require 2FA for risky actions such as
adding a new admin to the site.
As a result of this gradual growth of the 2FA system, technical debt has
accumulated to the point where it has become difficult to require 2FA for more
actions. We now have 5 different 2FA UI implementations and each one has to
support all 3 2FA methods (TOTP, backup codes, and security keys) which makes
it difficult to maintain a consistent UX for these different implementations.
Moreover, there is a lot of repeated logic in the server-side code behind these
5 UI implementations which hinders maintainability even more.
This commit is the first step towards repaying the technical debt: it builds a
system that centralizes as much as possible of the 2FA server-side logic and
UI. The 2 main components of this system are:
1. A dedicated page for 2FA with support for all 3 methods.
2. A reusable server-side class that centralizes the 2FA logic (the
`SecondFactor::AuthManager` class).
From a top-level view, the 2FA flow in this new system looks like this:
1. User initiates an action that requires 2FA;
2. Server is aware that 2FA is required for this action, so it redirects the
user to the 2FA page if the user has a 2FA method, otherwise the action is
performed.
3. User submits the 2FA form on the page;
4. Server validates the 2FA and if it's successful, the action is performed and
the user is redirected to the previous page.
A more technically-detailed explanation/documentation of the new system is
available as a comment at the top of the `lib/second_factor/auth_manager.rb`
file. Please note that the details are not set in stone and will likely change
in the future, so please don't use the system in your plugins yet.
Since this is a new system that needs to be tested, we've decided to migrate
only the 2FA for adding a new admin to the new system at this time (in this
commit). Our plan is to gradually migrate the remaining 2FA implementations to
the new system.
For screenshots of the 2FA page, see PR #15377 on GitHub.
2022-02-17 04:12:59 -05:00
|
|
|
|
|
|
|
it 'does not grant admin if second factor auth is not successful' do
|
|
|
|
user_second_factor = Fabricate(:user_second_factor_totp, user: admin)
|
|
|
|
|
2022-04-13 08:04:09 -04:00
|
|
|
put "/admin/users/#{another_user.id}/grant_admin.json", xhr: true
|
FEATURE: Centralized 2FA page (#15377)
2FA support in Discourse was added and grown gradually over the years: we first
added support for TOTP for logins, then we implemented backup codes, and last
but not least, security keys. 2FA usage was initially limited to logging in,
but it has been expanded and we now require 2FA for risky actions such as
adding a new admin to the site.
As a result of this gradual growth of the 2FA system, technical debt has
accumulated to the point where it has become difficult to require 2FA for more
actions. We now have 5 different 2FA UI implementations and each one has to
support all 3 2FA methods (TOTP, backup codes, and security keys) which makes
it difficult to maintain a consistent UX for these different implementations.
Moreover, there is a lot of repeated logic in the server-side code behind these
5 UI implementations which hinders maintainability even more.
This commit is the first step towards repaying the technical debt: it builds a
system that centralizes as much as possible of the 2FA server-side logic and
UI. The 2 main components of this system are:
1. A dedicated page for 2FA with support for all 3 methods.
2. A reusable server-side class that centralizes the 2FA logic (the
`SecondFactor::AuthManager` class).
From a top-level view, the 2FA flow in this new system looks like this:
1. User initiates an action that requires 2FA;
2. Server is aware that 2FA is required for this action, so it redirects the
user to the 2FA page if the user has a 2FA method, otherwise the action is
performed.
3. User submits the 2FA form on the page;
4. Server validates the 2FA and if it's successful, the action is performed and
the user is redirected to the previous page.
A more technically-detailed explanation/documentation of the new system is
available as a comment at the top of the `lib/second_factor/auth_manager.rb`
file. Please note that the details are not set in stone and will likely change
in the future, so please don't use the system in your plugins yet.
Since this is a new system that needs to be tested, we've decided to migrate
only the 2FA for adding a new admin to the new system at this time (in this
commit). Our plan is to gradually migrate the remaining 2FA implementations to
the new system.
For screenshots of the 2FA page, see PR #15377 on GitHub.
2022-02-17 04:12:59 -05:00
|
|
|
nonce = response.parsed_body["second_factor_challenge_nonce"]
|
|
|
|
expect(nonce).to be_present
|
|
|
|
expect(another_user.reload.admin).to eq(false)
|
|
|
|
|
|
|
|
token = ROTP::TOTP.new(user_second_factor.data).now.to_i
|
|
|
|
token = (token == 999_999 ? token - 1 : token + 1).to_s
|
|
|
|
post "/session/2fa.json", params: {
|
|
|
|
nonce: nonce,
|
|
|
|
second_factor_token: token,
|
|
|
|
second_factor_method: UserSecondFactor.methods[:totp]
|
|
|
|
}
|
|
|
|
expect(response.status).to eq(400)
|
|
|
|
expect(another_user.reload.admin).to eq(false)
|
|
|
|
|
|
|
|
put "/admin/users/#{another_user.id}/grant_admin.json", params: {
|
|
|
|
second_factor_nonce: nonce
|
|
|
|
}
|
|
|
|
expect(response.status).to eq(401)
|
|
|
|
expect(another_user.reload.admin).to eq(false)
|
|
|
|
end
|
|
|
|
|
|
|
|
it 'does not grant admin if the acting admin loses permission in the middle of the process' do
|
|
|
|
user_second_factor = Fabricate(:user_second_factor_totp, user: admin)
|
|
|
|
|
2022-04-13 08:04:09 -04:00
|
|
|
put "/admin/users/#{another_user.id}/grant_admin.json", xhr: true
|
FEATURE: Centralized 2FA page (#15377)
2FA support in Discourse was added and grown gradually over the years: we first
added support for TOTP for logins, then we implemented backup codes, and last
but not least, security keys. 2FA usage was initially limited to logging in,
but it has been expanded and we now require 2FA for risky actions such as
adding a new admin to the site.
As a result of this gradual growth of the 2FA system, technical debt has
accumulated to the point where it has become difficult to require 2FA for more
actions. We now have 5 different 2FA UI implementations and each one has to
support all 3 2FA methods (TOTP, backup codes, and security keys) which makes
it difficult to maintain a consistent UX for these different implementations.
Moreover, there is a lot of repeated logic in the server-side code behind these
5 UI implementations which hinders maintainability even more.
This commit is the first step towards repaying the technical debt: it builds a
system that centralizes as much as possible of the 2FA server-side logic and
UI. The 2 main components of this system are:
1. A dedicated page for 2FA with support for all 3 methods.
2. A reusable server-side class that centralizes the 2FA logic (the
`SecondFactor::AuthManager` class).
From a top-level view, the 2FA flow in this new system looks like this:
1. User initiates an action that requires 2FA;
2. Server is aware that 2FA is required for this action, so it redirects the
user to the 2FA page if the user has a 2FA method, otherwise the action is
performed.
3. User submits the 2FA form on the page;
4. Server validates the 2FA and if it's successful, the action is performed and
the user is redirected to the previous page.
A more technically-detailed explanation/documentation of the new system is
available as a comment at the top of the `lib/second_factor/auth_manager.rb`
file. Please note that the details are not set in stone and will likely change
in the future, so please don't use the system in your plugins yet.
Since this is a new system that needs to be tested, we've decided to migrate
only the 2FA for adding a new admin to the new system at this time (in this
commit). Our plan is to gradually migrate the remaining 2FA implementations to
the new system.
For screenshots of the 2FA page, see PR #15377 on GitHub.
2022-02-17 04:12:59 -05:00
|
|
|
nonce = response.parsed_body["second_factor_challenge_nonce"]
|
|
|
|
expect(nonce).to be_present
|
|
|
|
expect(another_user.reload.admin).to eq(false)
|
|
|
|
|
|
|
|
post "/session/2fa.json", params: {
|
|
|
|
nonce: nonce,
|
|
|
|
second_factor_token: ROTP::TOTP.new(user_second_factor.data).now,
|
|
|
|
second_factor_method: UserSecondFactor.methods[:totp]
|
|
|
|
}
|
|
|
|
res = response.parsed_body
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
expect(res["ok"]).to eq(true)
|
|
|
|
expect(res["callback_method"]).to eq("PUT")
|
|
|
|
expect(res["callback_path"]).to eq("/admin/users/#{another_user.id}/grant_admin.json")
|
2022-04-13 08:04:09 -04:00
|
|
|
expect(res["redirect_url"]).to eq("/admin/users/#{another_user.id}/#{another_user.username}")
|
FEATURE: Centralized 2FA page (#15377)
2FA support in Discourse was added and grown gradually over the years: we first
added support for TOTP for logins, then we implemented backup codes, and last
but not least, security keys. 2FA usage was initially limited to logging in,
but it has been expanded and we now require 2FA for risky actions such as
adding a new admin to the site.
As a result of this gradual growth of the 2FA system, technical debt has
accumulated to the point where it has become difficult to require 2FA for more
actions. We now have 5 different 2FA UI implementations and each one has to
support all 3 2FA methods (TOTP, backup codes, and security keys) which makes
it difficult to maintain a consistent UX for these different implementations.
Moreover, there is a lot of repeated logic in the server-side code behind these
5 UI implementations which hinders maintainability even more.
This commit is the first step towards repaying the technical debt: it builds a
system that centralizes as much as possible of the 2FA server-side logic and
UI. The 2 main components of this system are:
1. A dedicated page for 2FA with support for all 3 methods.
2. A reusable server-side class that centralizes the 2FA logic (the
`SecondFactor::AuthManager` class).
From a top-level view, the 2FA flow in this new system looks like this:
1. User initiates an action that requires 2FA;
2. Server is aware that 2FA is required for this action, so it redirects the
user to the 2FA page if the user has a 2FA method, otherwise the action is
performed.
3. User submits the 2FA form on the page;
4. Server validates the 2FA and if it's successful, the action is performed and
the user is redirected to the previous page.
A more technically-detailed explanation/documentation of the new system is
available as a comment at the top of the `lib/second_factor/auth_manager.rb`
file. Please note that the details are not set in stone and will likely change
in the future, so please don't use the system in your plugins yet.
Since this is a new system that needs to be tested, we've decided to migrate
only the 2FA for adding a new admin to the new system at this time (in this
commit). Our plan is to gradually migrate the remaining 2FA implementations to
the new system.
For screenshots of the 2FA page, see PR #15377 on GitHub.
2022-02-17 04:12:59 -05:00
|
|
|
expect(another_user.reload.admin).to eq(false)
|
|
|
|
|
|
|
|
admin.update!(admin: false)
|
|
|
|
put res["callback_path"], params: {
|
|
|
|
second_factor_nonce: nonce
|
|
|
|
}
|
|
|
|
expect(response.status).to eq(404)
|
|
|
|
expect(another_user.reload.admin).to eq(false)
|
|
|
|
end
|
|
|
|
|
|
|
|
it 'does not accept backup codes' do
|
|
|
|
Fabricate(:user_second_factor_totp, user: admin)
|
|
|
|
Fabricate(:user_second_factor_backup, user: admin)
|
|
|
|
|
2022-04-13 08:04:09 -04:00
|
|
|
put "/admin/users/#{another_user.id}/grant_admin.json", xhr: true
|
FEATURE: Centralized 2FA page (#15377)
2FA support in Discourse was added and grown gradually over the years: we first
added support for TOTP for logins, then we implemented backup codes, and last
but not least, security keys. 2FA usage was initially limited to logging in,
but it has been expanded and we now require 2FA for risky actions such as
adding a new admin to the site.
As a result of this gradual growth of the 2FA system, technical debt has
accumulated to the point where it has become difficult to require 2FA for more
actions. We now have 5 different 2FA UI implementations and each one has to
support all 3 2FA methods (TOTP, backup codes, and security keys) which makes
it difficult to maintain a consistent UX for these different implementations.
Moreover, there is a lot of repeated logic in the server-side code behind these
5 UI implementations which hinders maintainability even more.
This commit is the first step towards repaying the technical debt: it builds a
system that centralizes as much as possible of the 2FA server-side logic and
UI. The 2 main components of this system are:
1. A dedicated page for 2FA with support for all 3 methods.
2. A reusable server-side class that centralizes the 2FA logic (the
`SecondFactor::AuthManager` class).
From a top-level view, the 2FA flow in this new system looks like this:
1. User initiates an action that requires 2FA;
2. Server is aware that 2FA is required for this action, so it redirects the
user to the 2FA page if the user has a 2FA method, otherwise the action is
performed.
3. User submits the 2FA form on the page;
4. Server validates the 2FA and if it's successful, the action is performed and
the user is redirected to the previous page.
A more technically-detailed explanation/documentation of the new system is
available as a comment at the top of the `lib/second_factor/auth_manager.rb`
file. Please note that the details are not set in stone and will likely change
in the future, so please don't use the system in your plugins yet.
Since this is a new system that needs to be tested, we've decided to migrate
only the 2FA for adding a new admin to the new system at this time (in this
commit). Our plan is to gradually migrate the remaining 2FA implementations to
the new system.
For screenshots of the 2FA page, see PR #15377 on GitHub.
2022-02-17 04:12:59 -05:00
|
|
|
nonce = response.parsed_body["second_factor_challenge_nonce"]
|
|
|
|
expect(nonce).to be_present
|
|
|
|
expect(another_user.reload.admin).to eq(false)
|
|
|
|
|
|
|
|
post "/session/2fa.json", params: {
|
|
|
|
nonce: nonce,
|
|
|
|
second_factor_token: "iAmValidBackupCode",
|
|
|
|
second_factor_method: UserSecondFactor.methods[:backup_codes]
|
|
|
|
}
|
|
|
|
expect(response.status).to eq(403)
|
|
|
|
expect(another_user.reload.admin).to eq(false)
|
|
|
|
end
|
2018-06-08 00:42:06 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
describe '#add_group' do
|
2019-05-06 23:12:20 -04:00
|
|
|
fab!(:group) { Fabricate(:group) }
|
2018-06-08 00:42:06 -04:00
|
|
|
|
|
|
|
it 'adds the user to the group' do
|
|
|
|
post "/admin/users/#{user.id}/groups.json", params: {
|
|
|
|
group_id: group.id
|
|
|
|
}
|
|
|
|
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
expect(GroupUser.where(user_id: user.id, group_id: group.id).exists?).to eq(true)
|
|
|
|
|
|
|
|
group_history = GroupHistory.last
|
|
|
|
|
|
|
|
expect(group_history.action).to eq(GroupHistory.actions[:add_user_to_group])
|
|
|
|
expect(group_history.acting_user).to eq(admin)
|
|
|
|
expect(group_history.target_user).to eq(user)
|
|
|
|
|
|
|
|
# Doing it again doesn't raise an error
|
|
|
|
post "/admin/users/#{user.id}/groups.json", params: {
|
|
|
|
group_id: group.id
|
|
|
|
}
|
|
|
|
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
end
|
2020-04-20 21:50:20 -04:00
|
|
|
|
|
|
|
it 'returns not-found error when there is no group' do
|
|
|
|
group.destroy!
|
|
|
|
|
|
|
|
put "/admin/users/#{user.id}/groups.json", params: {
|
|
|
|
group_id: group.id
|
|
|
|
}
|
|
|
|
|
|
|
|
expect(response.status).to eq(404)
|
|
|
|
end
|
|
|
|
|
|
|
|
it 'does not allow adding users to an automatic group' do
|
|
|
|
group.update!(automatic: true)
|
|
|
|
|
|
|
|
expect do
|
|
|
|
post "/admin/users/#{user.id}/groups.json", params: {
|
|
|
|
group_id: group.id
|
|
|
|
}
|
|
|
|
end.to_not change { group.users.count }
|
|
|
|
|
|
|
|
expect(response.status).to eq(422)
|
|
|
|
expect(response.parsed_body["errors"]).to eq(["You cannot modify an automatic group"])
|
|
|
|
end
|
2018-06-08 00:42:06 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
describe '#remove_group' do
|
|
|
|
it "also clears the user's primary group" do
|
2020-04-20 21:50:20 -04:00
|
|
|
group = Fabricate(:group, users: [user])
|
|
|
|
user.update!(primary_group_id: group.id)
|
|
|
|
delete "/admin/users/#{user.id}/groups/#{group.id}.json"
|
2018-06-08 00:42:06 -04:00
|
|
|
|
|
|
|
expect(response.status).to eq(200)
|
2020-04-20 21:50:20 -04:00
|
|
|
expect(user.reload.primary_group).to eq(nil)
|
|
|
|
end
|
|
|
|
|
|
|
|
it 'returns not-found error when there is no group' do
|
|
|
|
delete "/admin/users/#{user.id}/groups/9090.json"
|
|
|
|
|
|
|
|
expect(response.status).to eq(404)
|
|
|
|
end
|
|
|
|
|
|
|
|
it 'does not allow removing owners from an automatic group' do
|
|
|
|
group = Fabricate(:group, users: [user], automatic: true)
|
|
|
|
|
|
|
|
delete "/admin/users/#{user.id}/groups/#{group.id}.json"
|
|
|
|
|
|
|
|
expect(response.status).to eq(422)
|
|
|
|
expect(response.parsed_body["errors"]).to eq(["You cannot modify an automatic group"])
|
2018-06-08 00:42:06 -04:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
describe '#trust_level' do
|
2021-12-15 12:41:14 -05:00
|
|
|
fab!(:another_user) {
|
|
|
|
coding_horror.update!(created_at: 1.month.ago)
|
|
|
|
coding_horror
|
|
|
|
}
|
2018-06-08 00:42:06 -04:00
|
|
|
|
|
|
|
it "raises an error when the user doesn't have permission" do
|
|
|
|
sign_in(user)
|
|
|
|
put "/admin/users/#{another_user.id}/trust_level.json"
|
|
|
|
expect(response.status).to eq(404)
|
|
|
|
end
|
|
|
|
|
2018-12-14 19:01:35 -05:00
|
|
|
it "returns a 404 if the username doesn't exist" do
|
2018-06-08 00:42:06 -04:00
|
|
|
put "/admin/users/123123/trust_level.json"
|
2018-12-14 19:01:35 -05:00
|
|
|
expect(response.status).to eq(404)
|
2018-06-08 00:42:06 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
it "upgrades the user's trust level" do
|
|
|
|
put "/admin/users/#{another_user.id}/trust_level.json", params: { level: 2 }
|
|
|
|
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
another_user.reload
|
|
|
|
expect(another_user.trust_level).to eq(2)
|
|
|
|
|
|
|
|
expect(UserHistory.where(
|
|
|
|
target_user: another_user,
|
|
|
|
acting_user: admin,
|
|
|
|
action: UserHistory.actions[:change_trust_level]
|
|
|
|
).count).to eq(1)
|
|
|
|
end
|
|
|
|
|
|
|
|
it "raises no error when demoting a user below their current trust level (locks trust level)" do
|
|
|
|
stat = another_user.user_stat
|
|
|
|
stat.topics_entered = SiteSetting.tl1_requires_topics_entered + 1
|
|
|
|
stat.posts_read_count = SiteSetting.tl1_requires_read_posts + 1
|
|
|
|
stat.time_read = SiteSetting.tl1_requires_time_spent_mins * 60
|
|
|
|
stat.save!
|
2019-04-29 03:32:25 -04:00
|
|
|
another_user.update(trust_level: TrustLevel[1])
|
2018-06-08 00:42:06 -04:00
|
|
|
|
|
|
|
put "/admin/users/#{another_user.id}/trust_level.json", params: {
|
|
|
|
level: TrustLevel[0]
|
|
|
|
}
|
|
|
|
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
another_user.reload
|
|
|
|
expect(another_user.trust_level).to eq(TrustLevel[0])
|
|
|
|
expect(another_user.manual_locked_trust_level).to eq(TrustLevel[0])
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
describe '#grant_moderation' do
|
2021-12-15 12:41:14 -05:00
|
|
|
fab!(:another_user) { coding_horror }
|
2018-06-08 00:42:06 -04:00
|
|
|
|
|
|
|
it "raises an error when the user doesn't have permission" do
|
|
|
|
sign_in(user)
|
|
|
|
put "/admin/users/#{another_user.id}/grant_moderation.json"
|
|
|
|
expect(response.status).to eq(404)
|
|
|
|
end
|
|
|
|
|
2018-12-14 19:01:35 -05:00
|
|
|
it "returns a 404 if the username doesn't exist" do
|
2018-06-08 00:42:06 -04:00
|
|
|
put "/admin/users/123123/grant_moderation.json"
|
2018-12-14 19:01:35 -05:00
|
|
|
expect(response.status).to eq(404)
|
2018-06-08 00:42:06 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
it 'updates the moderator flag' do
|
2020-07-24 05:16:52 -04:00
|
|
|
expect_enqueued_with(job: :send_system_message, args: {
|
|
|
|
user_id: another_user.id,
|
|
|
|
message_type: 'welcome_staff',
|
|
|
|
message_options: { role: :moderator }
|
|
|
|
}) do
|
|
|
|
put "/admin/users/#{another_user.id}/grant_moderation.json"
|
|
|
|
end
|
|
|
|
|
2018-06-08 00:42:06 -04:00
|
|
|
expect(response.status).to eq(200)
|
|
|
|
another_user.reload
|
|
|
|
expect(another_user.moderator).to eq(true)
|
|
|
|
end
|
FIX: Revoking admin or moderator status doesn't require refresh to delete/anonymize/merge user (#14073)
* FIX: Revoking admin or moderator status doesn't require refresh to delete/anonymize/merge user
On the /admin/users/<id>/<username> page, there are action buttons that are either visible or hidden depending on a few fields from the AdminDetailsSerializer: `can_be_deleted`, `can_be_anonymized`, `can_be_merged`, `can_delete_all_posts`.
These fields are updated when granting/revoking admin or moderator status. However, those updates were not being reflected on the page. E.g. if a user is granted moderation privileges, the 'anonymize user' and 'merge' buttons still appear on the page, which is inconsistent with the backend state of the user. It requires refreshing the page to update the state.
This commit fixes that issue, by syncing the client model state with the server state when handling a successful response from the server. Now, when revoking privileges, the buttons automatically appear without refreshing the page. Similarly, when granting moderator privileges, the buttons automatically disappear without refreshing the page.
* Add detailed user response to spec for changed routes.
Add tests to verify that the revoke_moderation, grant_moderation, and revoke_admin routes return a response formatted according to the AdminDetailedUserSerializer.
2021-08-18 21:57:16 -04:00
|
|
|
|
|
|
|
it 'returns detailed user schema' do
|
|
|
|
put "/admin/users/#{another_user.id}/grant_moderation.json"
|
|
|
|
expect(response.parsed_body['can_be_merged']).to eq(false)
|
|
|
|
expect(response.parsed_body['can_be_anonymized']).to eq(false)
|
|
|
|
end
|
2018-06-08 00:42:06 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
describe '#revoke_moderation' do
|
2019-05-06 23:12:20 -04:00
|
|
|
fab!(:moderator) { Fabricate(:moderator) }
|
2018-06-08 00:42:06 -04:00
|
|
|
|
|
|
|
it 'raises an error unless the user can revoke access' do
|
|
|
|
sign_in(user)
|
|
|
|
put "/admin/users/#{moderator.id}/revoke_moderation.json"
|
|
|
|
expect(response.status).to eq(404)
|
|
|
|
moderator.reload
|
|
|
|
expect(moderator.moderator).to eq(true)
|
|
|
|
end
|
|
|
|
|
|
|
|
it 'updates the moderator flag' do
|
|
|
|
put "/admin/users/#{moderator.id}/revoke_moderation.json"
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
moderator.reload
|
|
|
|
expect(moderator.moderator).to eq(false)
|
|
|
|
end
|
FIX: Revoking admin or moderator status doesn't require refresh to delete/anonymize/merge user (#14073)
* FIX: Revoking admin or moderator status doesn't require refresh to delete/anonymize/merge user
On the /admin/users/<id>/<username> page, there are action buttons that are either visible or hidden depending on a few fields from the AdminDetailsSerializer: `can_be_deleted`, `can_be_anonymized`, `can_be_merged`, `can_delete_all_posts`.
These fields are updated when granting/revoking admin or moderator status. However, those updates were not being reflected on the page. E.g. if a user is granted moderation privileges, the 'anonymize user' and 'merge' buttons still appear on the page, which is inconsistent with the backend state of the user. It requires refreshing the page to update the state.
This commit fixes that issue, by syncing the client model state with the server state when handling a successful response from the server. Now, when revoking privileges, the buttons automatically appear without refreshing the page. Similarly, when granting moderator privileges, the buttons automatically disappear without refreshing the page.
* Add detailed user response to spec for changed routes.
Add tests to verify that the revoke_moderation, grant_moderation, and revoke_admin routes return a response formatted according to the AdminDetailedUserSerializer.
2021-08-18 21:57:16 -04:00
|
|
|
|
|
|
|
it 'returns detailed user schema' do
|
|
|
|
put "/admin/users/#{moderator.id}/revoke_moderation.json"
|
|
|
|
expect(response.parsed_body['can_be_merged']).to eq(true)
|
|
|
|
expect(response.parsed_body['can_be_anonymized']).to eq(true)
|
|
|
|
end
|
2018-06-08 00:42:06 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
describe '#primary_group' do
|
2019-05-06 23:12:20 -04:00
|
|
|
fab!(:group) { Fabricate(:group) }
|
2021-12-15 12:41:14 -05:00
|
|
|
fab!(:another_user) { coding_horror }
|
2019-05-06 23:12:20 -04:00
|
|
|
fab!(:another_group) { Fabricate(:group, title: 'New') }
|
2018-06-08 00:42:06 -04:00
|
|
|
|
|
|
|
it "raises an error when the user doesn't have permission" do
|
|
|
|
sign_in(user)
|
|
|
|
put "/admin/users/#{another_user.id}/primary_group.json"
|
|
|
|
expect(response.status).to eq(404)
|
|
|
|
another_user.reload
|
|
|
|
expect(another_user.primary_group_id).to eq(nil)
|
|
|
|
end
|
|
|
|
|
|
|
|
it "returns a 404 if the user doesn't exist" do
|
|
|
|
put "/admin/users/123123/primary_group.json"
|
2018-12-14 19:01:35 -05:00
|
|
|
expect(response.status).to eq(404)
|
2018-06-08 00:42:06 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
it "changes the user's primary group" do
|
|
|
|
group.add(another_user)
|
|
|
|
put "/admin/users/#{another_user.id}/primary_group.json", params: {
|
|
|
|
primary_group_id: group.id
|
|
|
|
}
|
|
|
|
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
another_user.reload
|
|
|
|
expect(another_user.primary_group_id).to eq(group.id)
|
|
|
|
end
|
|
|
|
|
|
|
|
it "doesn't change primary group if they aren't a member of the group" do
|
|
|
|
put "/admin/users/#{another_user.id}/primary_group.json", params: {
|
|
|
|
primary_group_id: group.id
|
|
|
|
}
|
|
|
|
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
another_user.reload
|
|
|
|
expect(another_user.primary_group_id).to eq(nil)
|
|
|
|
end
|
|
|
|
|
|
|
|
it "remove user's primary group" do
|
|
|
|
group.add(another_user)
|
|
|
|
|
|
|
|
put "/admin/users/#{another_user.id}/primary_group.json", params: {
|
|
|
|
primary_group_id: ""
|
|
|
|
}
|
|
|
|
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
another_user.reload
|
|
|
|
expect(another_user.primary_group_id).to eq(nil)
|
|
|
|
end
|
2018-09-17 01:08:39 -04:00
|
|
|
|
|
|
|
it "updates user's title when it matches the previous primary group title" do
|
|
|
|
group.update_columns(primary_group: true, title: 'Previous')
|
|
|
|
group.add(another_user)
|
|
|
|
another_group.add(another_user)
|
|
|
|
|
|
|
|
expect(another_user.reload.title).to eq('Previous')
|
|
|
|
|
|
|
|
put "/admin/users/#{another_user.id}/primary_group.json", params: {
|
|
|
|
primary_group_id: another_group.id
|
|
|
|
}
|
|
|
|
|
|
|
|
another_user.reload
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
expect(another_user.primary_group_id).to eq(another_group.id)
|
|
|
|
expect(another_user.title).to eq('New')
|
|
|
|
end
|
|
|
|
|
|
|
|
it "doesn't update user's title when it does not match the previous primary group title" do
|
|
|
|
another_user.update_columns(title: 'Different')
|
|
|
|
group.update_columns(primary_group: true, title: 'Previous')
|
|
|
|
another_group.add(another_user)
|
|
|
|
group.add(another_user)
|
|
|
|
|
|
|
|
expect(another_user.reload.title).to eq('Different')
|
|
|
|
|
|
|
|
put "/admin/users/#{another_user.id}/primary_group.json", params: {
|
|
|
|
primary_group_id: another_group.id
|
|
|
|
}
|
|
|
|
|
|
|
|
another_user.reload
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
expect(another_user.primary_group_id).to eq(another_group.id)
|
|
|
|
expect(another_user.title).to eq('Different')
|
|
|
|
end
|
2018-06-08 00:42:06 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
describe '#destroy' do
|
2019-05-06 23:12:20 -04:00
|
|
|
fab!(:delete_me) { Fabricate(:user) }
|
2018-06-08 00:42:06 -04:00
|
|
|
|
|
|
|
it "returns a 403 if the user doesn't exist" do
|
|
|
|
delete "/admin/users/123123drink.json"
|
|
|
|
expect(response.status).to eq(403)
|
|
|
|
end
|
|
|
|
|
|
|
|
context "user has post" do
|
|
|
|
let(:topic) { Fabricate(:topic, user: delete_me) }
|
|
|
|
let!(:post) { Fabricate(:post, topic: topic, user: delete_me) }
|
|
|
|
|
|
|
|
it "returns an api response that the user can't be deleted because it has posts" do
|
2021-06-11 01:07:34 -04:00
|
|
|
post_count = delete_me.posts.joins(:topic).count
|
|
|
|
delete_me_topic = Fabricate(:topic)
|
|
|
|
Fabricate(:post, topic: delete_me_topic, user: delete_me)
|
|
|
|
PostDestroyer.new(admin, delete_me_topic.first_post, context: "Deleted by admin").destroy
|
|
|
|
|
2018-06-08 00:42:06 -04:00
|
|
|
delete "/admin/users/#{delete_me.id}.json"
|
|
|
|
expect(response.status).to eq(403)
|
2020-05-07 11:04:12 -04:00
|
|
|
json = response.parsed_body
|
2018-06-08 00:42:06 -04:00
|
|
|
expect(json['deleted']).to eq(false)
|
2021-06-22 05:29:35 -04:00
|
|
|
expect(json['message']).to eq(I18n.t("user.cannot_delete_has_posts", username: delete_me.username, count: post_count))
|
2018-06-08 00:42:06 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
it "doesn't return an error if delete_posts == true" do
|
|
|
|
delete "/admin/users/#{delete_me.id}.json", params: { delete_posts: true }
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
expect(Post.where(id: post.id).count).to eq(0)
|
|
|
|
expect(Topic.where(id: topic.id).count).to eq(0)
|
|
|
|
expect(User.where(id: delete_me.id).count).to eq(0)
|
|
|
|
end
|
2021-09-06 02:11:44 -04:00
|
|
|
|
|
|
|
context "user has reviewable flagged post which was handled" do
|
|
|
|
let!(:reviewable) { Fabricate(:reviewable_flagged_post, created_by: admin, target_created_by: delete_me, target: post, topic: topic, status: 4) }
|
|
|
|
|
|
|
|
it "deletes the user record" do
|
|
|
|
delete "/admin/users/#{delete_me.id}.json", params: { delete_posts: true, delete_as_spammer: true }
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
expect(User.where(id: delete_me.id).count).to eq(0)
|
|
|
|
end
|
|
|
|
end
|
2018-06-08 00:42:06 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
it "deletes the user record" do
|
|
|
|
delete "/admin/users/#{delete_me.id}.json"
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
expect(User.where(id: delete_me.id).count).to eq(0)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
describe '#activate' do
|
2019-05-06 23:12:20 -04:00
|
|
|
fab!(:reg_user) { Fabricate(:inactive_user) }
|
2018-06-08 00:42:06 -04:00
|
|
|
|
|
|
|
it "returns success" do
|
|
|
|
put "/admin/users/#{reg_user.id}/activate.json"
|
|
|
|
expect(response.status).to eq(200)
|
2020-05-07 11:04:12 -04:00
|
|
|
json = response.parsed_body
|
2018-06-08 00:42:06 -04:00
|
|
|
expect(json['success']).to eq("OK")
|
|
|
|
reg_user.reload
|
|
|
|
expect(reg_user.active).to eq(true)
|
|
|
|
end
|
|
|
|
|
|
|
|
it "should confirm email even when the tokens are expired" do
|
|
|
|
reg_user.email_tokens.update_all(confirmed: false, expired: true)
|
|
|
|
|
|
|
|
reg_user.reload
|
|
|
|
expect(reg_user.email_confirmed?).to eq(false)
|
|
|
|
|
|
|
|
put "/admin/users/#{reg_user.id}/activate.json"
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
|
|
|
|
reg_user.reload
|
|
|
|
expect(reg_user.email_confirmed?).to eq(true)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2019-12-30 10:14:29 -05:00
|
|
|
describe '#deactivate' do
|
|
|
|
fab!(:reg_user) { Fabricate(:active_user) }
|
|
|
|
|
|
|
|
it "returns success" do
|
|
|
|
put "/admin/users/#{reg_user.id}/deactivate.json"
|
|
|
|
expect(response.status).to eq(200)
|
2020-05-07 11:04:12 -04:00
|
|
|
json = response.parsed_body
|
2019-12-30 10:14:29 -05:00
|
|
|
expect(json['success']).to eq("OK")
|
|
|
|
reg_user.reload
|
|
|
|
expect(reg_user.active).to eq(false)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2018-06-08 00:42:06 -04:00
|
|
|
describe '#log_out' do
|
2019-05-06 23:12:20 -04:00
|
|
|
fab!(:reg_user) { Fabricate(:user) }
|
2018-06-08 00:42:06 -04:00
|
|
|
|
|
|
|
it "returns success" do
|
|
|
|
post "/admin/users/#{reg_user.id}/log_out.json"
|
|
|
|
expect(response.status).to eq(200)
|
2020-05-07 11:04:12 -04:00
|
|
|
json = response.parsed_body
|
2018-06-08 00:42:06 -04:00
|
|
|
expect(json['success']).to eq("OK")
|
|
|
|
end
|
|
|
|
|
|
|
|
it "returns 404 when user_id does not exist" do
|
|
|
|
post "/admin/users/123123drink/log_out.json"
|
|
|
|
expect(response.status).to eq(404)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
describe '#silence' do
|
2019-05-06 23:12:20 -04:00
|
|
|
fab!(:reg_user) { Fabricate(:user) }
|
2018-06-08 00:42:06 -04:00
|
|
|
|
|
|
|
it "raises an error when the user doesn't have permission" do
|
|
|
|
sign_in(user)
|
|
|
|
put "/admin/users/#{reg_user.id}/silence.json"
|
|
|
|
expect(response.status).to eq(404)
|
|
|
|
reg_user.reload
|
|
|
|
expect(reg_user).not_to be_silenced
|
|
|
|
end
|
|
|
|
|
2018-12-14 19:01:35 -05:00
|
|
|
it "returns a 404 if the user doesn't exist" do
|
2018-06-08 00:42:06 -04:00
|
|
|
put "/admin/users/123123/silence.json"
|
2018-12-14 19:01:35 -05:00
|
|
|
expect(response.status).to eq(404)
|
2018-06-08 00:42:06 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
it "punishes the user for spamming" do
|
|
|
|
put "/admin/users/#{reg_user.id}/silence.json"
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
reg_user.reload
|
|
|
|
expect(reg_user).to be_silenced
|
|
|
|
end
|
|
|
|
|
|
|
|
it "can have an associated post" do
|
|
|
|
silence_post = Fabricate(:post, user: reg_user)
|
|
|
|
|
|
|
|
put "/admin/users/#{reg_user.id}/silence.json", params: {
|
|
|
|
post_id: silence_post.id,
|
|
|
|
post_action: 'edit',
|
|
|
|
post_edit: "this is the new contents for the post"
|
|
|
|
}
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
|
|
|
|
silence_post.reload
|
|
|
|
expect(silence_post.raw).to eq("this is the new contents for the post")
|
|
|
|
|
|
|
|
log = UserHistory.where(
|
|
|
|
target_user_id: reg_user.id,
|
|
|
|
action: UserHistory.actions[:silence_user]
|
|
|
|
).first
|
|
|
|
expect(log).to be_present
|
|
|
|
expect(log.post_id).to eq(silence_post.id)
|
|
|
|
|
|
|
|
reg_user.reload
|
|
|
|
expect(reg_user).to be_silenced
|
|
|
|
end
|
|
|
|
|
|
|
|
it "will set a length of time if provided" do
|
|
|
|
future_date = 1.month.from_now.to_date
|
|
|
|
put "/admin/users/#{reg_user.id}/silence.json", params: {
|
|
|
|
silenced_till: future_date
|
|
|
|
}
|
|
|
|
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
reg_user.reload
|
|
|
|
expect(reg_user).to be_silenced
|
|
|
|
expect(reg_user.silenced_till).to eq(future_date)
|
|
|
|
end
|
|
|
|
|
|
|
|
it "will send a message if provided" do
|
|
|
|
expect do
|
|
|
|
put "/admin/users/#{reg_user.id}/silence.json", params: {
|
|
|
|
message: "Email this to the user"
|
|
|
|
}
|
|
|
|
end.to change { Jobs::CriticalUserEmail.jobs.size }.by(1)
|
|
|
|
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
reg_user.reload
|
|
|
|
expect(reg_user).to be_silenced
|
|
|
|
end
|
2020-11-03 10:38:56 -05:00
|
|
|
|
|
|
|
it "checks if user is silenced" do
|
|
|
|
put "/admin/users/#{user.id}/silence.json", params: {
|
|
|
|
silenced_till: 5.hours.from_now,
|
|
|
|
reason: "because I said so"
|
|
|
|
}
|
|
|
|
|
|
|
|
put "/admin/users/#{user.id}/silence.json", params: {
|
|
|
|
silenced_till: 5.hours.from_now,
|
|
|
|
reason: "because I said so too"
|
|
|
|
}
|
|
|
|
|
|
|
|
expect(response.status).to eq(409)
|
|
|
|
expect(response.parsed_body["message"]).to eq(
|
|
|
|
I18n.t(
|
|
|
|
"user.already_silenced",
|
|
|
|
staff: admin.username,
|
|
|
|
time_ago: FreedomPatches::Rails4.time_ago_in_words(user.silenced_record.created_at, true, scope: :'datetime.distance_in_words_verbose')
|
|
|
|
)
|
|
|
|
)
|
|
|
|
end
|
2018-06-08 00:42:06 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
describe '#unsilence' do
|
2019-05-06 23:12:20 -04:00
|
|
|
fab!(:reg_user) { Fabricate(:user, silenced_till: 10.years.from_now) }
|
2018-06-08 00:42:06 -04:00
|
|
|
|
|
|
|
it "raises an error when the user doesn't have permission" do
|
|
|
|
sign_in(user)
|
|
|
|
put "/admin/users/#{reg_user.id}/unsilence.json"
|
|
|
|
expect(response.status).to eq(404)
|
|
|
|
end
|
|
|
|
|
|
|
|
it "returns a 403 if the user doesn't exist" do
|
|
|
|
put "/admin/users/123123/unsilence.json"
|
2018-12-14 19:01:35 -05:00
|
|
|
expect(response.status).to eq(404)
|
2018-06-08 00:42:06 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
it "unsilences the user" do
|
|
|
|
put "/admin/users/#{reg_user.id}/unsilence.json"
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
reg_user.reload
|
|
|
|
expect(reg_user.silenced?).to eq(false)
|
|
|
|
log = UserHistory.where(
|
|
|
|
target_user_id: reg_user.id,
|
|
|
|
action: UserHistory.actions[:unsilence_user]
|
|
|
|
).first
|
|
|
|
expect(log).to be_present
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
describe '#ip_info' do
|
2018-10-30 18:08:57 -04:00
|
|
|
it "retrieves IP info" do
|
|
|
|
ip = "81.2.69.142"
|
|
|
|
|
|
|
|
DiscourseIpInfo.open_db(File.join(Rails.root, 'spec', 'fixtures', 'mmdb'))
|
|
|
|
Resolv::DNS.any_instance.stubs(:getname).with(ip).returns("ip-81-2-69-142.example.com")
|
2018-06-08 00:42:06 -04:00
|
|
|
|
|
|
|
get "/admin/users/ip-info.json", params: { ip: ip }
|
|
|
|
expect(response.status).to eq(200)
|
2020-05-07 11:04:12 -04:00
|
|
|
expect(response.parsed_body.symbolize_keys).to eq(
|
2018-10-30 18:08:57 -04:00
|
|
|
city: "London",
|
|
|
|
country: "United Kingdom",
|
|
|
|
country_code: "GB",
|
2022-03-02 16:51:42 -05:00
|
|
|
geoname_ids: [6255148, 2635167, 2643743, 6269131],
|
2018-10-30 18:08:57 -04:00
|
|
|
hostname: "ip-81-2-69-142.example.com",
|
|
|
|
location: "London, England, United Kingdom",
|
|
|
|
region: "England",
|
|
|
|
latitude: 51.5142,
|
|
|
|
longitude: -0.0931,
|
|
|
|
)
|
2018-06-08 00:42:06 -04:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
describe '#delete_other_accounts_with_same_ip' do
|
|
|
|
it "works" do
|
|
|
|
user_a = Fabricate(:user, ip_address: "42.42.42.42")
|
|
|
|
user_b = Fabricate(:user, ip_address: "42.42.42.42")
|
|
|
|
|
|
|
|
delete "/admin/users/delete-others-with-same-ip.json", params: {
|
|
|
|
ip: "42.42.42.42", exclude: -1, order: "trust_level DESC"
|
|
|
|
}
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
expect(User.where(id: user_a.id).count).to eq(0)
|
|
|
|
expect(User.where(id: user_b.id).count).to eq(0)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
describe '#sync_sso' do
|
2022-01-06 07:28:46 -05:00
|
|
|
let(:sso) { DiscourseConnectBase.new }
|
2018-06-08 00:42:06 -04:00
|
|
|
let(:sso_secret) { "sso secret" }
|
|
|
|
|
|
|
|
before do
|
|
|
|
SiteSetting.email_editable = false
|
2021-02-08 05:04:33 -05:00
|
|
|
SiteSetting.discourse_connect_url = "https://www.example.com/sso"
|
|
|
|
SiteSetting.enable_discourse_connect = true
|
|
|
|
SiteSetting.auth_overrides_email = true
|
|
|
|
SiteSetting.auth_overrides_name = true
|
|
|
|
SiteSetting.auth_overrides_username = true
|
|
|
|
SiteSetting.discourse_connect_secret = sso_secret
|
2018-06-08 00:42:06 -04:00
|
|
|
sso.sso_secret = sso_secret
|
|
|
|
end
|
|
|
|
|
|
|
|
it 'can sync up with the sso' do
|
|
|
|
sso.name = "Bob The Bob"
|
|
|
|
sso.username = "bob"
|
|
|
|
sso.email = "bob@bob.com"
|
|
|
|
sso.external_id = "1"
|
|
|
|
|
2022-01-06 07:28:46 -05:00
|
|
|
user = DiscourseConnect.parse(sso.payload, secure_session: read_secure_session).lookup_or_create_user
|
2018-06-08 00:42:06 -04:00
|
|
|
|
|
|
|
sso.name = "Bill"
|
|
|
|
sso.username = "Hokli$$!!"
|
|
|
|
sso.email = "bob2@bob.com"
|
|
|
|
|
|
|
|
post "/admin/users/sync_sso.json", params: Rack::Utils.parse_query(sso.payload)
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
|
|
|
|
user.reload
|
|
|
|
expect(user.email).to eq("bob2@bob.com")
|
|
|
|
expect(user.name).to eq("Bill")
|
|
|
|
expect(user.username).to eq("Hokli")
|
|
|
|
end
|
|
|
|
|
|
|
|
it 'should create new users' do
|
|
|
|
sso.name = "Dr. Claw"
|
|
|
|
sso.username = "dr_claw"
|
|
|
|
sso.email = "dr@claw.com"
|
|
|
|
sso.external_id = "2"
|
|
|
|
post "/admin/users/sync_sso.json", params: Rack::Utils.parse_query(sso.payload)
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
|
|
|
|
user = User.find_by_email('dr@claw.com')
|
|
|
|
expect(user).to be_present
|
|
|
|
expect(user.ip_address).to be_blank
|
|
|
|
end
|
|
|
|
|
2022-03-30 15:22:22 -04:00
|
|
|
it "triggers :sync_sso DiscourseEvent" do
|
|
|
|
sso.name = "Bob The Bob"
|
|
|
|
sso.username = "bob"
|
|
|
|
sso.email = "bob@bob.com"
|
|
|
|
sso.external_id = "1"
|
|
|
|
|
|
|
|
user = DiscourseConnect.parse(sso.payload, secure_session: read_secure_session).lookup_or_create_user
|
|
|
|
|
|
|
|
sso.name = "Bill"
|
|
|
|
sso.username = "Hokli$$!!"
|
|
|
|
sso.email = "bob2@bob.com"
|
|
|
|
|
|
|
|
events = DiscourseEvent.track_events do
|
|
|
|
post "/admin/users/sync_sso.json", params: Rack::Utils.parse_query(sso.payload)
|
|
|
|
end
|
|
|
|
expect(events).to include(event_name: :sync_sso, params: [user])
|
|
|
|
end
|
|
|
|
|
2018-06-08 00:42:06 -04:00
|
|
|
it 'should return the right message if the record is invalid' do
|
|
|
|
sso.email = ""
|
|
|
|
sso.name = ""
|
|
|
|
sso.external_id = "1"
|
|
|
|
|
|
|
|
post "/admin/users/sync_sso.json", params: Rack::Utils.parse_query(sso.payload)
|
|
|
|
expect(response.status).to eq(403)
|
2020-05-07 11:04:12 -04:00
|
|
|
expect(response.parsed_body["message"]).to include("Primary email can't be blank")
|
2018-06-08 00:42:06 -04:00
|
|
|
end
|
2018-12-07 10:01:44 -05:00
|
|
|
|
|
|
|
it 'should return the right message if the signature is invalid' do
|
|
|
|
sso.name = "Dr. Claw"
|
|
|
|
sso.username = "dr_claw"
|
|
|
|
sso.email = "dr@claw.com"
|
|
|
|
sso.external_id = "2"
|
|
|
|
|
|
|
|
correct_payload = Rack::Utils.parse_query(sso.payload)
|
|
|
|
post "/admin/users/sync_sso.json", params: correct_payload.merge(sig: "someincorrectsignature")
|
|
|
|
expect(response.status).to eq(422)
|
2021-02-08 05:04:33 -05:00
|
|
|
expect(response.parsed_body["message"]).to include(I18n.t('discourse_connect.login_error'))
|
2020-05-07 11:04:12 -04:00
|
|
|
expect(response.parsed_body["message"]).not_to include(correct_payload["sig"])
|
2018-12-07 10:01:44 -05:00
|
|
|
end
|
2020-01-08 11:47:01 -05:00
|
|
|
|
|
|
|
it "returns 404 if the external id does not exist" do
|
|
|
|
sso.name = "Dr. Claw"
|
|
|
|
sso.username = "dr_claw"
|
|
|
|
sso.email = "dr@claw.com"
|
|
|
|
sso.external_id = ""
|
|
|
|
post "/admin/users/sync_sso.json", params: Rack::Utils.parse_query(sso.payload)
|
|
|
|
expect(response.status).to eq(422)
|
2021-02-08 05:04:33 -05:00
|
|
|
expect(response.parsed_body["message"]).to include(I18n.t('discourse_connect.blank_id_error'))
|
2020-01-08 11:47:01 -05:00
|
|
|
end
|
2018-06-08 00:42:06 -04:00
|
|
|
end
|
|
|
|
|
2018-02-20 01:44:51 -05:00
|
|
|
describe '#disable_second_factor' do
|
2019-06-26 19:58:06 -04:00
|
|
|
let(:second_factor) { user.create_totp(enabled: true) }
|
2018-06-28 04:12:32 -04:00
|
|
|
let(:second_factor_backup) { user.generate_backup_codes }
|
2020-07-07 15:19:30 -04:00
|
|
|
let(:security_key) { Fabricate(:user_security_key, user: user) }
|
2018-02-20 01:44:51 -05:00
|
|
|
|
|
|
|
describe 'as an admin' do
|
|
|
|
before do
|
|
|
|
sign_in(admin)
|
|
|
|
second_factor
|
2018-06-28 04:12:32 -04:00
|
|
|
second_factor_backup
|
2020-07-07 15:19:30 -04:00
|
|
|
security_key
|
2019-06-26 19:58:06 -04:00
|
|
|
expect(user.reload.user_second_factors.totps.first).to eq(second_factor)
|
2018-02-20 01:44:51 -05:00
|
|
|
end
|
|
|
|
|
|
|
|
it 'should able to disable the second factor for another user' do
|
|
|
|
expect do
|
|
|
|
put "/admin/users/#{user.id}/disable_second_factor.json"
|
|
|
|
end.to change { Jobs::CriticalUserEmail.jobs.length }.by(1)
|
|
|
|
|
|
|
|
expect(response.status).to eq(200)
|
2018-06-28 04:12:32 -04:00
|
|
|
expect(user.reload.user_second_factors).to be_empty
|
2020-07-07 15:19:30 -04:00
|
|
|
expect(user.reload.security_keys).to be_empty
|
2018-02-20 01:44:51 -05:00
|
|
|
|
|
|
|
job_args = Jobs::CriticalUserEmail.jobs.first["args"].first
|
|
|
|
|
|
|
|
expect(job_args["user_id"]).to eq(user.id)
|
|
|
|
expect(job_args["type"]).to eq('account_second_factor_disabled')
|
|
|
|
end
|
|
|
|
|
|
|
|
it 'should not be able to disable the second factor for the current user' do
|
|
|
|
put "/admin/users/#{admin.id}/disable_second_factor.json"
|
|
|
|
|
|
|
|
expect(response.status).to eq(403)
|
|
|
|
end
|
|
|
|
|
2020-07-07 15:19:30 -04:00
|
|
|
describe 'when user has only one second factor type enabled' do
|
|
|
|
it 'should succeed with security keys' do
|
|
|
|
user.user_second_factors.destroy_all
|
|
|
|
|
|
|
|
put "/admin/users/#{user.id}/disable_second_factor.json"
|
|
|
|
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
end
|
|
|
|
it 'should succeed with totp' do
|
|
|
|
user.security_keys.destroy_all
|
|
|
|
|
|
|
|
put "/admin/users/#{user.id}/disable_second_factor.json"
|
|
|
|
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2018-02-20 01:44:51 -05:00
|
|
|
describe 'when user does not have second factor enabled' do
|
|
|
|
it 'should raise the right error' do
|
2018-06-28 04:12:32 -04:00
|
|
|
user.user_second_factors.destroy_all
|
2020-07-07 15:19:30 -04:00
|
|
|
user.security_keys.destroy_all
|
2018-02-20 01:44:51 -05:00
|
|
|
|
|
|
|
put "/admin/users/#{user.id}/disable_second_factor.json"
|
|
|
|
|
|
|
|
expect(response.status).to eq(400)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
2018-05-25 11:45:42 -04:00
|
|
|
|
|
|
|
describe "#penalty_history" do
|
2019-05-06 23:12:20 -04:00
|
|
|
fab!(:moderator) { Fabricate(:moderator) }
|
2018-05-25 11:45:42 -04:00
|
|
|
let(:logger) { StaffActionLogger.new(admin) }
|
|
|
|
|
|
|
|
it "doesn't allow moderators to clear a user's history" do
|
|
|
|
sign_in(moderator)
|
|
|
|
delete "/admin/users/#{user.id}/penalty_history.json"
|
|
|
|
expect(response.code).to eq("404")
|
|
|
|
end
|
|
|
|
|
|
|
|
def find_logs(action)
|
|
|
|
UserHistory.where(target_user_id: user.id, action: UserHistory.actions[action])
|
|
|
|
end
|
|
|
|
|
|
|
|
it "allows admins to clear a user's history" do
|
|
|
|
logger.log_user_suspend(user, "suspend reason")
|
|
|
|
logger.log_user_unsuspend(user)
|
|
|
|
logger.log_unsilence_user(user)
|
|
|
|
logger.log_silence_user(user)
|
|
|
|
|
|
|
|
sign_in(admin)
|
|
|
|
delete "/admin/users/#{user.id}/penalty_history.json"
|
|
|
|
expect(response.code).to eq("200")
|
|
|
|
|
|
|
|
expect(find_logs(:suspend_user)).to be_blank
|
|
|
|
expect(find_logs(:unsuspend_user)).to be_blank
|
|
|
|
expect(find_logs(:silence_user)).to be_blank
|
|
|
|
expect(find_logs(:unsilence_user)).to be_blank
|
|
|
|
|
|
|
|
expect(find_logs(:removed_suspend_user)).to be_present
|
|
|
|
expect(find_logs(:removed_unsuspend_user)).to be_present
|
|
|
|
expect(find_logs(:removed_silence_user)).to be_present
|
|
|
|
expect(find_logs(:removed_unsilence_user)).to be_present
|
|
|
|
end
|
|
|
|
|
|
|
|
end
|
|
|
|
|
2018-12-14 05:04:18 -05:00
|
|
|
describe "#delete_posts_batch" do
|
2018-12-14 19:01:35 -05:00
|
|
|
describe 'when user is is invalid' do
|
|
|
|
it 'should return the right response' do
|
|
|
|
put "/admin/users/nothing/delete_posts_batch.json"
|
|
|
|
|
|
|
|
expect(response.status).to eq(404)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2018-12-14 05:04:18 -05:00
|
|
|
context "when there are user posts" do
|
|
|
|
before do
|
|
|
|
post = Fabricate(:post, user: user)
|
|
|
|
Fabricate(:post, topic: post.topic, user: user)
|
|
|
|
Fabricate(:post, user: user)
|
|
|
|
end
|
|
|
|
|
|
|
|
it 'returns how many posts were deleted' do
|
|
|
|
put "/admin/users/#{user.id}/delete_posts_batch.json"
|
|
|
|
expect(response.status).to eq(200)
|
2020-05-07 11:04:12 -04:00
|
|
|
expect(response.parsed_body["posts_deleted"]).to eq(3)
|
2018-12-14 05:04:18 -05:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
context "when there are no posts left to be deleted" do
|
|
|
|
it "returns correct json" do
|
|
|
|
put "/admin/users/#{user.id}/delete_posts_batch.json"
|
|
|
|
expect(response.status).to eq(200)
|
2020-05-07 11:04:12 -04:00
|
|
|
expect(response.parsed_body["posts_deleted"]).to eq(0)
|
2018-12-14 05:04:18 -05:00
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2020-04-22 04:37:51 -04:00
|
|
|
describe "#merge" do
|
|
|
|
fab!(:target_user) { Fabricate(:user) }
|
|
|
|
fab!(:topic) { Fabricate(:topic, user: user) }
|
|
|
|
fab!(:first_post) { Fabricate(:post, topic: topic, user: user) }
|
|
|
|
|
|
|
|
it 'should merge source user to target user' do
|
2020-12-09 23:52:08 -05:00
|
|
|
Jobs.run_immediately!
|
2020-04-22 04:37:51 -04:00
|
|
|
post "/admin/users/#{user.id}/merge.json", params: {
|
|
|
|
target_username: target_user.username
|
|
|
|
}
|
|
|
|
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
expect(topic.reload.user_id).to eq(target_user.id)
|
|
|
|
expect(first_post.reload.user_id).to eq(target_user.id)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2020-09-15 10:00:10 -04:00
|
|
|
describe '#sso_record' do
|
|
|
|
fab!(:sso_record) { SingleSignOnRecord.create!(user_id: user.id, external_id: '12345', external_email: user.email, last_payload: '') }
|
|
|
|
|
|
|
|
it "deletes the record" do
|
2021-02-08 05:04:33 -05:00
|
|
|
SiteSetting.discourse_connect_url = "https://www.example.com/sso"
|
|
|
|
SiteSetting.enable_discourse_connect = true
|
2020-09-15 10:00:10 -04:00
|
|
|
|
|
|
|
delete "/admin/users/#{user.id}/sso_record.json"
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
expect(user.single_sign_on_record).to eq(nil)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2020-12-15 15:48:16 -05:00
|
|
|
describe "#anonymize" do
|
|
|
|
it "will make the user anonymous" do
|
|
|
|
put "/admin/users/#{user.id}/anonymize.json"
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
expect(response.parsed_body['username']).to be_present
|
|
|
|
end
|
|
|
|
|
|
|
|
it "supports `anonymize_ip`" do
|
|
|
|
Jobs.run_immediately!
|
|
|
|
sl = Fabricate(:search_log, user_id: user.id)
|
|
|
|
put "/admin/users/#{user.id}/anonymize.json?anonymize_ip=127.0.0.2"
|
|
|
|
expect(response.status).to eq(200)
|
|
|
|
expect(response.parsed_body['username']).to be_present
|
|
|
|
expect(sl.reload.ip_address).to eq('127.0.0.2')
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2018-02-20 01:44:51 -05:00
|
|
|
end
|