Stuck into change password when impersonating user

Summary

On my gitlab server, I impersonated a user and for some reason I was sent to the "change password" page. Since I didn't want to change his password, I tried to get out of this page but couldn't. Tried to press "stop impersonating", close and reopen browser, change page. No way out. Furthermore, I didn't know his password so I couldn't simply reset it. And since I was no more an admin, I couldn't event reset his password. Luckily, I had another browser already opened on the admin page so I set a new password and finished the procedure.

Steps to reproduce

Have an user that gitlab think it needs to change password. Impersonate this user. Get the change password screen. Unable to escape.

What is the current bug behavior?

Get the change password screen. Unable to escape.

What is the expected correct behavior?

The "stop impersonating" button should allow the admin to regain control.

Relevant logs and/or screenshots

Output of checks

Results of GitLab environment info

root@ID16723:~# sudo gitlab-rake gitlab:info sudo: unable to resolve host ID16723.example.com D, [2017-02-20T10:32:55.631530 #52594 (moved)] DEBUG -- sentry: ** [Raven] Don't know how to build task 'gitlab:info' (see --tasks) excluded from capture due to environment or should_capture callback rake aborted! Don't know how to build task 'gitlab:info' (see --tasks) /opt/gitlab/embedded/bin/bundle:22:in load' /opt/gitlab/embedded/bin/bundle:22:in ' (See full trace by running task with --trace)

Results of GitLab application Check

Checking GitLab Shell ...

GitLab Shell version >= 4.1.1 ? ... OK (4.1.1) Repo base directory exists? default... yes Repo storage directories are symlinks? default... no Repo paths owned by git:git? default... yes Repo paths access is drwxrws---? default... yes hooks directories in repos are links: ... test / bbb ... ok Running /opt/gitlab/embedded/service/gitlab-shell/bin/check Check GitLab API access: OK Access to /var/opt/gitlab/.ssh/authorized_keys: OK Send ping to redis server: OK gitlab-shell self-check successful

Checking GitLab Shell ... Finished

Checking Sidekiq ...

Running? ... yes Number of Sidekiq processes ... 1

Checking Sidekiq ... Finished

Checking Reply by email ...

Reply by email is disabled in config/gitlab.yml

Checking Reply by email ... Finished

Checking LDAP ...

LDAP is disabled in config/gitlab.yml

Checking LDAP ... Finished

Checking GitLab ...

Git configured with autocrlf=input? ... yes Database config exists? ... yes All migrations up? ... yes Database contains orphaned GroupMembers? ... no GitLab config exists? ... yes GitLab config outdated? ... no Log directory writable? ... yes Tmp directory writable? ... yes Uploads directory setup correctly? ... no Try fixing it: sudo chown -R git /var/opt/gitlab/gitlab-rails/uploads sudo find /var/opt/gitlab/gitlab-rails/uploads -type f -exec chmod 0644 {} ; sudo find /var/opt/gitlab/gitlab-rails/uploads -type d -not -path /var/opt/gitlab/gitlab-rails/uploads -exec chmod 0700 {} ; For more information see: doc/install/installation.md in section "GitLab" Please fix the error above and rerun the checks. Init script exists? ... skipped (omnibus-gitlab has no init script) Init script up-to-date? ... skipped (omnibus-gitlab has no init script) projects have namespace: ... test / bbb ... yes Redis version >= 2.8.0? ... yes Ruby version >= 2.1.0 ? ... yes (2.3.3) Your git bin path is "/opt/gitlab/embedded/bin/git" Git version >= 2.7.3 ? ... yes (2.10.2) Active users: 15

Checking GitLab ... Finished

Possible fixes

Assignee Loading
Time tracking Loading