Admin users are not able to see full pipeline trigger tokens of other project [BUG]

Summary

According to the GitLab permission documentation page, GitLab administrators have all permissions. Therfore, it should also be possible to see / reveal the correct values of the pipeline trigger tokens when accesing any project as an admin user with admin mode enabled. This helps admin users to reproduce certain situations and support requests where the pipeline trigger token is necessary.

Currently, it is only possible to see a shortened value instead of the full value of the pipeline trigger token.

Steps to reproduce

  1. In a new browser window, sign in as a non-admin user
  2. As the non-admin user, create a pipeline trigger token in the ci/cd settings
  3. Remember the value of the pipeline trigger token as it will be important later
  4. In a another (maybe private) browser window, sign in with an admin user.
  5. As the admin user, enter the admin mode (otherwise you will not be able to access the project's ci/cd settings)
  6. As the admin user, go the ci/cd section and expand the section "Pipeline trigger tokens"; you should see the active pipeline trigger tokens
  7. Click the button "Edit" for the pipeline trigger token and look at the token value => you will notice that the token value is not the actual token value that was created before

Example Project

  1. Sign in as admin user and enable admin mode for this user
  2. Go to https://gitlab.com/client-siemens-workspace/bug-admin-mode-issues/test-project/-/settings/ci_cd#js-pipeline-triggers
  3. Reveal the values of the pipeline trigger tokens

What is the current bug behavior?

The following screenshots show how the table appears when accessed by a non-admin user and an instance admin user. Please note that only a short token value is revealed when an instance admin accesses the table of pipeline trigger tokens.

Table accessed by owner of the pipeline trigger token (non-admin user) Table accessed by instance admin (with enabled admin mode) and without project membership
image image
image image

What is the expected correct behavior?

The instance admin user should see the full value of the pipeline trigger token. The same as the non-admin user.

Relevant logs and/or screenshots

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info
System information
System:
Proxy:          no
Current User:   client-siemens
Using RVM:      no
Ruby Version:   3.2.4
Gem Version:    3.5.21
Bundler Version:2.5.11
Rake Version:   13.0.6
Redis Version:  7.0.14
Sidekiq Version:7.2.4
Go Version:     go1.22.7 darwin/arm64

GitLab information
Version:        17.5.0-pre
Revision:       3e19ed08866
Directory:      /Users/client-siemens/Development/gitlab-development-kit/gitlab
DB Adapter:     PostgreSQL
DB Version:     14.9
URL:            http://gdk.test:3000
HTTP Clone URL: http://gdk.test:3000/some-group/some-project.git
SSH Clone URL:  ssh://git@gdk.test:2222/some-group/some-project.git
Elasticsearch:  no
Geo:            no
Using LDAP:     no
Using Omniauth: yes
Omniauth Providers: 

GitLab Shell
Version:        14.39.0
Repository storages:
- default:      unix:/Users/client-siemens/Development/gitlab-development-kit/praefect.socket
GitLab Shell path:              /Users/client-siemens/Development/gitlab-development-kit/gitlab-shell

Gitaly
- default Address:      unix:/Users/client-siemens/Development/gitlab-development-kit/praefect.socket
- default Version:      17.4.0-rc1-470-gd13b26774
- default Git Version:  2.46.2

Results of GitLab application Check

Expand for output related to the GitLab application check
Checking GitLab subtasks ...

Checking GitLab Shell ...

GitLab Shell: ... GitLab Shell version >= 14.39.0 ? ... OK (14.39.0)
Running /Users/client-siemens/Development/gitlab-development-kit/gitlab-shell/bin/gitlab-shell-check
{"correlation_id":"01JA7MYDWMEQ2BWJYBM5AW1M8Y","duration_ms":7237,"level":"info","method":"GET","msg":"Finished HTTP request","status":200,"time":"2024-10-15T08:33:13Z","url":"http://gdk.test:3000/api/v4/internal/check"}
Internal API available: OK
Redis available via internal API: OK
gitlab-shell self-check successful

Checking GitLab Shell ... Finished

Checking Gitaly ...

Gitaly: ... default ... OK

Checking Gitaly ... Finished

Checking Sidekiq ...

Sidekiq: ... Running? ... yes
Number of Sidekiq processes (cluster/worker) ... 1/1

Checking Sidekiq ... Finished

Checking Incoming Email ...

Incoming Email: ... Reply by email is disabled in config/gitlab.yml

Checking Incoming Email ... Finished

Checking LDAP ...

LDAP: ... LDAP is disabled in config/gitlab.yml

Checking LDAP ... Finished

Checking GitLab App ...

Database config exists? ... yes
Tables are truncated? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... yes
Cable config exists? ... yes
Resque config exists? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... no
  Try fixing it:
  sudo chmod 700 /Users/client-siemens/Development/gitlab-development-kit/gitlab/public/uploads
  For more information see:
  doc/install/installation.md in section "GitLab"
  Please fix the error above and rerun the checks.
Uploads directory tmp has correct permissions? ... yes
Systemd unit files or init script exist? ... no
  Try fixing it:
  Install the Service
  For more information see:
  doc/install/installation.md in section "Install the Service"
  Please fix the error above and rerun the checks.
Systemd unit files or init script up-to-date? ... can't check because of previous errors
Projects have namespace: ... 
22/1 ... yes
24/2 ... yes
24/3 ... yes
27/4 ... yes
29/5 ... yes
31/6 ... yes
33/7 ... yes
35/8 ... yes
58/9 ... yes
10/10 ... yes
49/11 ... yes
12/12 ... yes
13/13 ... yes
43/14 ... yes
9/15 ... yes
56/16 ... yes
6/17 ... yes
17/18 ... yes
1/19 ... yes
1/20 ... yes
1/21 ... yes
1/22 ... yes
1/23 ... yes
1/24 ... yes
29/25 ... yes
104/26 ... yes
106/27 ... yes
109/28 ... yes
113/29 ... yes
115/30 ... yes
117/31 ... yes
119/32 ... yes
1/33 ... yes
125/34 ... yes
128/35 ... yes
127/36 ... yes
1/37 ... yes
132/38 ... yes
134/39 ... yes
140/40 ... yes
151/41 ... yes
153/42 ... yes
153/43 ... yes
158/44 ... yes
151/45 ... yes
151/46 ... yes
151/48 ... yes
151/49 ... yes
151/50 ... yes
151/51 ... yes
167/52 ... yes
170/53 ... yes
Redis version >= 6.2.14? ... yes
Ruby version >= 3.0.6 ? ... yes (3.2.4)
Git user has default SSH configuration? ... no
  Try fixing it:
  mkdir ~/gitlab-check-backup-1728981215
  sudo mv /Users/client-siemens/.ssh/config ~/gitlab-check-backup-1728981215
  sudo mv /Users/client-siemens/.ssh/gitpod ~/gitlab-check-backup-1728981215
  sudo mv /Users/client-siemens/.ssh/id_ed25519 ~/gitlab-check-backup-1728981215
  sudo mv /Users/client-siemens/.ssh/id_ed25519.pub ~/gitlab-check-backup-1728981215
  sudo mv /Users/client-siemens/.ssh/known_hosts.old ~/gitlab-check-backup-1728981215
  For more information see:
  doc/user/ssh.md#overriding-ssh-settings-on-the-gitlab-server
  Please fix the error above and rerun the checks.
Active users: ... 75
Is authorized keys file accessible? ... yes
GitLab configured to store new projects in hashed storage? ... yes
All projects are in hashed storage? ... yes
Elasticsearch version 7.x-8.x or OpenSearch version 1.x ... skipped (Advanced Search is disabled)
All migrations must be finished before doing a major upgrade ... skipped (Advanced Search is disabled)

Checking GitLab App ... Finished


Checking GitLab subtasks ... Finished

Possible fixes

Edited by Gerardo Navarro