v0.21.0 — delegated sign-in
Delegated sign-in: a connection can now be authorized by the person using it, so calls carry their permissions rather than a shared credential's.
New
GitLab can sign a person in, instead of asking them to paste a token. A connection is authorized by the person using it, and calls are made with their own permissions. The older arrangement still works unchanged — an organisation that prefers to provide one access token for everyone can keep doing exactly that. A connection uses one of the two; both are offered, and nothing here chooses between them.
A self-managed GitLab is asked for its address once. Point a connection at your own GitLab and both its API and its sign-in pages follow that single approved address together. There is no second place to fill in, and no way for the two to end up pointing somewhere different — which matters, because the sign-in address is where an application secret is presented.
GitHub and GitLab can be browsed rather than guessed at. List the organisations a connection can reach, the repositories inside them, and on GitLab the groups and projects available to you — complete with the address you would clone from. Until now every call needed the owner, repository or project identifier supplied up front, with nothing to look them up with.
GitHub connections have a Test connection check. It reports which account the configured token acts as, so a settings page can confirm a connection works before anything depends on it.
A GitLab connection asks for the callback address your deployment serves. Registering an application gives you an id, a secret and a redirect address; all three are now collected together. Previously only a callback on the same machine could be described, so a hosted installation had nowhere to record the address it actually serves and found out only when a sign-in attempt was rejected.
A connection can say whose permissions a credential carries. Credentials that act as the integration itself are now distinguishable from credentials that act on behalf of a specific person. Where that has not been reviewed yet it says so plainly rather than guessing, so nothing is quietly treated as more or less privileged than it is.
A credential can declare that the way it is obtained is weak. A deployment can then refuse that method by property rather than by name, and refusing is the default.
Action needed
If you build against the credential or configuration data directly, three additions need handling. Credentials now describe whose permissions they carry and how they are obtained, and configuration fields can name additional services they apply to. Code that lists every possible credential type, or constructs these entries by hand, needs updating. Reading the data is unaffected.
Catalogue: 835 operations across 55 connectors and 67 services, 1110 committed artifacts.
Engineering detail, including the reasoning behind each decision, is in CHANGELOG.md.