Group/Project Clusters page gives 404 in Admin Mode
Summary
Group/Project Clusters page gives 404 in Admin Mode.
Steps to reproduce
-
For Group-level clusters: enable
certificate_based_clusters
Feature Flag in the rails console:Feature.enable(:certificate_based_clusters)
-
Navigate to Admin Area -> Settings -> General -> Sign-in restrictions
-
Enter the Admin mode
-
Try accessing a group the admin user is not a member of you will be able to see the group as an admin
-
Try going to Kubernetes section of that group you will have a 404 error instead of the clusters page.
What is the current bug behavior?
404 on Clusters page when viewing the group/project as admin in Admin mode
What is the expected correct behavior?
Load Group Clusters page when viewing the group/project as admin in Admin mode
Relevant logs and/or screenshots
Output of checks
Results of GitLab environment info
Expand for output related to GitLab environment info
[root@kate-inst-1 ~]# sudo gitlab-rake gitlab:env:info System information System: Proxy: no Current User: git Using RVM: no Ruby Version: 2.7.4p191 Gem Version: 3.1.4 Bundler Version:2.1.4 Rake Version: 13.0.6 Redis Version: 6.0.16 Git Version: 2.33.0. Sidekiq Version:6.2.2 Go Version: unknown GitLab information Version: 14.4.1-ee Revision: abc23a14bac Directory: /opt/gitlab/embedded/service/gitlab-rails DB Adapter: PostgreSQL DB Version: 12.7 URL: https://cos7ob.kate.gitlab.support HTTP Clone URL: https://cos7ob.kate.gitlab.support/some-group/some-project.git SSH Clone URL: git@cos7ob.kate.gitlab.support:some-group/some-project.git Elasticsearch: no Geo: no Using LDAP: no Using Omniauth: yes Omniauth Providers: GitLab Shell Version: 13.21.1 Repository storage paths: - default: /data/git-data/repositories GitLab Shell path: /opt/gitlab/embedded/service/gitlab-shell Git: /opt/gitlab/embedded/bin/git
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 >= 13.21.1 ? ... OK (13.21.1) Running /opt/gitlab/embedded/service/gitlab-shell/bin/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 ...
Git configured correctly? ... yes Database config exists? ... yes All migrations up? ... yes Database contains orphaned GroupMembers? ... no GitLab config exists? ... yes GitLab config up to date? ... yes Log directory writable? ... yes Tmp directory writable? ... yes Uploads directory exists? ... yes Uploads directory has correct permissions? ... yes Uploads directory tmp has correct permissions? ... yes 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: ... 2/1 ... yes 51/2 ... yes 51/3 ... yes 51/4 ... yes 51/5 ... yes 51/6 ... yes 51/7 ... yes 51/8 ... yes 51/9 ... yes 51/10 ... yes 51/11 ... yes 52/12 ... yes 52/13 ... yes 53/14 ... yes 53/15 ... yes 53/16 ... yes 54/17 ... yes 54/18 ... yes 54/19 ... yes 54/20 ... yes 54/21 ... yes 54/22 ... yes 54/23 ... yes 54/24 ... yes 54/25 ... yes 54/26 ... yes 55/27 ... yes 55/28 ... yes 55/29 ... yes 55/30 ... yes 56/31 ... yes 56/32 ... yes 56/33 ... yes 56/34 ... yes 56/35 ... yes 57/36 ... yes 57/37 ... yes 57/38 ... yes 57/39 ... yes 58/40 ... yes 58/41 ... yes 58/42 ... yes 66/43 ... yes 70/45 ... yes 70/46 ... yes 69/47 ... yes 69/48 ... yes 58/52 ... yes 58/53 ... yes 63/54 ... yes 66/55 ... yes 66/56 ... yes 66/57 ... yes 66/58 ... yes 66/59 ... yes 65/72 ... yes 66/77 ... yes 66/78 ... yes 69/81 ... yes 66/85 ... yes 66/86 ... yes 66/89 ... yes 66/90 ... yes 66/92 ... yes 66/97 ... yes 69/100 ... yes 66/101 ... yes 66/102 ... yes 66/103 ... yes 66/104 ... yes 66/107 ... yes 66/110 ... yes 69/111 ... yes 94/112 ... yes 66/113 ... yes 69/114 ... yes 91/115 ... yes 66/117 ... yes 66/118 ... yes 66/119 ... yes 66/121 ... yes 66/122 ... yes 66/124 ... yes 66/125 ... yes 66/126 ... yes 66/128 ... yes 66/129 ... yes 66/130 ... yes 66/131 ... yes 69/132 ... yes 66/133 ... yes 66/137 ... yes 91/138 ... yes 69/140 ... yes 69/141 ... yes 69/142 ... yes 66/143 ... yes 100/144 ... yes 102/145 ... yes 69/146 ... yes 66/147 ... yes 66/148 ... yes 66/149 ... yes 66/152 ... yes 69/153 ... yes 87/154 ... yes 66/155 ... yes 66/156 ... yes 66/157 ... yes 66/159 ... yes 66/160 ... yes 66/161 ... yes Redis version >= 5.0.0? ... yes Ruby version >= 2.7.2 ? ... yes (2.7.4) Git version >= 2.33.0 ? ... yes (2.33.0) Git user has default SSH configuration? ... yes Active users: ... 57 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 (6.4 - 6.x deprecated to be removed in 13.8)? ... skipped (elasticsearch is disabled)
Checking GitLab App ... Finished
Checking GitLab subtasks ... Finished
Possible fixes
The issue is caused by the current user session not yet being present when trying to fetch a group
object.
In the Groups::ClustersController
, the group
object is fetched before the current session is setup. This is because the method to fetch the group
is is prepended to the controller's before_actions
, while the call to setup the current session happens after that.
More info in this comment thread: #344915 (comment 1543405009). As discussed in the thread, this could be fixed by making sure that the group
object is only fetched when the current user session is already present. This is done by using before_action
instead of prepend_before_action
, like so:
--- a/app/controllers/groups/clusters_controller.rb
+++ b/app/controllers/groups/clusters_controller.rb
@@ -3,8 +3,8 @@
class Groups::ClustersController < Clusters::ClustersController
include ControllerWithCrossProjectAccessCheck
+ before_action :group
before_action :ensure_feature_enabled!
- prepend_before_action :group
requires_cross_project_access
--- a/app/controllers/projects/clusters_controller.rb
+++ b/app/controllers/projects/clusters_controller.rb
@@ -1,7 +1,7 @@
# frozen_string_literal: true
class Projects::ClustersController < Clusters::ClustersController
- prepend_before_action :project
+ before_action :project
before_action :repository
You will need to check if using before_action
instead of prepend_before_action
causes problems, and resolve them accordingly.