---

name: geoserver-and-security description: "Configure and troubleshoot GeoServer-backed OGC publication, OAuth2, permissions, groups, remote services, and the GeoNode proxy." disable-model-invocation: true metadata: disco-role: operating license: NOASSERTION

GeoServer and security

Use this skill when a GeoNode task crosses the GeoNode Django boundary into GeoServer, GeoFence, an OAuth2/OIDC provider, a remote OGC service, or the GeoNode proxy. Route general installation and container readiness to the setup-and-configuration skill; route resource payloads and upload validation to resource-and-api; route harvest scheduling to harvesting-and-admin.

First classify the boundary

Before changing anything, identify which plane is failing:

1. GeoNode/Django plane — session or OAuth2 token validation, Django authentication backends, guardian object permissions, GroupProfile membership, and /security/ views.
2. GeoServer plane — GeoServer's internal users, OAuth2 authentication filter, filter chains, role service, GeoFence rules, workspaces, stores, and OGC operations.
3. Bridge plane — the URLs and secrets that let GeoNode and GeoServer call one another, the reverse proxy, TLS trust, and the remote-service registry.

A successful Django login is not proof that GeoServer authentication, GeoServer authorization, or GeoFence synchronization is working. Conversely, a GeoServer administrator credential is not a GeoNode user credential.

Gate the work

Ask for or verify the target topology before making a live change:

• GeoServer is running and reachable from GeoNode; GeoNode is reachable from GeoServer; external PostgreSQL/PostGIS, Redis/Celery, reverse proxy, and remote OGC services are available where the workflow needs them.
• The deployment owns a secret-management path for GeoServer admin credentials, OAuth2 client material, API keys, and remote-service credentials. Never place secrets in this skill, source control, shell history, URLs, or diagnostic output.
• GeoServer has compatible OAuth2 and GeoFence extensions when those features are enabled. Browser, live GeoServer, TLS, remote endpoint, and service-backed tests are optional gates, not package-import checks.
• The operator has a rollback or backup plan before changing GeoServer security, filter chains, or authorization rules.

The supplied CPU/Python environment does not verify any external service gate. Treat all live publication, OAuth2 handshake, TLS trust, GeoFence, Redis/Celery, PostgreSQL/PostGIS, reverse-proxy, browser, and remote OGC observations as unverified until tested in the target deployment.

Choose the configuration path

• For URL or topology work, read the GeoServer reference and compare internal, public, and browser UI URLs before editing settings.
• For identity, roles, resource permissions, or group synchronization, read permissions and auth.
• For an error or unexpected access result, use the status-code decision tree in troubleshooting, preserving the failing URL, request type, user/group context, and service logs without secrets.

Configure the URL contract

Keep these values intentional and coherent:

• GEOSERVER_LOCATION: GeoNode's server-to-server GeoServer base URL; it must resolve from the GeoNode process and normally end in /.
• GEOSERVER_PUBLIC_LOCATION: the canonical externally reachable GeoServer base URL used in capabilities, links, and browser-facing OGC URLs.
• GEOSERVER_WEB_UI_LOCATION: the browser/admin UI base URL; it may differ from the public OGC URL behind a reverse proxy.
• OGC_SERVER["default"]: align BACKEND, LOCATION, PUBLIC_LOCATION, WEB_UI_LOCATION, login/logout endpoint names, security toggles, write mode, timeout/retry values, and GeoFence URL.

Do not “fix” a bad base URL by making the proxy accept arbitrary hosts. Normalize scheme, host, path prefix, port, and trailing slash together, then test both a capabilities request and a browser redirect.

Operate safely

For publication or synchronization, establish the workspace and layer identifier first, then distinguish local GeoServer-managed datasets from remote-service resources. Inspect command help and select a narrow filter before using synchronization commands. Permission updates can write GeoFence rules and invalidate caches; style, layer, thumbnail, attribute, and metadata synchronization can call GeoServer and may enqueue work.

For remote services, register only a safe, reachable base URL, use the service's supported type and version, and use an auth configuration backed by a secret store when authentication is required. The generic proxy must remain protected by safe-URL validation and an allowlisted hostname registry. A remote link being stored in GeoNode is not proof that the endpoint is available or trustworthy.

Validate the outcome

A complete validation records:

• the effective settings (with secrets redacted), canonical URL normalization, and whether the target service gate was available;
• GeoNode-side authentication and guardian permission result;
• GeoServer-side authentication result, resolved roles, workspace/layer rule, and the exact OGC operation tested;
• expected status/content type, relevant GeoNode and GeoServer log correlation, and any cache or asynchronous synchronization delay;
• unverified prerequisites and the next service-backed check.

Prefer a mocked helper or URL-construction test when no service is provisioned. Never report a mock, import, or static check as proof of live WMS/WFS/WCS/CSW, OAuth2, GeoFence, TLS, or proxy behavior.

Hard safety rules

• Do not generate GeoServer launchers, password-bearing curl commands, sample client secrets, API keys, or plaintext credential examples.
• Do not disable TLS verification, safe-URL checks, GeoFence, or the OAuth2 API key merely to make a test pass.
• Do not grant anonymous or wildcard access while diagnosing a private layer.
• Do not use destructive rule purges, broad permission rewrites, or unscoped synchronization without explicit approval and a recovery plan.