@things-factory/auth-base 10.1.278 → 10.1.280

package/tests/appliance-delete-db.test.ts

@@ -1,119 +0,0 @@
-/**
- * Deleting an appliance stays inside the tenant that asked.
- *
- * ── The order the deletes happen in ─────────────────────────────────────────
- * An appliance is two rows: the appliance itself, which carries a domain, and a shadow `User`
- * standing in for the device, which is found by `reference` and carries no tenant of its own.
- *
- * `deleteAppliance` deleted the shadow user first and scoped only the appliance row afterwards.
- * So an id belonging to somebody else deleted their device's identity and then failed to delete
- * their appliance — the row stayed on their screen looking registered, and the device behind it
- * stopped at the next request, because `checkAuth` looks the subject up by the id in the token
- * and there was no longer a subject. Nothing in the answer said so: the mutation returns true.
- *
- * ⚠ sqlite (`tests/db.ts`).
- */
-
-import { closeAuthDatabase, Domain, getRepository, openAuthDatabase, resetAuthDatabase } from './db'
-import { loadCompiled } from './compiled'
-
-const { Appliance } = loadCompiled('service/appliance/appliance')
-const { User, UserStatus } = loadCompiled('service/user/user')
-const { ApplianceMutation } = loadCompiled('service/appliance/appliance-mutation')
-
-const mutation = new ApplianceMutation()
-
-let ours: any
-let theirs: any
-let actor: any
-
-function context(d: any) {
-  return {
-    state: { domain: d, user: actor, tx: undefined },
-    throw: (code: number, message: string) => {
-      const error: any = new Error(message)
-      error.status = code
-      throw error
-    }
-  } as any
-}
-
-async function register(name: string, d: any) {
-  return await mutation.createAppliance({ name, serialNo: `${name}-SN`, brand: 'Acme', model: 'X1' }, context(d))
-}
-
-async function shadowUserOf(applianceId: string) {
-  return await getRepository(User).findOneBy({ reference: applianceId, userType: 'appliance' })
-}
-
-beforeAll(async () => {
-  await openAuthDatabase()
-})
-
-afterAll(async () => {
-  await closeAuthDatabase()
-})
-
-beforeEach(async () => {
-  await resetAuthDatabase()
-
-  ours = await getRepository(Domain).save({ name: 'acme', subdomain: 'acme' })
-  theirs = await getRepository(Domain).save({ name: 'beta', subdomain: 'beta' })
-  actor = await getRepository(User).save({
-    username: 'operator@acme.z',
-    email: 'operator@acme.z',
-    name: 'operator',
-    status: UserStatus.ACTIVATED,
-    domains: [ours]
-  })
-})
-
-describe('deleting our own appliance', () => {
-  it('takes the appliance and its shadow user', async () => {
-    const appliance = await register('gate-a', ours)
-    await mutation.generateApplianceSecret(appliance.id, context(ours))
-
-    await mutation.deleteAppliance(appliance.id, context(ours))
-
-    expect(await getRepository(Appliance).findOneBy({ id: appliance.id })).toBeNull()
-    expect(await shadowUserOf(appliance.id)).toBeNull()
-  })
-})
-
-describe('an id that belongs to another tenant', () => {
-  it('leaves their appliance where it is', async () => {
-    const foreign = await register('their-gate', theirs)
-
-    await mutation.deleteAppliance(foreign.id, context(ours))
-
-    expect(await getRepository(Appliance).findOneBy({ id: foreign.id })).not.toBeNull()
-  })
-
-  it('leaves their device able to authenticate', async () => {
-    /*
-     * ⚠ The case. Deleting the shadow user before checking the tenant stopped somebody else's
-     * device while leaving their appliance row on screen looking registered — no screen would
-     * show what happened, and the fix from their side is to issue a new secret for a device
-     * that had a working one.
-     */
-    const foreign = await register('their-gate', theirs)
-    const issued = await mutation.generateApplianceSecret(foreign.id, context(theirs))
-
-    await mutation.deleteAppliance(foreign.id, context(ours))
-
-    expect(await shadowUserOf(foreign.id)).not.toBeNull()
-
-    const jwt = require('jsonwebtoken')
-    await expect(User.checkAuth(jwt.decode(issued.accessToken))).resolves.toBeTruthy()
-  })
-
-  it('does not take ours down with it either way', async () => {
-    const mine = await register('gate-a', ours)
-    const foreign = await register('their-gate', theirs)
-
-    await mutation.deleteAppliance(foreign.id, context(ours))
-
-    expect(await getRepository(Appliance).findOneBy({ id: mine.id })).not.toBeNull()
-    expect(await shadowUserOf(mine.id)).not.toBeNull()
-  })
-})

