Kyle Isom
59d51a1d38
- proto/mcias/v1/: AdminService, AuthService, TokenService, AccountService, CredentialService; generated Go stubs in gen/ - internal/grpcserver: full handler implementations sharing all business logic (auth, token, db, crypto) with REST server; interceptor chain: logging -> auth (JWT alg-first + revocation) -> rate-limit (token bucket, 10 req/s, burst 10, per-IP) - internal/config: optional grpc_addr field in [server] section - cmd/mciassrv: dual-stack startup; gRPC/TLS listener on grpc_addr when configured; graceful shutdown of both servers in 15s window - cmd/mciasgrpcctl: companion gRPC CLI mirroring mciasctl commands (health, pubkey, account, role, token, pgcreds) using TLS with optional custom CA cert - internal/grpcserver/grpcserver_test.go: 20 tests via bufconn covering public RPCs, auth interceptor (no token, invalid, revoked -> 401), non-admin -> 403, Login/Logout/RenewToken/ValidateToken flows, AccountService CRUD, SetPGCreds/GetPGCreds AES-GCM round-trip, credential fields absent from all responses Security: JWT validation path identical to REST: alg header checked before signature, alg:none rejected, revocation table checked after sig. Authorization metadata value never logged by any interceptor. Credential fields (PasswordHash, TOTPSecret*, PGPassword) absent from all proto response messages — enforced by proto design and confirmed by test TestCredentialFieldsAbsentFromAccountResponse. Login dummy-Argon2 timing guard preserves timing uniformity for unknown users (same as REST handleLogin). TLS required at listener level; cmd/mciassrv uses credentials.NewServerTLSFromFile; no h2c offered. 137 tests pass, zero race conditions (go test -race ./...)
The project notes are in PROJECT.md.
Before starting the project, read the project description and develop a system architecture document (ARCHITECTURE.md). It should describe the technical design of the system. Then, PROJECT_PLAN.md should be written that describes how to build this system in discrete steps.
Commit these files to Git after human review. For this project, all git commits should have a single first line, no more than 55 characters, that succinctly describes an overview of the changes. As necessary, the body of the commit message should contain bullets describing the work that was done.
Then, create PROGRESS.md. This should be initialized with the first steps for the project.
The development process for this should generally be:
- Determine the current state of the project. Track the progress in PROGRESS.md, explicitly stating what was done and next steps.
- Develop reasonable, discrete next steps to move forward with actionable acceptance criteria.
- Complete the next steps.
- You should adversarially check whether any outputs are correct.
- All code units should be thoroughly unit tested.
- All subsystems should be thoroughly integration tested.
- Where appropriate, end-to-end tests to validate the system should be developed.
- All code changes must pass golangci-lint checks.
- After each phase, checkpoint your work, committing it to git.
Repeat this cycle until the system is in the desired end state.