Skip to content

Separate UI and API checks for user impersonation

Hakeem Abdul-Razak requested to merge 480910-impersonation-ui-api-fix into master

What does this MR do and why?

Related to #480910 (closed)

This merge request fixes the impersonation availability button behaviour, based on the admin's chosen state of their Gitlab instance. It addresses an issue where disabling impersonation tokens, personal access tokens along with a few others also unintentionally disabled user impersonation via the web UI.

The "Impersonate" button now remains available in the web UI even when PATs are disabled, while API impersonation tokens are restricted.

Replication Of The Problem & Solution

Before After
vid vid2

How to set up and validate locally

Requires an EE license to test on GDK since this feature is only available in the premium/ultimate tiers. Follow the videos above for a visual guide

  • GDK Home -> Admin Button -> General -> Visibility and access controls -> Personal access tokens -> Disable personal access tokens
  • Go back to the admin page
  • Find and open a random user
  • At the top right of the user page, the Impersonate button should be visible.

Concerns

Although unrelated to the changes made in this MR, I've noticed that disabling/enabling PATs and their associated impersonation tokens occasionally requires a manual refresh for the changes to take effect. I confirmed this behavior while testing on both the master and MR branches.

Initially, I suspected it might be a caching issue, so I tested disabling the cache in chrome Devtools & in Ruby but, it did not make a difference (only increased latency).

before_action :no_cache_headers, only[:verify_impersonation_enabled!]

Is this behaviour a cause for concern, or normal?

MR acceptance checklist

Please 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 Hakeem Abdul-Razak

Merge request reports