Skip to main content
Version: 1.6.4

Known Issues

This page collects known issues per platform version along with available workarounds.

v1.6​

Superset: Public role has excessive permissions​

The permissions for Superset's Public role may be too permissive, e.g. grant access to information about databases and datasets via the API.

Cause: For Superset, the public_role_like property can be used to define from which role the Public role inherits its permissions. If this value is or was set to a too-permissive role like Alpha, then the Public role may include overly broad permissions. In CIVITAS CORE versions before v1.5, public_role_like defaulted to the Alpha role. This means installations that originally started with a version before v1.5 may be affected as well.

The default value for public_role_like was removed with the release of v1.5. However, Superset does not fully revert permissions when public_role_like is changed. If the property was previously set to Alpha, then the Alpha permissions remain if the value is just unset. If public_role_like is set to another role like Gamma, permissions like all database access on all_database_access and all datasource access on all_datasource_access remain.

Action:

  1. Check the value of public_role_like in your inventory. If it is unset and you are running CIVITAS CORE < v1.5, Alpha is the implicit default and should be overridden explicitly:

    public_role_like: ''

  2. Review the permissions of your Public role in Superset and remove any excessive entries, e.g.:

    • all database access on all_database_access
    • all datasource access on all_datasource_access

  3. In Superset 4.1.2 there is no predefined permission set for the role Public. We recommend configuring permissions manually and not use Gamma as an alternative to Alpha since this still grants unnecessarily broad permissions.

  4. In Superset 6.1.0 (release with CIVITAS CORE v1.7), setting public_role_like: 'Public' causes the superset init script to apply a sensible default set of permissions for the Public role. Be aware that any subsequent manual changes to the Public role will be overwritten on each deployment. To use this only for the initial setup, deploy once with public_role_like: 'Public' and then remove the value (public_role_like: '') so that manual adjustments are not overwritten on future deployments.

Recommended permissions for a public dashboard role based on Superset 6.1.0

For orientation when manually setting the permissions for the Public role, here are the permissions that Superset 6.1.0 sets as a default when public_role_like: 'Public' is set:

can dashboard permalink on Superset
can explore json on Superset
can external metadata on Datasource
can get on Datasource
can query form data on Api
can query on Api
can read on Annotation *
can read on Chart
can read on CssTemplate *
can read on CurrentUserRestApi *
can read on Dashboard
can read on DashboardFilterStateRestApi
can read on DashboardPermalinkRestApi
can read on EmbeddedDashboard
can read on ExplorePermalinkRestApi
can read on Theme *
can slice on Superset
can time range on Api
can write on DashboardFilterStateRestApi

Entries marked with * are not available in Superset 4.1.2.

Status: No automated fix available. Manual review and adjustment of the Public role permissions is required.

Repository locations changed​

On Jun 15, 2026, multiple repositories have been relocated. Upon redeployments or restarts in versions up to v1.6.3, this can result in the following issues:

  • ImagePullBackOff for civitas-core-portal, mapfish_print, geoportal_backend, or geoportal
  • Error in Keycloak deployment because udsp-tenantnamemapper.jar could not be downloaded in initdbScript

Status: A manual fix is available (see Updating Repository URLs). This issue will be resolved in v1.7.

FROST permissions do not allow for underscores in dataspace naming​

Status: A manual fix is available (see below). This issue will be resolved in v1.7.

Accessing projects using a project-level permission like ds_energy__read fails if the project name contains underscores.

Solution: Update the FROST deployment so the regular expression matching project-level permissions accepts underscores in the project part.

Environment:
  ...
  auth_prd_roleRegex: "^([a-zA-Z0-9 _]+)__([a-zA-Z0-9]+)$"

See the FROST Projects plugin documentation for more information on the subject.

Masterportal fails to show authenticated layers​

Status: A manual fix is available (see below). This issue will be resolved in v1.7.

After switching to the GeoServer OIDC integration in CIVITAS/CORE v1.6, Masterportal fails to show non-public layers. For users that are logged into GeoServer in the same session, displaying non-public layers in Masterportal will work through shared session cookies. For users who are not logged into GeoServer, displaying these layers fails.

Solution​

Create jwt-headers authentication filter​

In GeoServer under Security -> Authentication, create a jwt-headers filter chain civitas-idm-jwt with the following settings:

  • Request header attribute for User Name: Authorization
  • Format the Header value is in: JWT
  • JSON path for the User Name: preferred_username

Header Attached JWT Validation

  • Validate JWT (Access Token)
    • Validate Token Expiry
    • Validate JWT (Access Token) Signature
      • JSON Web Key Set URL (jwks_uri): https://idm.<your-domain>/realms/<your-realm>/protocol/openid-connect/certs
    • Validate JWT (Access Token) Against Endpoint
      • URL (userinfo_endpoint): https://idm.<your-domain>/realms/<your-realm>/protocol/openid-connect/userinfo

Role Source: Header Containing JWT

  • Request Header attributes for Roles: Authorization
  • JSON Path (i.e. property1.property2): resource_access.geostack.roles

Role Converter Map from External Roles to Geoserver Roles: geoAdmin=ROLE_ADMINISTRATOR;geoAdmin=ADMIN

Use jwt-headers filter in rest, gwc and default filter chains​

The filter chain web can be left untouched and keep using the civitas-idm-oidc filter.

Update the filter chains rest, gwc and default for using civitas-idm-jwt instead of the OIDC filter civitas-idm-oidc.

Status: A manual fix is available. This issue is expected to be fixed in version v1.7.

Keycloak restart failures​

Keycloak restart failures can occur due to missing overrides of the idmkeycloak-init-scripts config map during deployment.

ERROR: Failed to run 'build' command. ERROR: java.io.IOException: Failed to create a new filesystem for /opt/bitnami/keycloak/lib/../providers/udsp-organizationmapper.jar ERROR: Failed to create a new filesystem for /opt/bitnami/keycloak/lib/../providers/udsp-organizationmapper.jar ERROR: zip END header not found

Solution: The init script install-ext-1.sh trying to load the jar file udsp-organizationmapper.jar can be manually removed from the config map idmkeycloak-init-scripts.

Status: A manual fix is available. This issue is fixed in version v1.6.2.

Superset: Login screen shown for unauthenticated users on public dashboards​

When unauthenticated users navigate between public dashboards, a login screen may unexpectedly appear instead of the dashboard content. This is caused by PUT requests to the dashboard API (e.g. PUT /api/v1/dashboard/{id}/...) failing with 403/401 status codes, which triggers the authentication redirect. The issue can be tracked upstream: apache/superset#32836.

Solution: A possible fix for the unintended redirect is to temporarily configure the API management to replace the status code 401 with status code 200 for PUT requests to /api/v1/dashboard/* until an upstream fix is available.

Status: A manual workaround is available. This issue is expected to be fixed in version v1.7.

Service portal not reachable​

The service portal may become unreachable with a 502 Bad Gateway error after deployment. This is caused by missing version pinning in the cluster deployment, which allowed an incompatible version of the service portal to be pulled prematurely.

Solution: Manually pin the cluster deployment image to version 2.0.0.

Status: A manual fix is available (see above). This issue is fixed in version v1.6.3.