WordPressCustomerAuthRepository.php

Source file: wordpress/hslg-app-api/src/database/WordPressCustomerAuthRepository.php

Module: wordpress-hslg-app-api

Size: 171 lines

SHA-256: e7138ff08896da4e6fd67fa30fcb3b1becd066eb038267c80177727bbf5d84d9

Responsibility

Hosts independently deployable HSLG-owned API endpoints and schema operations on WordPress/MariaDB.

Declared entry points

• WordPressCustomerAuthRepository — source line 15.
• __construct — source line 17.
• sql — source line 18.
• write — source line 22.
• row — source line 28.
• email — source line 36.
• password — source line 44.
• account — source line 50.
• throttle — source line 59.
• register — source line 77.
• sendChallenge — source line 91.
• useChallenge — source line 102.
• verifyEmail — source line 112.
• login — source line 121.
• customerForToken — source line 140.
• logout — source line 147.
• requestChallenge — source line 153.
• resetPassword — source line 160.

Imports and dependencies

• Line 4: use Hslg\Backend\Database\TableNames;

Behaviour and audit locations

• Line 100: return wp_mail($email,$subject,$body);

Server-owned credential and challenge records

This repository stores and validates customer account credentials, login sessions, rate-limit activity and one-time challenges using HSLG-owned data rather than wp_users. Password recovery and verification must not expose whether an email exists. Its current mail challenge path is an integration foundation; the project owner requires all email verification logic to be consolidated into a separate module using the configured WordPress wp_mail() transport. Adding alternative verification providers before that refactor would scatter policy and make security review harder.

Relationship to the system

This page is the file-level source reference, not the architecture rationale. Read the module explanation, the corresponding architecture decision and user guide before changing behaviour. Names and line locations above are extracted from this exact source version; they are reference points, not proof that an external service or a phone feature works.

Change verification

Review the entry points and errors in this file, then run the module’s associated tests, source dependency gate, history gate and documentation coverage check. If the file changes an API response, user interaction, data model, deployment or third-party dependency, revise those human explanations and disaster recovery/licensing when relevant. Do not infer actual native or external API operation from source presence.