<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=344948) </details> <!--IssueSummary end--> <!--- Please read this! Before opening a new issue, make sure to search for keywords in the issues filtered by the "regression" or "type::bug" label: - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=regression - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=type::bug and verify the issue you're about to submit isn't a duplicate. ---> ### Summary While impersonating a user from the admin console, signing out _as the user being impersonated_ produces a 500 error. ### Steps to reproduce The customer reproduced this error on GitLab Omnibus 13.4.0, I reproduced on GitLab Ombibus on 14.2.1. 1. Sign into GitLab as an admin 1. Enter admin console 1. Navigate to users section 1. Impersonate a user 1. Attempt to sign out _while_ impersonating the user. _Don't_ try to stop impersonating the user first, as that will work as expected 1. At 500 error page, click "Go back" 1. Signing in now works properly on an instance without SAML integration. See note below about SAML error after this process. Additionally, my customer reports that when they click "go back" and attempt to sign in again as their admin user through SAML, they get a 422 error. They can resolve the 422 by clearing their browser cache. -- I was not able to reproduce this, as I do not have an instance with SAML enabled. You will now find ``NoMethodError (undefined method `impersonator=' for nil:NilClass)`` in `production.log` <!-- Describe how one can reproduce the issue - this is very important. Please use an ordered list. --> ### Screenshots Impersonating user:  Click drop-down at top right and select "Sign out":  Encounter 500 error:  ### What is the current *bug* behavior? Attempting to sign out while impersonating the user produces a 500 error, and one must go back and sign in again as themself. <!-- Describe what actually happens. --> ### What is the expected *correct* behavior? Successful sign-out, or end impersonation and resume admin session. <!-- Describe what you should see instead. --> ### Relevant logs and/or screenshots <details> <summary>Click to expand `500` error</summary> ``` Started POST "/users/sign_out" for <IP> at 2021-11-01 17:13:29 +0000 Processing by SessionsController#destroy as HTML Parameters: {"authenticity_token"=>"[FILTERED]"} Redirected to <customer_gitlab_url>/users/sign_in Completed 500 Internal Server Error in 61ms (ActiveRecord: 15.0ms | Elasticsearch: 0.0ms | Allocations: 31657) NoMethodError (undefined method `impersonator=' for nil:NilClass): app/controllers/concerns/impersonation.rb:9:in `current_user' app/controllers/application_controller.rb:55:in `block in <class:ApplicationController>' app/controllers/application_controller.rb:491:in `set_current_admin' lib/gitlab/session.rb:11:in `with_session' app/controllers/application_controller.rb:482:in `set_session_storage' lib/gitlab/i18n.rb:73:in `with_locale' lib/gitlab/i18n.rb:79:in `with_user_locale' app/controllers/application_controller.rb:476:in `set_locale' lib/gitlab/error_tracking.rb:52:in `with_context' app/controllers/application_controller.rb:541:in `sentry_context' app/controllers/application_controller.rb:469:in `block in set_current_context' lib/gitlab/application_context.rb:52:in `block in use' lib/gitlab/application_context.rb:52:in `use' lib/gitlab/application_context.rb:20:in `with_context' app/controllers/application_controller.rb:462:in `set_current_context' lib/gitlab/request_profiler/middleware.rb:17:in `call' lib/gitlab/jira/middleware.rb:19:in `call' lib/gitlab/middleware/go.rb:20:in `call' lib/gitlab/etag_caching/middleware.rb:13:in `call' lib/gitlab/middleware/multipart.rb:217:in `call' lib/gitlab/middleware/read_only/controller.rb:51:in `call' lib/gitlab/middleware/read_only.rb:18:in `call' lib/gitlab/middleware/same_site_cookies.rb:27:in `call' lib/gitlab/middleware/basic_health_check.rb:25:in `call' lib/gitlab/middleware/handle_ip_spoof_attack_error.rb:25:in `call' lib/gitlab/middleware/request_context.rb:23:in `call' config/initializers/fix_local_cache_middleware.rb:9:in `call' lib/gitlab/metrics/requests_rack_middleware.rb:60:in `call' lib/gitlab/middleware/release_env.rb:12:in `call' ``` </details> <details> <summary>Click to expand `422` error</summary> ``` Started POST "/users/auth/saml" for <IP> at 2021-11-01 17:13:34 +0000 Processing by Gitlab::RequestForgeryProtection::Controller#index as HTML Parameters: {"authenticity_token"=>"[FILTERED]"} Can't verify CSRF token authenticity. This CSRF token verification failure is handled internally by `GitLab::RequestForgeryProtection` Unlike the logs may suggest, this does not result in an actual 422 response to the user For API requests, the only effect is that `current_user` will be `nil` for the duration of the request Completed 422 Unprocessable Entity in 1ms (ActiveRecord: 0.0ms | Elasticsearch: 0.0ms | Allocations: 219) ActionController::InvalidAuthenticityToken (ActionController::InvalidAuthenticityToken): lib/gitlab/request_forgery_protection.rb:30:in `call' config/initializers/omniauth.rb:17:in `block in <top (required)>' lib/gitlab/request_profiler/middleware.rb:17:in `call' lib/gitlab/jira/middleware.rb:19:in `call' lib/gitlab/middleware/go.rb:20:in `call' lib/gitlab/etag_caching/middleware.rb:13:in `call' lib/gitlab/middleware/multipart.rb:217:in `call' lib/gitlab/middleware/read_only/controller.rb:51:in `call' lib/gitlab/middleware/read_only.rb:18:in `call' lib/gitlab/middleware/same_site_cookies.rb:27:in `call' lib/gitlab/middleware/basic_health_check.rb:25:in `call' lib/gitlab/middleware/handle_ip_spoof_attack_error.rb:25:in `call' lib/gitlab/middleware/request_context.rb:23:in `call' config/initializers/fix_local_cache_middleware.rb:9:in `call' lib/gitlab/metrics/requests_rack_middleware.rb:60:in `call' lib/gitlab/middleware/release_env.rb:12:in `call' ``` </details> ### Output of checks <!-- If you are reporting a bug on GitLab.com, write: This bug happens on GitLab.com --> #### Results of GitLab environment info <!-- Input any relevant GitLab environment information if needed. --> <details> <summary>Expand for output related to GitLab environment info</summary> <pre> (For installations with omnibus-gitlab package run and paste the output of: `sudo gitlab-rake gitlab:env:info`) (For installations from source run and paste the output of: `sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`) </pre> </details> #### Results of GitLab application Check <!-- Input any relevant GitLab application check information if needed. --> <details> <summary>Expand for output related to the GitLab application check</summary> <pre> (For installations with omnibus-gitlab package run and paste the output of: `sudo gitlab-rake gitlab:check SANITIZE=true`) (For installations from source run and paste the output of: `sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true`) (we will only investigate if the tests are passing) </pre> </details> ### Possible fixes <!-- If you can, link to the line of code that might be responsible for the problem. --> ### Workaround Delete browser data.