Dashboard User Guide

OGC API Processes — Secure Dimensions GmbH · processes-dashboard.html

Getting started

The OGC Processes Dashboard lets you deploy geospatial processing tasks as Docker containers, execute them with custom inputs, and retrieve results stored on IPFS — all through a standard-compliant OGC API Processes interface.

Non-production service. This service is intended for evaluation and development only. See the Terms of Use for details.

Sign in

Open processes-dashboard.html in your browser. The API Server URL is pre-filled with the current page's origin — change it only if the API server runs on a different host.

Click Sign in via AUTHENIX. You will be redirected to authenix.eu to authenticate. Choose your identity provider (e.g. Google, GitHub, or a direct AUTHENIX account).

After sign-in you are returned to the dashboard. Your name and available privileges are loaded automatically. The token countdown in the top bar shows when your session will be silently refreshed.

First-time users start with read-only access (openid scope only). To deploy processes or use bridge networking, request access from an admin — see Requesting access below.

Dashboard overview

The sidebar contains eight tabs:

Tab	What it does	Requires
Dashboard	Metrics overview, recent jobs, activity log	openid
Deploy	Register a new Docker image as an OGC process	ogcapi:deploy
Execute	Run a deployed process with custom inputs	ogcapi:execute
Process list	Browse all deployed processes; delete your own	openid
Job monitor	Track job status and retrieve IPFS result links	openid
Callbacks	View webhook notifications received by the dashboard	openid
API Docs	Endpoint reference and link to Swagger UI	—
Admin	Manage user privileges (admin password required)	admin login
Settings	Token info, privilege requests, Forget Me	openid

Tabs requiring privileges you do not yet have are dimmed in the sidebar. The Deploy and Execute buttons are disabled with a tooltip explaining the required scope.

Deploying a process

Deploying registers a Docker image as a named process. The server pulls the image and verifies its sha256 digest before registration.

ogcapi:deploy required. The Deploy tab and its button are disabled unless an admin has granted you the ogcapi:deploy privilege. See Requesting access.

Fields

Field	Description
Process ID	Unique identifier, alphanumeric + hyphens/underscores. Must be unique on this server.
Title	Human-readable name shown in the process list.
Description	Short explanation of what the process does.
Docker image	Full image reference, e.g. `docker.io/myorg/myprocess:1.0`.
Image digest	The `sha256:…` digest of the image. Used to verify the pulled image. Get it with `docker inspect --format='{{"{{"}}index .RepoDigests 0{{"}}"}}' IMAGE`.
Network mode	`none` (fully isolated, default) or `bridge` (outbound internet). Bridge is image-specific and one-time — requires an admin grant for the exact image and digest.
Inputs schema	JSON object describing process inputs in OGC schema format (see below).
Outputs schema	JSON object describing expected outputs.

Input/output schema format

Each field in the schema is an object with a title and a JSON Schema schema:

{
  "name": {
    "title": "User name",
    "schema": { "type": "string", "minLength": 1 }
  },
  "count": {
    "title": "Number of results",
    "schema": { "type": "integer", "default": 10 },
    "minOccurs": 0
  }
}

Set "minOccurs": 0 to mark a field as optional.

Process image I/O contract

Your Docker image must follow the stdin → stdout convention:

Stream	Direction	Content
`stdin`	server → container	JSON object of inputs, closed with EOF
`stdout`	container → IPFS	Result bytes (JSON, GeoPackage, etc.), streamed directly
`stderr`	container → logs	Diagnostic messages — never stored, visible in worker logs

Exit code 0 = success. Any other exit code marks the job as failed.

Click Fill demo to pre-fill the form with the hello-user example process. Click Clear to reset all fields.

Executing a process

The Execute tab lets you run any deployed process with custom inputs. All executions are asynchronous — the server returns a job ID immediately and processes the request in the background.

Select a process from the dropdown. The Inputs textarea is automatically populated with a template based on the process's input schema, with default values pre-filled.

Edit the inputs JSON as needed. All fields shown are required unless marked optional in the process description.

Optionally enter a Success URI for a webhook callback when the job completes. The dashboard's built-in callback listener can be used for testing.

Click Execute. The job appears immediately in the Job monitor tab with status accepted.

Monitoring jobs

The Job monitor tab lists all your jobs and their current status.

Status	Meaning
accepted	Job is queued, waiting for the worker to pick it up.
running	Container is executing. Stdout is being streamed.
successful	Container exited with code 0. Result is available on IPFS.
failed	Container exited with a non-zero code. Check the error message.

Click the IPFS link next to a successful job to open the result in the IPFS gateway. The result is a JSON document (or binary file, e.g. GeoPackage) stored at the shown CID.

The job list auto-refreshes every few seconds while running jobs are present. Click Dismiss to remove a completed or failed job from the list.

Process list

The Process list tab shows all deployed processes in two sections:

