Skip to main content

Authentication and Access Control

Credential Source​

Users are defined in users.yaml and loaded at startup.

Route Protection Source​

Access rules are defined in api_access.yaml.

Each rule specifies:

  • HTTP method
  • route path pattern
  • whether the route is protected

If a route is not marked protected, it is public by default.

Auth Flow​

The service uses a simple OAuth2 password-style login flow.

Common routes:

  • POST /token
  • POST /login

Example:

curl -X POST http://127.0.0.1:8080/login \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d 'username=demo&password=changeme'

Practical Security Notes​

Current behavior is intentionally lightweight for internal and controlled deployments:

  • bearer token handling is simple and operationally convenient
  • token expiry is not the central security model
  • password hashing uses AUTH_HASH_SALT

For internet-facing hardened deployments, treat this as the first layer only and consider stronger token issuance and secret management.

Public Versus Protected Patterns​

Public by design:

  • health checks and read-only config inspection (GET /config)
  • WMS, WCS, and terrain tile serving
  • viewer and CSW info pages
  • point-query endpoints
  • dataset sample, extent, thumbnail, and style serving

Typically protected:

  • dataset listing (GET /datasets), duplication checks, and variant reports
  • uploads, registration, and dataset deletion
  • config mutation (POST /config, POST /config/reset)
  • MapCache reload and all cache write operations
  • job submission, cancellation, and cleanup
  • bulk CSW ingestion (HySpex, Sentinel, resync, rehash, prune)

Frontend Behavior​

The frontend stores the token in browser storage and attaches it automatically to protected requests after login.