Skip to content

Managing access (private/public, users, groups, admins)

This page explains access control in ECMWF Sites without diving into implementation.

Private vs public

Every site has a type:

  • Private: only allowed users/groups and administrators can view.
  • Public: anyone can view unless you deliberately protect parts of the site.

A common approach:

  • keep the site private while you’re drafting
  • switch to public when ready — note that only Hub administrators can change a site’s type, so ask through the usual support channel
  • protect sensitive subfolders even on a public site

Viewers vs administrators

  • Viewers: can read the site (for private sites, they must be allowed).
  • Administrators: can change settings, manage sharing, and perform operational actions.

The site owner is also an administrator. See Site settings for the settings that administrators can change.

Give administrator rights only to people you trust. An administrator can publish pages and scripts. A script on your site runs in the browser of each visitor, and it can act with that visitor's session on other sites of the platform. You can give administrator rights to people outside your organisation, but you are responsible for this decision.

Users and groups

Sites supports sharing via:

  • Users (individual usernames)
  • Groups (recommended for teams)

Best practices:

  • Prefer groups for stable access.
  • Keep the admin list small.

Requesting access to a site

If you open a private site you can’t access, the Hub still shows you the site’s page, and its Actions include Request Access:

  1. Find the site in the Hub list, or open the Hub link someone shared with you.
  2. Select Actions → Request Access and confirm.

The Hub sends the request to the site owner through the platform's request system. The owner then adds you (or, better, your group) in the site's Access section. The request itself isn't an approval mechanism: you have access once an administrator updates the access list.

The same request works through the Hub API when you're signed in. Set HUB_TOKEN to an OpenID Connect (OIDC) access token for the Hub API:

curl -H "Authorization: Bearer ${HUB_TOKEN}" -X POST \
  "https://<domain>/hub/api/v2/sites/<space>/<site>/access/"

Notes:

  • You must be signed in; the request carries your username.
  • Users who already have access get an error instead — you don't need to request access.
  • Deployments without a notification integration can't accept access requests; ask a site administrator directly.

API access: tokens

If you use automation, use an API token in the Authorization header.

The main token types are:

  • Hub access token: used for Hub API operations such as managing a site.
  • HTTP access token: used for site content operations. It can grant read-only or read/write access and has an expiry date.
  • Master token: grants full administrative control of site content. Keep it secret; regenerating it invalidates the site's existing HTTP access tokens and temporary links.

Treat tokens like passwords:

  • don’t store them in source code
  • don’t paste them in tickets/chat
  • revoke/rotate if leaked

Site administrators create and revoke HTTP access tokens in the site's Configuration section in the Hub (see Site settings and the Hub token panel: create with permission, identifier, and expiry; a history table with per-token revoke and JSON export; revoke by token value). The same operations are available through the Hub API (POST and DELETE on /hub/api/v2/sites/<space>/<site>/access-tokens/) for automation. The master token, on the other hand, is shown in the site's Configuration section in the Hub, next to a button that revokes and regenerates it. See the Site API cookbook for authenticated requests and Signed and session URLs for safe sharing for temporary links.

Hiding content on public sites using .htpasswd

The Site API has an important security feature:

  • On a public site, the public Site API hides a directory tree if it or one of its parent directories contains a .htpasswd file. Listings omit that subtree and requests to it return 404 Not Found.
  • Browser requests to protected paths on a public site prompt for HTTP Basic Authentication, using the accounts stored in the .htpasswd file. This does not make the path undiscoverable: visitors get a password prompt, not a 404.
  • WebDAV is different: it never accepts the .htpasswd accounts. The password there must be a Site API token (the username is ignored) — the site's master token or an HTTP access token — and a valid token reaches every path whatever the .htpasswd files say; a read-only token works only for reading. The file still matters on WebDAV: under a directory that contains one, anonymous browsing stops and a token becomes mandatory.

Why this is useful:

  • it protects the content from anonymous access

How to use it:

  • create a folder like private/
  • place a .htpasswd file inside private/
  • keep public content outside that folder

If someone reports “files are missing” from a public API request, check whether .htpasswd exists in that directory or a parent directory.

Generating the .htpasswd file

The Hub API can hash an account for you. Send a user name — and optionally a password — to the .htpasswd endpoint:

curl -X POST "https://<domain>/hub/api/v2/htpasswd/" \
  -H "Content-Type: application/json" \
  -d '{"username": "report-reader", "password": "pick-a-strong-one"}'

The JSON response contains:

  • username and password: what you give the visitors who should see the content
  • hash: the username:<bcrypt-hash> line that goes into the .htpasswd file

If you omit the password, the Hub generates a random one and returns it in the response, so nobody has to invent one.

To get a ready-to-upload file instead of JSON, ask for text/plain. Then the password is required, because the file only contains the hash, and the password would otherwise be lost:

curl -X POST "https://<domain>/hub/api/v2/htpasswd/" \
  -H "Content-Type: application/json" -H "Accept: text/plain" \
  -d '{"username": "report-reader", "password": "pick-a-strong-one"}' \
  -OJ

This downloads a file named .htpasswd. Upload it into the folder you want to protect (see Publishing content for how to upload). It protects that folder and everything below it, for browser and WebDAV visits; the account isn't an ECMWF account. To give the folder several accounts, call the endpoint once per account and keep the hash lines together in one .htpasswd file.