discourse/lib/guardian/user_guardian.rb

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

224 lines
6.0 KiB
Ruby
Raw Normal View History

# frozen_string_literal: true
# mixin for all Guardian methods dealing with user permissions
module UserGuardian
def can_claim_reviewable_topic?(topic)
SiteSetting.reviewable_claiming != "disabled" && can_review_topic?(topic)
end
def can_pick_avatar?(user_avatar, upload)
return false unless self.user
return true if is_admin?
# can always pick blank avatar
return true if !upload
return true if user_avatar.contains_upload?(upload.id)
return true if upload.user_id == user_avatar.user_id || upload.user_id == user.id
UserUpload.exists?(upload_id: upload.id, user_id: user.id)
end
def can_edit_user?(user)
is_me?(user) || is_staff?
end
def can_edit_username?(user)
FEATURE: Rename 'Discourse SSO' to DiscourseConnect (#11978) The 'Discourse SSO' protocol is being rebranded to DiscourseConnect. This should help to reduce confusion when 'SSO' is used in the generic sense. This commit aims to: - Rename `sso_` site settings. DiscourseConnect specific ones are prefixed `discourse_connect_`. Generic settings are prefixed `auth_` - Add (server-side-only) backwards compatibility for the old setting names, with deprecation notices - Copy `site_settings` database records to the new names - Rename relevant translation keys - Update relevant translations This commit does **not** aim to: - Rename any Ruby classes or methods. This might be done in a future commit - Change any URLs. This would break existing integrations - Make any changes to the protocol. This would break existing integrations - Change any functionality. Further normalization across DiscourseConnect and other auth methods will be done separately The risks are: - There is no backwards compatibility for site settings on the client-side. Accessing auth-related site settings in Javascript is fairly rare, and an error on the client side would not be security-critical. - If a plugin is monkey-patching parts of the auth process, changes to locale keys could cause broken error messages. This should also be unlikely. The old site setting names remain functional, so security-related overrides will remain working. A follow-up commit will be made with a post-deploy migration to delete the old `site_settings` rows.
2021-02-08 05:04:33 -05:00
return false if SiteSetting.auth_overrides_username?
return true if is_staff?
return false if SiteSetting.username_change_period <= 0
return false if is_anonymous?
is_me?(user) && user.created_at > SiteSetting.username_change_period.days.ago
end
def can_edit_email?(user)
FEATURE: Rename 'Discourse SSO' to DiscourseConnect (#11978) The 'Discourse SSO' protocol is being rebranded to DiscourseConnect. This should help to reduce confusion when 'SSO' is used in the generic sense. This commit aims to: - Rename `sso_` site settings. DiscourseConnect specific ones are prefixed `discourse_connect_`. Generic settings are prefixed `auth_` - Add (server-side-only) backwards compatibility for the old setting names, with deprecation notices - Copy `site_settings` database records to the new names - Rename relevant translation keys - Update relevant translations This commit does **not** aim to: - Rename any Ruby classes or methods. This might be done in a future commit - Change any URLs. This would break existing integrations - Make any changes to the protocol. This would break existing integrations - Change any functionality. Further normalization across DiscourseConnect and other auth methods will be done separately The risks are: - There is no backwards compatibility for site settings on the client-side. Accessing auth-related site settings in Javascript is fairly rare, and an error on the client side would not be security-critical. - If a plugin is monkey-patching parts of the auth process, changes to locale keys could cause broken error messages. This should also be unlikely. The old site setting names remain functional, so security-related overrides will remain working. A follow-up commit will be made with a post-deploy migration to delete the old `site_settings` rows.
2021-02-08 05:04:33 -05:00
return false if SiteSetting.auth_overrides_email?
return false unless SiteSetting.email_editable?
return true if is_staff?
return false if is_anonymous?
can_edit?(user)
end
def can_edit_name?(user)
return false unless SiteSetting.enable_names?
FEATURE: Rename 'Discourse SSO' to DiscourseConnect (#11978) The 'Discourse SSO' protocol is being rebranded to DiscourseConnect. This should help to reduce confusion when 'SSO' is used in the generic sense. This commit aims to: - Rename `sso_` site settings. DiscourseConnect specific ones are prefixed `discourse_connect_`. Generic settings are prefixed `auth_` - Add (server-side-only) backwards compatibility for the old setting names, with deprecation notices - Copy `site_settings` database records to the new names - Rename relevant translation keys - Update relevant translations This commit does **not** aim to: - Rename any Ruby classes or methods. This might be done in a future commit - Change any URLs. This would break existing integrations - Make any changes to the protocol. This would break existing integrations - Change any functionality. Further normalization across DiscourseConnect and other auth methods will be done separately The risks are: - There is no backwards compatibility for site settings on the client-side. Accessing auth-related site settings in Javascript is fairly rare, and an error on the client side would not be security-critical. - If a plugin is monkey-patching parts of the auth process, changes to locale keys could cause broken error messages. This should also be unlikely. The old site setting names remain functional, so security-related overrides will remain working. A follow-up commit will be made with a post-deploy migration to delete the old `site_settings` rows.
2021-02-08 05:04:33 -05:00
return false if SiteSetting.auth_overrides_name?
return true if is_staff?
return false if is_anonymous?
can_edit?(user)
end
def can_see_notifications?(user)
is_me?(user) || is_admin?
end
2017-11-10 12:18:08 -05:00
def can_silence_user?(user)
user && is_staff? && not(user.staff?)
end
2017-11-10 12:18:08 -05:00
def can_unsilence_user?(user)
user && is_staff?
end
def can_delete_user?(user)
return false if user.nil? || user.admin?
if is_me?(user)
FEATURE: Rename 'Discourse SSO' to DiscourseConnect (#11978) The 'Discourse SSO' protocol is being rebranded to DiscourseConnect. This should help to reduce confusion when 'SSO' is used in the generic sense. This commit aims to: - Rename `sso_` site settings. DiscourseConnect specific ones are prefixed `discourse_connect_`. Generic settings are prefixed `auth_` - Add (server-side-only) backwards compatibility for the old setting names, with deprecation notices - Copy `site_settings` database records to the new names - Rename relevant translation keys - Update relevant translations This commit does **not** aim to: - Rename any Ruby classes or methods. This might be done in a future commit - Change any URLs. This would break existing integrations - Make any changes to the protocol. This would break existing integrations - Change any functionality. Further normalization across DiscourseConnect and other auth methods will be done separately The risks are: - There is no backwards compatibility for site settings on the client-side. Accessing auth-related site settings in Javascript is fairly rare, and an error on the client side would not be security-critical. - If a plugin is monkey-patching parts of the auth process, changes to locale keys could cause broken error messages. This should also be unlikely. The old site setting names remain functional, so security-related overrides will remain working. A follow-up commit will be made with a post-deploy migration to delete the old `site_settings` rows.
2021-02-08 05:04:33 -05:00
!SiteSetting.enable_discourse_connect &&
!user.has_more_posts_than?(SiteSetting.delete_user_self_max_post_count)
else
is_staff? &&
(
user.first_post_created_at.nil? ||
!user.has_more_posts_than?(User::MAX_STAFF_DELETE_POST_COUNT) ||
user.first_post_created_at > SiteSetting.delete_user_max_post_age.to_i.days.ago
)
end
end
def can_anonymize_user?(user)
is_staff? && !user.nil? && !user.staff? && !user.email&.ends_with?(UserAnonymizer::EMAIL_SUFFIX)
end
def can_merge_user?(user)
is_admin? && !user.nil? && !user.staff?
end
def can_merge_users?(source_user, target_user)
can_merge_user?(source_user) && !target_user.nil?
end
def can_see_warnings?(user)
user && (is_me?(user) || is_staff?)
end
def can_reset_bounce_score?(user)
user && is_staff?
end
def can_check_emails?(user)
is_admin? || (is_staff? && SiteSetting.moderators_view_emails)
end
def can_check_sso_details?(user)
user && is_admin?
end
def restrict_user_fields?(user)
(user.trust_level == TrustLevel[0] && anonymous?) || !can_see_profile?(user)
end
def can_see_staff_info?(user)
user && is_staff?
end
def can_see_suspension_reason?(user)
return true unless SiteSetting.hide_suspension_reasons?
user == @user || is_staff?
end
def can_disable_second_factor?(user)
user && can_administer_user?(user)
end
def can_see_user?(_user)
true
end
def public_can_see_profiles?
!SiteSetting.hide_user_profiles_from_public || !anonymous?
end
def can_see_profile?(user)
return false if user.blank?
return true if is_me?(user) || is_staff?
profile_hidden = SiteSetting.allow_users_to_hide_profile && user.user_option&.hide_profile?
return true if user.staff? && !profile_hidden
if user.user_stat.blank? || user.user_stat.post_count == 0
return false if anonymous? || !@user.has_trust_level?(TrustLevel[2])
end
if anonymous? || !@user.has_trust_level?(TrustLevel[1])
return user.has_trust_level?(TrustLevel[1]) && !profile_hidden
end
!profile_hidden
end
def can_see_user_actions?(user, action_types)
return true if !@user.anonymous? && (@user.id == user.id || is_admin?)
return false if SiteSetting.hide_user_activity_tab?
(action_types & UserAction.private_types).empty?
end
def allowed_user_field_ids(user)
@allowed_user_field_ids ||= {}
is_staff_or_is_me = is_staff? || is_me?(user)
cache_key = is_staff_or_is_me ? :staff_or_me : :other
@allowed_user_field_ids[cache_key] ||= begin
if is_staff_or_is_me
UserField.pluck(:id)
else
UserField.where("show_on_profile OR show_on_user_card").pluck(:id)
end
end
end
def can_feature_topic?(user, topic)
return false if topic.nil?
return false if !SiteSetting.allow_featured_topic_on_user_profiles?
return false if !is_me?(user) && !is_staff?
return false if !topic.visible
return false if topic.read_restricted_category? || topic.private_message?
true
end
def can_see_review_queue?
is_staff? ||
(
SiteSetting.enable_category_group_moderation &&
Reviewable
.joins(
"INNER JOIN category_moderation_groups ON category_moderation_groups.category_id = reviewables.category_id",
)
.where(
category_id: allowed_category_ids,
"category_moderation_groups.group_id": @user.group_users.pluck(:group_id),
)
.exists?
)
end
def can_see_summary_stats?(target_user)
true
end
def can_upload_profile_header?(user)
(is_me?(user) && user.in_any_groups?(SiteSetting.profile_background_allowed_groups_map)) ||
is_staff?
end
def can_upload_user_card_background?(user)
(is_me?(user) && user.in_any_groups?(SiteSetting.user_card_background_allowed_groups_map)) ||
is_staff?
end
FEATURE: Uppy direct S3 multipart uploads in composer (#14051) This pull request introduces the endpoints required, and the JavaScript functionality in the `ComposerUppyUpload` mixin, for direct S3 multipart uploads. There are four new endpoints in the uploads controller: * `create-multipart.json` - Creates the multipart upload in S3 along with an `ExternalUploadStub` record, storing information about the file in the same way as `generate-presigned-put.json` does for regular direct S3 uploads * `batch-presign-multipart-parts.json` - Takes a list of part numbers and the unique identifier for an `ExternalUploadStub` record, and generates the presigned URLs for those parts if the multipart upload still exists and if the user has permission to access that upload * `complete-multipart.json` - Completes the multipart upload in S3. Needs the full list of part numbers and their associated ETags which are returned when the part is uploaded to the presigned URL above. Only works if the user has permission to access the associated `ExternalUploadStub` record and the multipart upload still exists. After we confirm the upload is complete in S3, we go through the regular `UploadCreator` flow, the same as `complete-external-upload.json`, and promote the temporary upload S3 into a full `Upload` record, moving it to its final destination. * `abort-multipart.json` - Aborts the multipart upload on S3 and destroys the `ExternalUploadStub` record if the user has permission to access that upload. Also added are a few new columns to `ExternalUploadStub`: * multipart - Whether or not this is a multipart upload * external_upload_identifier - The "upload ID" for an S3 multipart upload * filesize - The size of the file when the `create-multipart.json` or `generate-presigned-put.json` is called. This is used for validation. When the user completes a direct S3 upload, either regular or multipart, we take the `filesize` that was captured when the `ExternalUploadStub` was first created and compare it with the final `Content-Length` size of the file where it is stored in S3. Then, if the two do not match, we throw an error, delete the file on S3, and ban the user from uploading files for N (default 5) minutes. This would only happen if the user uploads a different file than what they first specified, or in the case of multipart uploads uploaded larger chunks than needed. This is done to prevent abuse of S3 storage by bad actors. Also included in this PR is an update to vendor/uppy.js. This has been built locally from the latest uppy source at https://github.com/transloadit/uppy/commit/d613b849a6591083f8a0968aa8d66537e231bbcd. This must be done so that I can get my multipart upload changes into Discourse. When the Uppy team cuts a proper release, we can bump the package.json versions instead.
2021-08-24 18:46:54 -04:00
def can_upload_external?
!ExternalUploadManager.user_banned?(user)
end
def can_delete_sso_record?(user)
FEATURE: Rename 'Discourse SSO' to DiscourseConnect (#11978) The 'Discourse SSO' protocol is being rebranded to DiscourseConnect. This should help to reduce confusion when 'SSO' is used in the generic sense. This commit aims to: - Rename `sso_` site settings. DiscourseConnect specific ones are prefixed `discourse_connect_`. Generic settings are prefixed `auth_` - Add (server-side-only) backwards compatibility for the old setting names, with deprecation notices - Copy `site_settings` database records to the new names - Rename relevant translation keys - Update relevant translations This commit does **not** aim to: - Rename any Ruby classes or methods. This might be done in a future commit - Change any URLs. This would break existing integrations - Make any changes to the protocol. This would break existing integrations - Change any functionality. Further normalization across DiscourseConnect and other auth methods will be done separately The risks are: - There is no backwards compatibility for site settings on the client-side. Accessing auth-related site settings in Javascript is fairly rare, and an error on the client side would not be security-critical. - If a plugin is monkey-patching parts of the auth process, changes to locale keys could cause broken error messages. This should also be unlikely. The old site setting names remain functional, so security-related overrides will remain working. A follow-up commit will be made with a post-deploy migration to delete the old `site_settings` rows.
2021-02-08 05:04:33 -05:00
SiteSetting.enable_discourse_connect && user && is_admin?
end
def can_delete_user_associated_accounts?(user)
user && is_admin?
end
def can_change_tracking_preferences?(user)
(SiteSetting.allow_changing_staged_user_tracking || !user.staged) && can_edit_user?(user)
end
end