Access control: identity, sharing, and permissions (tracking)

[giswqs]

Summary

Tracking issue for GeoLibre's access-control story: who someone is, what they can open, and what they can do once they have it. The individual pieces are filed separately and linked below.

Why

GeoLibre is local-first, and that has kept the access model deliberately thin. What exists today, in one place:

Surface	Control today
share.geolibre.app	One owner per project; public / unlisted / private (ShareVisibility in apps/geolibre-desktop/src/lib/share-geolibre.ts); a personal API token the user pastes into Settings and that lives in localStorage
Collaboration relay (workers/collab)	Anonymous participants; a host token gates set-mode; session-wide view-only / co-edit plus per-participant editOverride, enforced in the Durable Object
Web container (docker/)	Optionally one shared HTTP Basic Auth credential (GEOLIBRE_AUTH_USER / GEOLIBRE_AUTH_PASSWORD) over the app and /sidecar
Python sidecar	A per-launch bearer token, TrustedHostMiddleware, a CORS origin regex, and GEOLIBRE_CONVERSION_ROOTS path confinement
Embed API	Off by default, with a postMessage origin allowlist
Service credentials	Cesium ion / Google Maps / map service keys, custom 3D Tiles headers, PostGIS DSNs — all device-local localStorage

That is enough for one person on one machine, and it is the right amount for the desktop app. It is not enough for the workflows people keep asking about: hand a project to a team, publish a map without leaking the key that powers it, run a shared deployment where not everyone may edit, or answer "who changed this?"

Framing that applies to every child issue

The React app runs on the user's machine, so anything the client enforces is a suggestion, not a permission. Access control can only be enforced on the three server surfaces GeoLibre actually has:

1. share.geolibre.app (projects, identity, sharing)
2. the FastAPI sidecar (processing, conversion, server-backed layers)
3. the Cloudflare Workers (collaboration relay, tiles)

Every child issue below should say explicitly which of those enforces it, and where the UI is only mirroring a server decision. Two useful precedents already exist: the collaboration relay's server-side rejection of a snapshot from a guest who cannot edit, and the sidecar's token middleware — both are the right shape to generalize from.

The share server must be self-hostable

share.geolibre.app is one deployment of a documented contract, not the definition of it. A server-side access-control feature is not done until it is implementable in a server anyone can run — otherwise every item in this umbrella is unavailable to exactly the users who self-host because they do not want their data leaving their infrastructure.

Where the app stands today: resolveShareBaseUrl() and resolveCollabBaseUrl() already honor VITE_GEOLIBRE_SHARE_URL / VITE_GEOLIBRE_COLLAB_URL, but both are build-time only and neither reaches Dockerfile or docker/entrypoint.sh — so the published image cannot be pointed anywhere else, and a misconfigured value silently falls back to the public host. There is also no open-source server to point at, and no written API contract to build one against.

• Point the web container at a self-hosted share and collaboration server at runtime, and never silently fall back to the public host #1684 — point the web container at a self-hosted share/collab server at runtime, and refuse instead of falling back
• An open-source, Docker-deployable GeoLibre server for projects and identity #1685 — an open-source, Docker-deployable server for projects and identity (phase 1: write the API contract down)
• A Docker-deployable collaboration relay, with no Cloudflare dependency #1686 — a Docker-deployable collaboration relay, with no Cloudflare dependency

Children

Identity — everything else depends on it

• Sign in to share.geolibre.app with OAuth 2.0 + PKCE, using scoped and revocable tokens #1666 — sign in with OAuth 2.0 + PKCE, scoped and revocable tokens
• Store the share token and service credentials in OS secure storage on desktop #1667 — store the share token and service credentials in OS secure storage on desktop
• Organizations: members, roles, an organization visibility level, and a public-sharing policy #1668 — organizations: members, roles, an organization visibility level, and a public-sharing policy

Who can open a project

• Groups: share a project with a team, including shared-update groups #1669 — groups, including shared-update groups
• Transfer ownership of a shared project, and delete protection #1670 — ownership transfer and delete protection
• Share-readiness check: warn when a shared project references data recipients cannot load #1671 — share-readiness check (no server or identity dependency; can land first)
• Share links: access roles, expiry, password, and revoke #1527 — share links: access roles, expiry, password, and revoke (already open)

What a person can do

• A capability model: privileges, roles, and a store slice that gates the UI #1672 — a capability model: privileges, roles, and a store slice that gates the UI
• Locked-down deployment modes for the web container and embeds (kiosk, classroom) #1673 — locked-down deployment modes for the web container and embeds

What a person can see in the data

• Per-layer capabilities: query, create, update, delete, export #1674 — per-layer capabilities: query, create, update, delete, export
• Saved view definitions: server-enforced attribute and spatial filters on server-backed layers #1675 — saved view definitions, server-enforced, including own-features-only
• Field-level visibility: hide attributes and exclude them on share and export #1676 — field-level visibility, excluded on share and export

Accountability

• Editor tracking: who created and last edited each feature, and when #1677 — editor tracking (no identity dependency; can land early)
• Activity log for shared projects and collaboration sessions #1678 — activity log for shared projects and collaboration sessions

Credentials

• Credential broker so shared and embedded maps can use a key the viewer never sees #1679 — credential broker for shared and embedded maps
• Guarantee published and exported projects never carry credentials #1680 — guarantee published and exported projects never carry credentials

Sessions and institutions

• Collaboration sessions: invite roles, identity binding, durable overrides, moderation, and layer locks #1681 — collaboration: invite roles, identity binding, durable overrides, moderation, layer locks
• Enterprise sign-in for organizations: SAML/OIDC, SCIM, MFA, and session policy #1682 — enterprise sign-in: SAML/OIDC, SCIM, MFA, session policy

Suggested first slice

1. Point the web container at a self-hosted share and collaboration server at runtime, and never silently fall back to the public host #1684, and phase 1 of An open-source, Docker-deployable GeoLibre server for projects and identity #1685 — writing the server API contract down constrains the identity work rather than the other way around, and making the host runtime-configurable is a prerequisite for anyone self-hosting any of this.
2. Sign in to share.geolibre.app with OAuth 2.0 + PKCE, using scoped and revocable tokens #1666 + Store the share token and service credentials in OS secure storage on desktop #1667 — nothing above them is trustworthy until there is a real identity and somewhere safe to keep its token.
3. Groups: share a project with a team, including shared-update groups #1669 + Organizations: members, roles, an organization visibility level, and a public-sharing policy #1668 — team sharing is the most-asked-for visible gap.
4. Share-readiness check: warn when a shared project references data recipients cannot load #1671, Editor tracking: who created and last edited each feature, and when #1677, Guarantee published and exported projects never carry credentials #1680, and item 1 of Collaboration sessions: invite roles, identity binding, durable overrides, moderation, and layer locks #1681 — these need no identity and no new server surface, so they can run in parallel with the above and are the cheapest wins in the whole umbrella.

Related

• Share links: access roles, expiry, password, and revoke #1527 — share links: access roles, expiry, password, and revoke (the link-hygiene half of this; not duplicated here)
• Anchored, persistent comments on a project #1518 — anchored, persistent comments (the Comment role in Share links: access roles, expiry, password, and revoke #1527 depends on it)
• Autosave, crash recovery, and a Project History dialog #1522 — autosave, crash recovery, and a Project History dialog (project version history)

Effort

Large, and deliberately incremental. Nothing here needs to land as one release. The suggested first slice is identity, then team sharing, then the two items that need no server work at all (share-readiness check, editor tracking).