HectorMRC/rauth

This system is a Rust-based authentication and user-management service that exposes session and user operations over both gRPC and REST. It supports account signup, email verification, password reset, account deletion, and TOTP two-factor authentication, while persisting users, secrets, and metadata in Postgres and using Redis for token or session state. It also publishes user-created events to RabbitMQ, sends email through SMTP, and is packaged as containerized gRPC and REST processes.

3 changes.

This period was focused on defining the authentication and user-management surface for rauth, adding proto contracts for session login/logout and user signup, reset, deletion, and TOTP operations. It also introduced the Rust dependency manifest for the rauth package, pinning core libraries and optional integrations for gRPC, REST, Postgres, RabbitMQ, and Redis, while many repo-wide changes and fixes touched session-related behavior.

5 changes.

This period built the shared Rust library layer for an authenticator, adding modules for cryptography, configuration, email handling, validation, and error handling. It introduced user account management with signup, email verification, password reset, deletion, and TOTP support, along with Postgres-backed metadata and secret storage and a script to assemble database setup files.

4 changes.

This period established the core runtime and data model for an authentication service, adding database tables for users, metadata, and immutable secrets along with Redis configuration for bounded token storage. It also introduced container build definitions and separate REST and gRPC server entrypoints, wiring repositories, token storage, an event bus, mailer configuration, and session logic into deployable services.

This change adds new runnable server entrypoints for the authentication service: a REST server built with Actix Web that exposes the session REST service, and a gRPC server built with tonic that exposes user and session gRPC services. The gRPC entrypoint wires together Postgres metadata, secret, and user repositories, Redis token storage, a RabbitMQ user event bus, SMTP mailer configuration, and token/session application logic, while the REST entrypoint wires token storage and the session service. Both entrypoints load environment configuration through dotenv and use tracing for logging, giving operators separate processes for the REST and gRPC APIs.

src/bin · high confidence

A new build\_db\_setup\_script.py script can generate a single database setup script by scanning a migrations directory, selecting files that match a configured pattern, and concatenating their contents in sorted order into a target SQL file. By default it looks in ./migrations for files matching up.sql and writes to ./migrations/.postgres/setup.sql, but the migrations path, target path, and file pattern can be configured through environment variables. This makes database setup generation more repeatable and less dependent on manually maintaining one combined SQL file.

scripts · high confidence

Adds containerfile definitions for the gRPC and REST components, creating multi-stage images that build the Rust binaries and run them as a non-root appuser in a Debian slim runtime. This makes containerized deployment of the gRPC and REST services available, while the shown change is limited to the added container files and does not include the event, RabbitMQ, or REST implementation changes suggested by the commit messages.

container · medium confidence

This adds a dedicated user-management layer to the system. It introduces a User domain model (validating email and Base64 password format, with name defaulting to the email), application logic for signing up, verifying a signup via an emailed token, resetting a password, deleting an account, and enabling/disabling TOTP two-factor authentication (with password and TOTP checks enforced before destructive actions). It exposes these operations through a gRPC service (signup, reset, delete, and TOTP handlers), persists users in Postgres via a repository, and publishes a 'user created' event to RabbitMQ through an event bus. For a product reader, this means the platform can now create and manage user accounts end-to-end — including email verification, password reset, account deletion, and two-factor authentication — and can notify downstream consumers when a new account is created.

src/user · high confidence

This change introduces a dedicated secret module with a Secret domain model and an async SecretRepository interface, including a Postgres-backed implementation that can create secrets, find them by id or by user and name, update them, save changes, and delete them. It also adds a mock repository for tests and wires the module through a new src/secret entry point. For users, this establishes the internal foundation for storing and retrieving secrets through a Postgres-backed repository, though the diff does not show user-facing endpoints or UI.

src/secret · medium confidence

The proto definitions now introduce a Session service with Login and Logout operations, where Login accepts an identifier, password, and TOTP code, and a User service with Signup, Reset, Delete, and Totp operations. The user contract supports email/password signup, password reset with TOTP, account deletion with password and TOTP, and enabling or disabling TOTP. These new proto3 definitions establish the API surface for authentication and user management, though the diff shows only the contract definitions and not implementation or runtime behavior.

proto · medium confidence

New migrations introduce the Metadata, Users, and Secrets tables. Users now store name, email, actual email, password, and a metadata reference, while Secrets store a name and data value per user with a unique name-per-user constraint and a metadata reference. A database trigger also prevents updates to a secret's id, name, data, or user, making those fields immutable after creation.

migrations · medium confidence

The src tree introduces a new shared library layer for the authenticator, adding modules for base64 decoding, environment-driven configuration, JWT/TOTP/RSA cryptography, email suffix handling, gRPC and REST header extraction, SMTP template sending, regex validation, custom error codes, and time utilities. This establishes the common foundation used by the service’s authentication, session, secret, and email flows.