My processes — processes you deployed. A Delete button is shown. Deleting a process does not affect already-running jobs.
Other users' processes — deployed by other users. You can execute them but not delete them. The owner's sub is shown in abbreviated form.

Click Run next to any process to jump straight to the Execute tab with that process pre-selected.

API documentation

The API Docs tab shows a quick endpoint reference table and provides three action buttons:

Open Swagger UI — opens ogc-api-docs.html in a new tab with the live OpenAPI 3.0 spec loaded from the server. You can use Try It Out for any endpoint after entering your Bearer token in the Authorize dialog.
Download JSON — downloads the raw openapi.json spec.
Copy URL — copies the OpenAPI spec URL to the clipboard.

The spec is also linked from the server's landing page at GET /api/1.0/openapi.

Admin panel

The Admin tab is for server administrators. It requires a separate username and password (not your AUTHENIX credentials).

Admins can toggle two privileges per user:

Privilege	Grants	Type
`ogcapi:deploy`	Deploy, replace, and undeploy process images	Blanket (persistent)
`bridge`	Deploy one specific process image with outbound network access (e.g. fetching SensorThings API data). The tag `latest` is not permitted.	Image-specific, one-time

How bridge grants work

Unlike ogcapi:deploy, a bridge grant is not a standing permission. Each grant is tied to a specific Docker image name and sha256 digest and is consumed after a single successful deploy. A new grant must be requested and approved for each distinct image+digest that needs bridge networking.

To add a bridge grant in the Admin panel, click + Grant bridge next to the user, enter the full image reference and its sha256 digest, then click Grant. The grant appears in the table and can be revoked before it is consumed.

The "latest" tag is not accepted for bridge grants or bridge privilege requests. Users must specify an explicit version tag (e.g. :1.2) to ensure the grant is pinned to a known, auditable image.

Users appear in the admin table as soon as they make their first authenticated API request. Privilege changes take effect immediately — no restart required.

Admin login is also available on the login screen — click Admin login ▼ to expand the form. Signing in as admin takes you directly to the Admin tab without requiring an AUTHENIX token.

Settings & privacy

The Settings tab shows:

Your authenticated identity (sub, name, email) and current effective privileges
Your raw access token (click to copy)
Decoded ID token claims
AUTHENIX endpoint information

Forget Me

The Forget Me button permanently deletes all personal data held about you on this server — name, email, subject identifier, privilege grants, and job history. You must undeploy all your processes first before this is permitted. After deletion you are automatically signed out.

See the Privacy Notice for full details of what data is stored and why.

Requesting access

New users have read-only access by default. To deploy processes or use bridge networking, go to Settings → Request additional privileges:

Requesting ogcapi:deploy

Check ogcapi:deploy.

Optionally enter a reason explaining your use case.

Click Send request to admin. The admin receives an email and can grant access via the Admin panel. Once granted, the Deploy button becomes active.

Requesting bridge network access

Bridge access is one-time and image-specific. Each request must name the exact Docker image and sha256 digest you intend to deploy with bridge networking. The latest tag is not accepted — use an explicit version tag.

Check bridge network. An additional form expands below it.

Enter the full Docker image name with an explicit version tag, e.g. docker.io/myorg/sta-fetcher:1.2 — not :latest.

Enter the image's sha256 digest, e.g. sha256:abc123…. Get it with: docker inspect --format='{{"{{"}}index .RepoDigests 0{{"}}"}}' IMAGE

Optionally enter a reason, then click Send request to admin. The email to the admin includes the image name and digest.

The admin approves by entering the same image+digest in the Admin panel's + Grant bridge form for your account. The grant is one-time: after you deploy that image with bridge networking, the grant is automatically consumed. A new request is needed for each subsequent bridge deploy.

FAQ

Why is the Deploy button greyed out?

You do not yet have the ogcapi:deploy privilege. Request it from an admin via Settings → Request additional privileges.

Why is the bridge network option not visible?

The bridge option only appears in the network selector when an admin has granted you a bridge privilege for a specific image and digest. Bridge grants are one-time and image-specific — the option disappears again after you deploy with it, because the grant is consumed. Request a new bridge grant for each image+digest you need bridge networking for.

My job is stuck at "accepted" — what happened?

The worker process may not have started a listener for your process yet. This can happen if the process was deployed very recently. Wait a few seconds and refresh. If it remains stuck, check the worker logs.

Where is the process result stored?

Results are stored on IPFS (InterPlanetary File System) via the locally operated Kubo node. Each result is identified by a content hash (CID). The gateway URL shown in the job results lets you open it directly in a browser.

How long are job results kept?

Job records are retained for 7 days, after which they are automatically deleted from Redis. The IPFS content may persist longer depending on pinning configuration.

Can I execute another user's process?

Yes — all deployed processes are visible in the Process list and can be executed by any user with the ogcapi:execute scope. You cannot delete another user's process.

How do I delete my data?

Use the Forget Me button in Settings after undeploying all your processes. See the Privacy Notice for your full GDPR rights.