uwe.admin/oatpp-authkit
1
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions

0 releases 21 tags

RSS feed
  • v0.12.0 9040a9ec48

    #14 PR 4: relocate users with temporal shape (Option B)

    u.schuster released this 2026-05-06 12:57:59 +02:00 | 4 commits to main since this release

    Lifts the auth-essential users table from fewo-webapp into oatpp-authkit
    in temporal form per Option B from the issue body. The previous shape
    (id INTEGER autoinc + is_active flag) is replaced with the entity_id +
    valid_from/valid_until triple; soft-delete via valid_until = now()
    instead of toggling is_active.

    New files (all in oatpp-authkit):

    • dto/UserDto.hpp — auth-essential columns only: id, entity_id, username,
      password_hash, role, tls_cert_dn, valid_from, valid_until. Registered
      as temporal so TemporalRepository composes cleanly. Application-
      specific columns (email, profile data) belong on a consumer-side DTO
      • parallel SchemaContract that contributes additional columns to the
        same users table.
    • db/UserDb.hpp — DbClient with login-path queries (findLiveByUsername,
      findLiveByTlsCertDn) plus generic CRUD. UserSchema declares the
      schema: TEXT id, entity_id, username, password_hash, role, tls_cert_dn,
      with natural-key UNIQUE on (username, valid_until) so no two live rows
      can share a username while historical rows for the same username are
      allowed.
    • repo/ConcreteUserRepository.hpp — Repository adapter +
      makeUserRepository factory wrapping in TemporalRepository.
    • test/test_user_schema.cpp — verifies SchemaBuilder<UserSchema,
      TemporalRepository>::create produces the expected 5 DDL
      statements; specifically asserts is_active and created_at are NOT
      present in the temporal shape (Option B replacement).

    13 of 13 tests pass. Bumped 0.11.0 → 0.12.0.

    Per owner directive on authkit#14: password_hash rides the temporal row.
    A separate security follow-up issue tracks the redaction policy for
    historical password hashes (likely blank the hash but keep the row so
    change-history is auditable).

    The migration of an existing non-temporal users table to this shape is
    documented in db/UserDb.hpp: Atlas-generated migration handles the
    structural conversion + backfill (each existing row becomes its own
    entity with entity_id = CAST(id AS TEXT)). Sessions/certificates FKs
    that referenced users.id (INTEGER) need rewiring to reference
    users.entity_id — that's a consumer-side rewire, separate PR.

    Closes #14 — the four migration sub-PRs (PR 1 role_templates, PRs 2+3
    permissions, PR 4 users) are now landed; the umbrella issue can close.
    Follow-ups (security hash redaction, fewo-webapp consumer migration,
    Atlas CI integration) get their own issues.

    Co-Authored-By: Claude Opus 4.7 (1M context) noreply@anthropic.com

    Downloads