Skip to main content
Version: 1.6.4

Known Issues

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

v1.6​

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.