Apply incident visibility rules to metric image reads

Diane Russelrequested to merge
dlrussel/631431-metric-image-anonymous-read into master

What does this MR do and why?

Metric image downloads did not follow the incident's own visibility rules. Anonymous users and non-members could download images for confidential incidents, incidents with a banned (hidden) author, and incidents where issues are visible to members only. The issue is confidential and has the security-fix-in-public label, which is why this is on the canonical project.

  • Add prevent :read_issuable_metric_image to the existing ~can?(:read_issue) block in app/policies/issue_policy.rb, so metric images are hidden whenever the incident is. That covers confidential, hidden and members only incidents, and any future rule that hides an issue.
  • Merge the 2 ~can?(:read_issue) prevent blocks in IssuePolicy into one, in a separate commit.
  • Keep the read_issuable_metric_image grant in config/authz/roles/public_anonymous.yml, because fine-grained personal access tokens without a scope rely on it to get the same access as a signed in non-member on public projects.
  • Add tests, a read_issuable_metric_image table in ee/spec/policies/issue_policy_spec.rb for public, confidential, members only and hidden incidents across anonymous, non-member and member users, plus download cases in ee/spec/controllers/ee/uploads_controller_spec.rb.

Removing the public anonymous grant instead was rejected because it breaks the documented fine-grained token behavior and fails an existing shared example in ee/spec/requests/api/issues_spec.rb.

References

Screenshots or screen recordings

No UI change.

How to set up and validate locally

bin/rspec ee/spec/policies/issue_policy_spec.rb -e read_issuable_metric_image
bin/rspec ee/spec/controllers/ee/uploads_controller_spec.rb
bin/rspec ee/spec/requests/api/issues_spec.rb -e metric_images -e 'metric images'

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Diane Russel

Merge request reports