Module admin 

Administrative operations, shared by both front ends and owned by neither.

crate::cli and crate::webadmin are the two front ends; everything they can do lives here, so the password policy, the duplicate check and the rehash-on-login cannot drift between a terminal and a browser.

• ops — the operations themselves (accounts, orders, EAB, nonces, audit).
• render — one JSON renderer per shape, surfacing the admin-only fields (an order’s revocation, an account’s traceability columns) the ACME wire format deliberately does not carry. JSON only: both front ends parse these, so they are a wire format. The human-readable renderings have exactly one consumer and live in crate::cli::render, which is where colour is woven in — and therefore cannot reach a --json shape.
• password, users — the credential store and the KDF.
• totp, recovery, mfa — the second factor: RFC 6238 over RFC 4226, single-use recovery codes, and where those two meet the database.
• prompt — confirmation, over an injectable reader so it is testable.

Destructive operations come in pairs: a bare form, and a confirm_* wrapper taking assume_yes and a reader. Those two arguments are a terminal’s concern, so the CLI calls the wrapper and the web calls the bare form — rather than an HTTP caller passing true and an empty reader to assert a confirmation that never happened.

Re-exports

pub use ops::*;

pub use prompt::*;

pub use render::*;

Modules

mfa

The second-factor operations, which both front ends dispatch to and neither owns.

ops

password

Password hashing for the web admin’s operators.

prompt

recovery

Recovery codes: the way back in when the phone holding the TOTP secret is gone.

render

The JSON renderings, shared by both front ends.

totp

RFC 6238 time-based one-time passwords, over RFC 4226’s HOTP.

users

Operator management for the web admin: create, list, re-password, enable, disable, delete, and the password check the login path runs.