Context
spp_attendance (migrated in the referenced PR) is a standalone, API-first attendance service and
is currently the only v1-style spp_oauth API in OpenSPP2 — every other API surface lives on
spp_api_v2 (FastAPI, spp.api.client, rate-limited token endpoint, RFC 9457 errors, audit,
consent-awareness). The migration deliberately preserved the v1 wire contract for deployed clients
and kept the module self-contained (deps: base, spp_oauth, spp_security only).
This issue tracks the deferred alignment items. Revisit after PR #114 (spp_oauth stabilization +
spp_api_v2_oauth RS256 bridge) lands, since it defines the pattern for optional bridge modules.
Deferred items
- API v2 alignment strategy — decide whether spp_attendance gets an optional bridge module
(à la spp_api_v2_oauth, auto-installing when spp_api_v2 is present) exposing the attendance
API through the v2 stack, while the standalone v1 core keeps working on bare instances.
- RFC 9457 error responses — the v1 endpoints use a custom
{"error": {"code", "message"}} shape. Aligning is a breaking wire change for deployed
clients, so it belongs to the v2 surface (item 1), not a patch of v1.
- DELETE /attendances hardening — the delete endpoint hard-deletes records for any valid
token. Scoped-token authorization (and/or soft-delete) should come with the v2 surface;
interim mitigation is operational (issue delete-capable credentials sparingly).
- Token endpoint rate limiting — the v1
/auth/token mint has no throttling;
spp_api_v2's token endpoint pattern (rate limiting) is the reference.
- Enumeration-shaped error messages —
validate_entity helpfully lists all available
type/location ids in its 400 message. Harmless for types/locations today, but the pattern
shouldn't spread; tighten when touching the controller for v2.
Non-goals
Secret storage is already fixed in the migration PR (scrypt show-once + migration hashing existing
secrets); the spp_session_tracking positioning is documented in the module DESCRIPTION.
Context
spp_attendance(migrated in the referenced PR) is a standalone, API-first attendance service andis currently the only v1-style
spp_oauthAPI in OpenSPP2 — every other API surface lives onspp_api_v2(FastAPI,spp.api.client, rate-limited token endpoint, RFC 9457 errors, audit,consent-awareness). The migration deliberately preserved the v1 wire contract for deployed clients
and kept the module self-contained (deps:
base,spp_oauth,spp_securityonly).This issue tracks the deferred alignment items. Revisit after PR #114 (spp_oauth stabilization +
spp_api_v2_oauthRS256 bridge) lands, since it defines the pattern for optional bridge modules.Deferred items
(à la
spp_api_v2_oauth, auto-installing whenspp_api_v2is present) exposing the attendanceAPI through the v2 stack, while the standalone v1 core keeps working on bare instances.
{"error": {"code", "message"}}shape. Aligning is a breaking wire change for deployedclients, so it belongs to the v2 surface (item 1), not a patch of v1.
token. Scoped-token authorization (and/or soft-delete) should come with the v2 surface;
interim mitigation is operational (issue delete-capable credentials sparingly).
/auth/tokenmint has no throttling;spp_api_v2's token endpoint pattern (rate limiting) is the reference.validate_entityhelpfully lists all availabletype/location ids in its 400 message. Harmless for types/locations today, but the pattern
shouldn't spread; tighten when touching the controller for v2.
Non-goals
Secret storage is already fixed in the migration PR (scrypt show-once + migration hashing existing
secrets); the
spp_session_trackingpositioning is documented in the module DESCRIPTION.