Skip to content

Authentication and authorization

Central session authentication

The service imports ../shared/auth and validates Central's acugis_session cookie by hashing its value with SHA-256 and looking up a non-expired dashboard_sessions row joined to an enabled dashboard_users row. It does not create users, groups, or sessions and exposes no login route; unauthenticated browser requests are redirected to /login?next=..., which must be supplied by the surrounding platform.

The shared library can parse bearer personal access tokens, but this service's authorization provider does not attach a token store. Bearer PAT authentication is therefore unsupported by this service as currently wired.

Mechanisms not implemented by this service

Mechanism Status
Session cookie (acugis_session) Supported for validation; issuance belongs to Central.
Personal access token (Authorization: Bearer agp_…) Shared code exists; this service does not wire a token store, so PATs do not authenticate.
JWT Not implemented. Shared TokenClaims is reserved for possible future use and is not verified here.
OAuth / OIDC Not implemented.
API keys / HTTP Basic Not implemented for publish-service routes.
qcarta purge Bearer token Implemented only for POST /admin/cache/purge on the separate tile service.

When all Central database URLs are absent, or the connection fails, auth is disabled and route wrappers become permissive. Database-backed registries are also unavailable. This fail-open compatibility mode is unsuitable for an exposed production instance; production should monitor startup logs and network-restrict the service.

Authorization model

Central ACLs use:

  • groups: Administrators, Public, and deployment-defined groups such as Editors;
  • resources: a type/key pair;
  • permissions: view, edit, or admin.

Permission implication is admin → edit → view. Administrator group aliases and the user's admin flag bypass resource checks. Every user check also includes the Public group; anonymous project checks use Public alone.

Service gate

Management routes require a resource_type=service, resource_key=qgis_publish permission. Static administration pages generally require view; pgservice and basemap administration require admin.

Startup reconciles platform service resource rows. New service rows receive admin only for the Administrators group when that group exists.

Project gate

Published projects are registered as:

  • resource_type=qgis_project
  • resource_key=<project-id>
  • service=qgis-publish-service

For a newly registered project, existing named groups receive:

  • Administrators: admin
  • Editors: edit
  • Public: view

This means newly published projects are public by default when the Public group exists. Change Central grants if restricted-by-default publication is required.

Read endpoints enforce project view where implemented, and feature/project mutations require service edit plus route-specific project checks. The UI service gate does not replace project ACLs.

The shared cookie helper issues HttpOnly, SameSite=Lax cookies and marks them Secure when TLS is direct or X-Forwarded-Proto is exactly https. Although this service does not issue the cookie, a trusted reverse proxy should set/replace X-Forwarded-Proto correctly and prevent clients from spoofing forwarded headers.

Set ACUGIS_SESSION_COOKIE_DOMAIN only in Central when cross-subdomain cookies are required. Empty means host-only. BASE_PATH does not alter the cookie path, which is /.

qcarta administration

Most qcarta HTTP endpoints have no built-in authentication and are expected to bind to loopback. Only POST /admin/cache/purge checks Authorization: Bearer <token> against QCARTA_CACHE_PURGE_TOKEN. The comparison is a normal string comparison, and seed/prewarm/metrics endpoints are unprotected.

Keep qcarta on loopback or behind an authenticated network boundary. Use a high-entropy token shared only with the main service, and rotate the credential-like token present in the tracked unit sample.

Security notes

  • QGIS WMS filters are validated for dangerous SQL-like constructs, but detailed filter/query values are logged in several paths. Restrict log access.
  • pg_service.conf contains plaintext database passwords and is managed through admin APIs; restrict filesystem permissions and backups.
  • The UI uses external CDNs and map/CRS providers. Define an appropriate Content Security Policy at the reverse proxy after inventorying required origins.
  • No CSRF middleware is visible in the main service. SameSite cookies help, but state-changing routes should also be protected by same-origin proxy policy and, if required, an upstream CSRF layer.
  • The repository contains no rate limiter. Apply request/body/time limits at the edge, especially for uploads, QGIS rendering, seed, and import routes.