src · medium confidence

The metadata area now has a dedicated module with a Metadata record containing id, created\_at, updated\_at, and deleted\_at, plus an async MetadataRepository interface for find, create, save, and delete operations. A Postgres-backed implementation is included behind the postgres feature, using sqlx to insert, query, update, and delete metadata rows, while a mock repository is provided for tests. This standardizes how metadata is persisted and makes the metadata module testable, though the diff does not show it wired into a user-facing workflow.

src/metadata · medium confidence

A change to existing behaviour in (repo-wide) — 166 commits (11 fixs), 7 files.

(repo-wide), src/session · low confidence · unverified

A new Redis configuration file sets a 2 MB memory limit, enables allkeys-lru eviction when memory is reached, and caps the tracking table at 1,000,000 keys. This makes Redis usage more predictable and prevents unbounded memory growth by evicting least-recently-used keys under pressure.

redis · medium confidence

The new Cargo.toml for the rauth package pins core dependencies such as tokio 1.28.2, serde 1.0.164, jsonwebtoken 8.3.0, base64 0.21.2, chrono 0.4.26, regex 1.8.4, and tracing 0.1, and declares optional integration crates including actix-web 4.3.1, tonic 0.9.2, prost 0.11.9, protoc 2.28.0, sqlx 0.6.3, redis 0.23.0, reool 0.30.0, deadpool-lapin 0.10.0, and lapin 2.2.1. It also sets default features to config, grpc, rest, postgres, rabbitmq, and redis-cache, so the manifest defines the dependency set and feature-gated integrations available for building the project.

(dependencies) · medium confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 56 → 59 (+3.1)
• Rubric changed (rubric-2026.08.20 → rubric-2026.09.16) — scores are not directly comparable.

• Code Health 100 → 99 (-1.4)
• Architecture 98 → 93 (-4.2)
• Maturity 45 → 45 (+0.0)
• Readiness 73 → 73 (-0.7)
• Security 44 → 55 (+10.8)
• Domain Modelling 100 → 100 (+0.0)
• Performance 100 (new)

• Coverage not included — suite not readable by the collector
• Dependency hygiene not measured — dependency manifest found but not parsed for hygiene
• No exposed public API
• Test reliability not included
• dormant codebase — no living knowledge left to concentrate

• Dependency hygiene PARTLY measured — Cargo dependencies read, no committed lock to grade for currency
• Duplicated block (10 lines × 3) (src/user/application.rs)
• Duplicated block (11 lines × 2) (src/secret/repository.rs)
• Duplicated block (12 lines × 2) (src/metadata/repository.rs)
• Duplicated block (14 lines × 2) (src/secret/repository.rs)
• Duplicated block (15 lines × 2) (src/metadata/repository.rs)
• Duplicated block (16 lines × 2) (src/session/application.rs)
• Duplicated block (19 lines × 2) (src/user/application.rs)
• Duplicated block (6 lines × 2) (src/smtp.rs)
• Duplicated block (6 lines × 3) (src/user/application.rs)
• Duplicated block (8 lines × 2) (src/crypto.rs)
• Duplicated block (8 lines × 2) (src/user/application.rs)
• Duplicated block (9 lines × 2) (src/session/grpc.rs)
• Inconsistent naming for ID accessors. Most entities use 'get_id()', but 'SignedToken' uses 'id()' (no 'get_' prefix) and 'TokenDefinition' uses 'get_id()'. While minor, this breaks the pattern established by the majority of domain entities.
• Inconsistent naming for ID-based retrieval. While 'find' is used here, other repositories like 'TokenRepository' use 'find(key: str)' which is consistent, but the domain entities have 'get_id()' methods. More critically, if 'find' returns a Result, it's unclear if it returns Option<T> inside the Result or if the Result itself indicates NotFound. However, the primary inconsistency is the lack of a standard 'get' vs 'find' convention across the board if other methods existed, but here the main issue is the 'create'/'save' duplication above. A secondary inconsistency is 'TokenRepository.find(key: str)' vs others 'find(id: i32)' - while keys differ, the method name 'find' is consistent. The real issue is the 'create'/'save' duplication.
• Medium IaC: WD-COMPOSE-0002 (compose.yaml)
• Medium IaC: WD-COMPOSE-0002 (compose.yaml)
• Medium IaC: WD-COMPOSE-0002 (compose.yaml)
• Medium IaC: WD-COMPOSE-0002 (compose.yaml)
• Medium IaC: WD-COMPOSE-0002 (compose.yaml)
• …and 10 more

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

HectorMRC/rauth was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.