package/tests/appliance-revoke-db.test.ts

@@ -1,294 +0,0 @@
-/**
- * `revokeApplianceCredential` — taking a device's access away while keeping the device.
- *
- * ── What was missing ────────────────────────────────────────────────────────
- * There was no way to leave an appliance without a working credential. You could delete the
- * row, which takes its history with it, or issue a new secret, which puts a **live** credential
- * in the database and on the screen. Neither is revocation.
- *
- * ── Why the status is the switch, not the field ─────────────────────────────
- * The access token is a signed JWT. Clearing `Appliance.accessToken` drops our copy and does
- * nothing to the token already on the device — it keeps verifying against SECRET until its own
- * `exp`, a year out. `User.checkAuth` is what refuses it, and it refuses on the shadow user's
- * status. So these tests assert the status; the cleared fields are tidiness, and one case says
- * so explicitly because the opposite is easy to assume.
- *
- * ⚠ sqlite (`tests/db.ts`). Enum columns fall to the varchar branch here, so this pins the
- * value that is stored and read back, not the dialect's own enum behaviour.
- */
-
-import { config } from '@things-factory/env'
-
-import { closeAuthDatabase, Domain, getRepository, openAuthDatabase, resetAuthDatabase } from './db'
-import { loadCompiled } from './compiled'
-
-const jwt = require('jsonwebtoken')
-
-const { Appliance } = loadCompiled('service/appliance/appliance')
-const { User, UserStatus } = loadCompiled('service/user/user')
-const { ApplianceMutation } = loadCompiled('service/appliance/appliance-mutation')
-
-const mutation = new ApplianceMutation()
-
-let domain: any
-let actor: any
-
-function context(d: any = domain) {
-  return {
-    state: { domain: d, user: actor, tx: undefined },
-    throw: (code: number, message: string) => {
-      const error: any = new Error(message)
-      error.status = code
-      throw error
-    }
-  } as any
-}
-
-async function shadowUserOf(applianceId: string) {
-  return await getRepository(User).findOneBy({ reference: applianceId, userType: 'appliance' })
-}
-
-async function makeAppliance(name: string) {
-  const appliance = await mutation.createAppliance(
-    { name, serialNo: `${name}-SN`, brand: 'Acme', model: 'X1' },
-    context()
-  )
-
-  /* Registering does not issue a token; the screen shows "not issued" until someone asks. */
-  return await mutation.generateApplianceSecret(appliance.id, context())
-}
-
-/*
- * Revocation is off unless the installation asks for it (ADR-0085 decision 2), so these cases
- * turn it on. `credential-features.ts` reads the config on each call, which is what lets a test
- * stand in for a configured installation.
- *
- * `credential-features-off.test.ts` holds the other side — what an installation that configures
- * nothing sees.
- */
-const configGet = config.get
-
-beforeAll(async () => {
-  config.get = ((key: string, fallback?: any) =>
-    key === 'credential/revocable' ? true : configGet(key, fallback)) as typeof config.get
-
-  await openAuthDatabase()
-})
-
-afterAll(async () => {
-  config.get = configGet
-  await closeAuthDatabase()
-})
-
-beforeEach(async () => {
-  await resetAuthDatabase()
-
-  domain = await getRepository(Domain).save({ name: 'acme', subdomain: 'acme' })
-  actor = await getRepository(User).save({
-    username: 'operator@acme.z',
-    email: 'operator@acme.z',
-    name: 'operator',
-    status: UserStatus.ACTIVATED,
-    domains: [domain]
-  })
-})
-
-describe('revoking an appliance credential', () => {
-  it('leaves the appliance, and leaves it with nothing to authenticate with', async () => {
-    const issued = await makeAppliance('gate-a')
-
-    expect(issued.accessToken).toBeTruthy()
-    expect((await shadowUserOf(issued.id))!.status).toEqual(UserStatus.ACTIVATED)
-
-    const revoked = await mutation.revokeApplianceCredential(issued.id, context())
-
-    /* The record survives — that is the whole difference from deleteAppliance. */
-    expect(revoked.id).toEqual(issued.id)
-    expect(revoked.name).toEqual('gate-a')
-    expect(await getRepository(Appliance).findOneBy({ id: issued.id })).toBeTruthy()
-
-    expect(revoked.accessToken).toBeNull()
-  })
-
-  it('turns the shadow user inactive — the switch every request reads', async () => {
-    /*
-     * ⚠ The case the feature exists for. `checkAuth` throws USER_NOT_ACTIVATED on INACTIVE, so
-     * this is what refuses the token that is already out on the device. Without it the cleared
-     * field means nothing: the JWT verifies on its signature alone.
-     */
-    const issued = await makeAppliance('gate-b')
-
-    await mutation.revokeApplianceCredential(issued.id, context())
-
-    const appuser = await shadowUserOf(issued.id)
-
-    expect(appuser).toBeTruthy()
-    expect(appuser!.status).toEqual(UserStatus.INACTIVE)
-  })
-
-  it('moves the credential serial, which is what a status alone cannot do', async () => {
-    /*
-     * ⚠ The serial is the half of revocation that cannot be undone by putting the status back.
-     * Its effect shows up in `checkAuth` (ADR-0085 decision 4), so until that lands nothing else
-     * here would notice if the bump went missing — this case watches the column directly.
-     */
-    const issued = await makeAppliance('gate-s')
-    const before = (await shadowUserOf(issued.id))!.credentialSerial
-
-    expect(before).toEqual(1)
-
-    await mutation.revokeApplianceCredential(issued.id, context())
-
-    expect((await shadowUserOf(issued.id))!.credentialSerial).toEqual(before + 1)
-  })
-
-  it('moves it again on the next issue, so no generation is reused', async () => {
-    const issued = await makeAppliance('gate-t')
-
-    await mutation.revokeApplianceCredential(issued.id, context())
-    await mutation.generateApplianceSecret(issued.id, context())
-
-    expect((await shadowUserOf(issued.id))!.credentialSerial).toEqual(3)
-  })
-
-  it('keeps the shadow user rather than deleting it', async () => {
-    /*
-     * `deleteAppliance` deletes it, and that is right when the appliance goes too. Here the
-     * appliance stays, so the identity has to stay with it — past rows point at it as creator
-     * and updater, and re-issuing keeps the same id rather than orphaning them.
-     */
-    const issued = await makeAppliance('gate-c')
-    const before = await shadowUserOf(issued.id)
-
-    await mutation.revokeApplianceCredential(issued.id, context())
-
-    const after = await shadowUserOf(issued.id)
-
-    expect(after).toBeTruthy()
-    expect(after!.id).toEqual(before!.id)
-  })
-
-  it('stops holding a copy of the credential it just killed', async () => {
-    /*
-     * Tidiness, not a control — and worth saying so, because the opposite is easy to believe.
-     * The JWT verifies on its signature, never against this column, so clearing it does not
-     * stop the token on the device. The status does that.
-     *
-     * ⚠ Which leaves a real hazard this does NOT close: put the status back to ACTIVATED
-     * without issuing a new secret and the old token authenticates again, cleared column or
-     * not. Nothing here prevents that. Closing it needs the token itself to be refusable —
-     * a jti denylist, or re-issuing as part of reactivation.
-     */
-    const issued = await makeAppliance('gate-d')
-
-    expect((await shadowUserOf(issued.id))!.password).toBeTruthy()
-
-    await mutation.revokeApplianceCredential(issued.id, context())
-
-    expect((await shadowUserOf(issued.id))!.password).toBeNull()
-  })
-
-  it('lets a new secret work afterwards', async () => {
-    /*
-     * A revoked appliance is INACTIVE, and `checkAuth` refuses that whatever the token says. So
-     * issuing again has to put the status back, or the new credential is dead on arrival — a
-     * failure that would look like the token being wrong.
-     */
-    const issued = await makeAppliance('gate-e')
-    await mutation.revokeApplianceCredential(issued.id, context())
-
-    const reissued = await mutation.generateApplianceSecret(issued.id, context())
-
-    expect(reissued.accessToken).toBeTruthy()
-
-    const appuser = await shadowUserOf(issued.id)
-
-    expect(appuser!.status).toEqual(UserStatus.ACTIVATED)
-    expect(appuser!.password).toEqual(reissued.accessToken)
-  })
-
-  it('does not hand back the token it just revoked, even re-issued in the same second', async () => {
-    /*
-     * This used to pin a defect. The payload carried `{ id, userType, appliance.id, status,
-     * domain.subdomain }` and nothing else, and `iat` counts whole seconds, so two signings
-     * inside one second produced a byte-identical string — revoking and immediately re-issuing,
-     * which is the obvious way to rotate a suspect device, handed back the credential just
-     * revoked.
-     *
-     * The credential serial closes it: it moves on every issue and every revoke, and it is in
-     * the payload, so no two issues can produce the same token.
-     */
-    const issued = await makeAppliance('gate-g')
-
-    await mutation.revokeApplianceCredential(issued.id, context())
-    const reissued = await mutation.generateApplianceSecret(issued.id, context())
-
-    expect(reissued.accessToken).not.toEqual(issued.accessToken)
-
-    /* And the reason is the serial, not the clock — the two tokens name different generations. */
-    expect(jwt.decode(reissued.accessToken).cs).toBeGreaterThan(jwt.decode(issued.accessToken).cs)
-  })
-
-  it('refuses an appliance that belongs to another domain', async () => {
-    /*
-     * Revocation stops a device. Reaching across a tenant boundary with it would let one
-     * customer turn off another's equipment.
-     */
-    const issued = await makeAppliance('gate-f')
-    const stranger = await getRepository(Domain).save({ name: 'other', subdomain: 'other' })
-
-    await expect(mutation.revokeApplianceCredential(issued.id, context(stranger))).rejects.toThrow()
-
-    const appuser = await shadowUserOf(issued.id)
-
-    expect(appuser!.status).toEqual(UserStatus.ACTIVATED)
-  })
-})
-
-describe('what an already-issued token can still do', () => {
-  /*
-   * The token is a signed JWT. `checkAuth` is the only thing that looks at our records once the
-   * signature verifies, so these cases run the real token through the real function rather than
-   * reasoning about it.
-   */
-  function decode(token: string) {
-    return jwt.decode(token)
-  }
-
-  it('is refused while the appliance is revoked', async () => {
-    const issued = await makeAppliance('gate-h')
-
-    await expect(User.checkAuth(decode(issued.accessToken))).resolves.toBeTruthy()
-
-    await mutation.revokeApplianceCredential(issued.id, context())
-
-    await expect(User.checkAuth(decode(issued.accessToken))).rejects.toThrow()
-  })
-
-  it('stays refused when the status goes back, because the serial moved', async () => {
-    /*
-     * This used to pin a hazard. Revocation lived entirely in the shadow user's status, so
-     * putting the status back — by hand, by a fixture, by some future screen — let every token
-     * ever issued to that appliance work again. Clearing the stored copy did not help: the JWT
-     * verifies on its signature and never against that column.
-     *
-     * The serial closes it. It moved on revoke and does not move back, so the old token names a
-     * generation this subject has left. Access can only come from issuing a new one.
-     */
-    const issued = await makeAppliance('gate-i')
-    const oldToken = issued.accessToken
-
-    await mutation.revokeApplianceCredential(issued.id, context())
-    await expect(User.checkAuth(decode(oldToken))).rejects.toThrow()
-
-    const appuser = await shadowUserOf(issued.id)
-    await getRepository(User).save({ ...appuser, status: UserStatus.ACTIVATED })
-
-    await expect(User.checkAuth(decode(oldToken))).rejects.toThrow()
-
-    /* And a freshly issued one does work — the subject is usable again, its old tokens are not. */
-    const reissued = await mutation.generateApplianceSecret(issued.id, context())
-
-    await expect(User.checkAuth(decode(reissued.accessToken))).resolves.toBeTruthy()
-  })
-})

