Quillet
Menu
Menu

Access

5 min read

Quillet has four credentials (an account, a personal token, a CLI key and a delivery key), and each one reaches a different part of the system for a different reason.

Why ownership stays with a person

Two kinds of work happen in a Quillet project. A person runs the project: they add members, mint keys and create environments. A deploy job or a website does something narrower, reading or writing content and nothing else. Quillet keeps those two kinds of work on different credentials, and it draws the line between them at ownership. Ownership belongs to a person.

The line sits there for two reasons. Renaming a project, changing who may see it and minting the next key are decisions somebody answers for, and a credential sitting in a CI job is nobody. And a key that could mint keys could mint its own replacement, so revoking it would achieve nothing. That is why an API key, whatever its scopes, never has the owner role. It can never mint another key, add a member or change the project's settings.

What each credential can reach

Each credential is shaped for one kind of caller, and only the delivery key belongs on a website.

Account

You sign in to the dashboard with an email and a password, or through GitHub or Google where the instance allows it. Your role is set per project, not once for the whole instance. An owner manages members, keys, environments, webhooks and settings. An editor writes and publishes content. A viewer reads.

Personal token

A personal token is you, working from a terminal or a script. You mint it on your Account page. It carries no scopes and is tied to no project. Instead it acts with your memberships and your roles, in every project you belong to. That is what makes it the credential for owner work from the command line, such as creating an environment. The CLI has no password sign-in at all, so a token is how a person signs in to it. A new token expires after 90 days by default. A token cannot mint another token, so a leaked one cannot replace itself before you revoke it.

CLI key

A CLI key belongs to one project and is meant for the CLI and for CI jobs. It holds explicit scopes, such as content:read, content:write and content:publish, and it reaches either every environment in the project or a single one. Whatever it does is recorded as the key's action, not a person's.

Delivery key

A delivery key reads published content from one environment, through /d/v1 and nowhere else. Of the four credentials, it is the only one that belongs in a website. With the assets:private scope it also receives signed links to private files.

Quillet shows every secret once, at the moment it is minted, and stores only a hash of it. A preview token is not a fifth credential. All it does is choose which version an authorised delivery read answers with.

How to

Dashboard

  1. Open the account menu in the header and choose Account.
  2. Under Personal access tokens, press New token, give it a name and keep the 90-day expiry.
  3. Press Create token and copy the secret. It is not shown again.
  4. If you are an owner, open Settings, then Keys, to see the project's management and delivery keys, with when each was created and last used.

API

Ask the API who a credential is:

curl -s -u '<tokenId>:<secret>' http://localhost:3000/api/v1/auth/me

A personal token answers "kind":"user" with "via":"token". A CLI key answers "kind":"key" with its project, environment and scopes. A delivery key is refused with a 403, because it belongs to /d/v1 alone.

Limits

  • A personal token cannot be narrowed to one project or to some of its scopes. Use a CLI key when you need that.
  • No one can see another person's tokens, not even an owner.
  • Revoking a token stops it at once, but it undoes nothing the token did. Keys minted with it outlive it, so after a leak, check the project's keys and members for anything you did not add.
  • A CLI key never has the owner role, so creating or deleting an environment from the CLI needs a personal token.
  • A CLI key bound to one environment cannot compare or promote.
  • Anyone who can read your site's delivery key can read your published content. That is the only thing the key lets them do.

Last updated