SecurityActivityRecorder
Corex\Config\Activity\SecurityActivityRecorder · class · Config layer
Writes the security events the activity log was missing (spec 114, US-SAFE-13, FR-014). Mode changes, refusals of CoreX screens and sign-in lockouts were kept only in their own logs, so the Insights card that reads the activity log said “No security events recorded” on a site that had them. Each now adds one activity event: - operations.mode.changed (operations), when the mode store records a real change, from any route: the screen, the command line, a production launch; - access.denied (access), when the access log opens a new counted entry: a page reloaded a thousand times in an hour is one entry there (spec 112) and one event here; - security.login.locked (security), when login protection locks a sign-in out. It keeps when the lock ends, not the username that was typed nor the visitor’s address. Access-request decisions were already written by the access service. Each write is the record of something another part of CoreX has already done, so one that fails is let go: a mode change or a refusal never fails because its record could not be kept.
Public API
Section titled “Public API”__construct(ActivityService $activity, AccessUserDirectory $users, ListenerProvider $listeners, SecurityEventsSince $since, OperationsMode $modes)
Section titled “__construct(ActivityService $activity, AccessUserDirectory $users, ListenerProvider $listeners, SecurityEventsSince $since, OperationsMode $modes)”register(): void
Section titled “register(): void”modeChanged(string $from, string $to, int $userId): void
Section titled “modeChanged(string $from, string $to, int $userId): void”refused(int $userId, string $kind, string $section): void
Section titled “refused(int $userId, string $kind, string $section): void”The access log’s new entry: recorded as it is opened, in the request that was refused.