package/tests/appliance-schema.test.ts

@@ -1,129 +0,0 @@
-/**
- * The appliance resolvers make a schema, and the two new fields carry the gate they meant to.
- *
- * ── Why a schema test and not another unit test ─────────────────────────────
- * `credentialRevoked` is a field with no column behind it and `applianceCredentialRevocable` is
- * a Query on a resolver whose other methods all return objects. Both are the shapes that build
- * fine in TypeScript and fail when type-graphql reads the decorators — an inferred type it
- * cannot resolve takes the whole schema down, and a schema that does not build is a server that
- * comes up without its doors (`reference_resolver_load_failure_leaves_server_half_up`).
- *
- * ── What the gate assertion is for ──────────────────────────────────────────
- * `applianceCredentialRevocable` exists so a screen can ask "would pressing revoke work for
- * me". That answer is only worth anything if the query is refused in the same cases the
- * mutation is, so the two declarations have to stay identical. Nothing else would notice them
- * drifting apart: the query would simply start answering people who cannot act on it, and the
- * button would appear and then refuse.
- */
-
-import { buildSchema } from 'type-graphql'
-import { GraphQLSchema } from 'graphql'
-
-import { loadCompiled } from './compiled'
-
-const { ApplianceQuery } = loadCompiled('service/appliance/appliance-query')
-const { ApplianceMutation } = loadCompiled('service/appliance/appliance-mutation')
-const { ApplicationQuery } = loadCompiled('service/application/application-query')
-const { ApplicationMutation } = loadCompiled('service/application/application-mutation')
-const { AppBindingQuery } = loadCompiled('service/app-binding/app-binding-query')
-const { AppBindingMutation } = loadCompiled('service/app-binding/app-binding-mutation')
-const { privilegeDirectiveResolver, privilegeOfField } = loadCompiled('service/privilege/privilege-directive')
-
-let schema: GraphQLSchema
-
-beforeAll(async () => {
-  schema = await buildSchema({
-    resolvers: [
-      ApplianceQuery,
-      ApplianceMutation,
-      ApplicationQuery,
-      ApplicationMutation,
-      AppBindingQuery,
-      AppBindingMutation
-    ],
-    validate: false
-  })
-
-  /* The map of what each field asks for is filled in while the directive walks the schema. */
-  privilegeDirectiveResolver(schema)
-})
-
-describe('the schema builds', () => {
-  it('has the query the screen asks before showing a revoke button', () => {
-    const field = schema.getQueryType()?.getFields()['applianceCredentialRevocable']
-
-    expect(field).toBeDefined()
-
-    /* Non-null: it always has an answer, and "no answer" would read as "no button". */
-    expect(String(field!.type)).toEqual('Boolean!')
-  })
-
-  it('has the field that separates revoked from never issued', () => {
-    const field = schema.getType('Appliance')?.['getFields']()['credentialRevoked']
-
-    expect(field).toBeDefined()
-
-    /*
-     * Nullable, unlike the query above. This field rides on the Appliance type, which is also
-     * what the mutations hand back, and a caller that does not ask for it should get a record
-     * without it rather than one asserting the credential is live. The screen reads absent as
-     * not revoked — `client/utils/credential-panel-state.ts` in auth-ui pins that.
-     */
-    expect(String(field.type)).toEqual('Boolean')
-  })
-
-  it('still has the door those two describe', () => {
-    expect(schema.getMutationType()?.getFields()['revokeApplianceCredential']).toBeDefined()
-  })
-})
-
-describe('the question is gated like the act it describes', () => {
-  it('asks for exactly what revoking asks for', () => {
-    /*
-     * ⚠ The pair that has to stay together. If the query opened up, it would answer yes to a
-     * reader the mutation refuses, and the screen would put a button in front of somebody who
-     * cannot press it.
-     */
-    const asking = privilegeOfField('Query', 'applianceCredentialRevocable')
-    const acting = privilegeOfField('Mutation', 'revokeApplianceCredential')
-
-    expect(asking.known).toBe(true)
-    expect(acting.known).toBe(true)
-    expect(asking['gate']).toEqual(acting['gate'])
-  })
-
-  it('is not an open field', () => {
-    /* `null` is how the map records a root field that declares nothing. */
-    expect(privilegeOfField('Query', 'applianceCredentialRevocable')['gate']).not.toBeNull()
-  })
-})
-
-describe('no door on a machine credential is left open', () => {
-  /*
-   * ⚠ The sweep this file exists for as much as for the two fields above. `deleteAppBinding`
-   * carried no privilege at all, and nothing noticed: an undeclared root field is recorded as
-   * open, so it reads exactly like a field somebody decided to open. The two app binding reads
-   * were the same.
-   *
-   * These three resources are one family — an appliance, an application, and a client bound to
-   * one — and every way in or out of them is a machine credential. So the assertion is on the
-   * whole family rather than on the doors that happen to be remembered.
-   */
-
-  /** Every root field these six resolvers put in the schema. */
-  function rootFields(typeName: string): string[] {
-    const type = typeName === 'Query' ? schema.getQueryType() : schema.getMutationType()
-
-    return Object.keys(type?.getFields() || {})
-  }
-
-  it.each(['Query', 'Mutation'])('%s', typeName => {
-    const open = rootFields(typeName).filter(field => {
-      const declared = privilegeOfField(typeName, field)
-
-      return declared.known && declared['gate'] === null
-    })
-
-    expect(open).toEqual([])
-  })
-})