Cannot log in to Lagoon logs UI

Describe the bug

The Lagoon logs UI (Kibana or Opensearch Dashboards) gets a cookie from Keycloak which passes role information to the logs UI in order to enforce index viewing permissions.

If the user is in too many groups, this cookie can get so large that it reaches the de facto browser limit of 4096 bytes and is rejected by the browser.

This causes a redirect loop when trying to log in to the logs UI.

To Reproduce

Steps to reproduce the behavior:

1. Add a user to lots of projects in Lagoon
2. User visits the logs UI
3. User cannot login and encounters a “too many redirects” error.

Expected behavior

Lagoon should avoid creating such a large cookie.

Screenshots

n/a

Additional context

In order to add users to a project a user must be OWNER within a project group. This means that a Lagoon user who is OWNER in their main customer group which contains all their projects will often also want to be OWNER in individual project groups which will increase the likelihood of hitting this bug.

The code creating the cookie looks roughly like this:

var ArrayList = Java.type("java.util.ArrayList");
var groupsAndRoles = new ArrayList();
var forEach = Array.prototype.forEach;
// add all groups the user is part of
forEach.call(user.getGroups().toArray(), function(group) {
	// remove the group role suffixes
	// lets check if the group has a parent if this is a child
	if(group.getFirstAttribute("type") == "role-subgroup") {
		var parent = group.getParent();
		if(parent.getFirstAttribute("type") == "project-default-group") {
			var projectIds = parent.getFirstAttribute("lagoon-projects");
			if(projectIds !== null) {
				forEach.call(projectIds.split(","), function(g) {
					groupsAndRoles.add("p" + g);
				});
				return;
			}
		}
	}
	var groupName = group.getName().replace(/-owner|-maintainer|-developer|-reporter|-guest/gi,"");
	groupsAndRoles.add(groupName);
	return;
});
// add all roles the user is part of
forEach.call(user.getRoleMappings().toArray(), function(role) {
	var roleName = role.getName();
	groupsAndRoles.add(roleName);
});
exports = groupsAndRoles;

This adds roles for all the projects that the user is an OWNER of even if the user is already an OWNER of a group that contains the project.

Could this code be improved to inspect the lagoon-projects annotation on the group and avoid adding the individual project roles where the user already has index view permissions for the project via a group? That would significantly reduce the cookie size in the common case outlined above.

[shreddedbacon]

I have something that appears to work, it’s in the test infrastructure now and playing around with groups/clearing cookies etc returns the expected results.

it creates 2 maps

• one map is projectid:custom-group (all the user created groups)
• one map is projectid:project-group (all the project default groups)

it removes all the custom-group projectids from the project-group map so that only unique ungrouped project roles remain

then goes over the remaining 2 maps to add all the unique roles for the user to the exported array

var ArrayList = Java.type("java.util.ArrayList");
var HashMap = Java.type("java.util.HashMap");
var HashSet = Java.type("java.util.HashSet");

var groupsAndRoles = new ArrayList();
var groupProjectIds = new HashMap();
var projectGroupProjectIds = new HashMap();

var forEach = Array.prototype.forEach;
// add all groups the user is part of
forEach.call(user.getGroups().toArray(), function(group) {
	// remove the group role suffixes
	// lets check if the group has a parent if this is a child
	var groupName = group.getName().replace(/-owner|-maintainer|-developer|-reporter|-guest/gi,"");
	if(group.getFirstAttribute("type") == "role-subgroup") {
		var parent = group.getParent();
		var projectIds = parent.getFirstAttribute("lagoon-projects");
		if(parent.getFirstAttribute("type") == "project-default-group") {
			if(projectIds !== null) {
				forEach.call(projectIds.split(","), function(g) {
					projectGroupProjectIds.put(g, groupName)
				});
				return;
			}
		} else {
			if(projectIds !== null) {
				forEach.call(projectIds.split(","), function(g) {
					groupProjectIds.put(g, groupName)
				});
				return;
			}
		}
	}
	return;
});

// add all the unique project ids roles the user has, that aren't in an already existing group
projectGroupProjectIds.keySet().removeAll(groupProjectIds.keySet());
for each (var e in projectGroupProjectIds.keySet()) groupsAndRoles.add("p"+e);

// now add all the users groups
var uniqueGroups = new HashSet(groupProjectIds.values());
for each (var e in uniqueGroups) groupsAndRoles.add(e);

// add all roles the user is part of
forEach.call(user.getRoleMappings().toArray(), function(role) {
	var roleName = role.getName();
	groupsAndRoles.add(roleName);
});
exports = groupsAndRoles;

[tobybellwood]

This would have to be done in hand with removing the project-specific roles. The only personalised tenant+roles created would be for those people who don’t use a group currently, so the numbers of roles shouldn’t explode (in fact, they should reduce).

Not creating an alternative to the project-groups would render those users unable to view anything in kibana, hence this idea?