Foundation Inkfire Login 2.3.2

Dashboard design repair

• Uses the full available WordPress admin width instead of a fixed 1380px canvas.
• Makes light and dark mode complete surface systems across the canvas, hero, navigation, panels, notices, tables and controls.
• Aligns security-card actions and normalises button sizing across desktop, tablet and mobile.
• Contains third-party WordPress notices in a dedicated hero row so they cannot crush the heading or theme switch.
• Versions the admin stylesheet from its file modification time to prevent stale cached layouts after updates.

Validation

• Release validation: PHP 7.4 and 8.2 passed.
• WordPress Playground integration: PHP 7.4 and 8.3 passed.
• Authentication security regressions passed.
• Authenticated Mali dashboard QA passed at 1720px, 1024px and 390px with no document overflow.

SHA-256: 113b1adda5817dad4b722df884af808ac7f23c0341658033e842ed1888996189

Foundation Inkfire Login 2.3.1

Live-validation correctness follow-up.

• Correctly reports Foundation diagnostics logging when it is disabled.
• Reports AIOS-active/Foundation-off telemetry as amber.
• Reports no known logger/Foundation-off telemetry as red.
• Retains all v2.3.0 throttle, security dashboard, and bounded logging protections.

Validated in CI on PHP 7.4, 8.2 and 8.3 with WordPress 7.1 integration.

Foundation Inkfire Login 2.3.0

Enterprise login-defense release.

• Adds identity/address and address-wide origin throttling with HTTP 429 and Retry-After.
• Trusts only the origin REMOTE_ADDR for rate-limit identity.
• Samples lockout telemetry and bounds database pruning for shared-host resilience.
• Adds opt-in AIOS failed-login telemetry ownership without disabling other AIOS protections.
• Adds a Security red/amber/green dashboard with setup links and hostname-bound 90-day external greenlights.
• Adds PHP security regressions and WordPress Playground integration on PHP 7.4 and 8.3.

Cloudflare is optional. Application protection works standalone; green layered readiness requires a verified edge WAF or origin-server throttle.

Foundation Inkfire Login 2.2.4

Added

• Hidden honeypot protection for the plugin's branded inline WordPress login form.
• Early rejection of filled traps before credential authentication.
• Distinct honeypot_blocked event in the existing diagnostics report.

Behaviour

• The protection is enabled by the shared plugin; no new WordPress admin setting is needed.
• Normal submissions with an empty hidden field continue through WordPress authentication unchanged.

Validation

• PHP 7.4 and 8.2 release checks passed.
• AMH staging verified both the filled-trap and normal failed-login paths.

Package

• Canonical plugin directory: foundation-inkfire-login-styler/
• SHA-256 supplied as a release asset.

Foundation Inkfire Login v2.2.3

Changes\n\n- Replaced the oversized background watermark with Inkfire's hero palette.\n- Refined the right-side glass surface while keeping the login form card solid.\n- Corrected the desktop panel seam so the left edge is square against the contact panel; compact layouts retain rounded corners.\n\n## Validation\n\n- Validated on the live Inkfire login screen before release approval.\n- Release validation passed on PHP 7.4 and PHP 8.2.\n- CI-built ZIP integrity and SHA-256 were verified before publication.

Foundation Inkfire Login 2.2.1

Foundation Inkfire Login 2.2.1

Official release of the audited, live-derived Inkfire Login candidate.

Highlights

• Adds the Foundation authentication operations dashboard, searchable diagnostics, local authentication event logging, incident reporting, and privacy-safe support diagnostics.
• Fixes wp-admin reflow so wide operational tables scroll inside their own region instead of causing page-level horizontal overflow.
• Improves the public login: translucent account surface, stronger Inkfire watermark, layered glass edge, while retaining the solid credential card and contact panel.
• Fixes password-reset CSRF handling and preserves the native successful reset confirmation.
• Adds keyboard/focus, reduced-motion, contrast, and server-rendered fallback improvements.

Delivery and verification

• Package filename is deliberately foundation-inkfire-login-styler.zip; the built-in updater requires that exact release-asset name.
• Release asset SHA-256: 70b19d75108a67f24392255b4b7952e267054234427f0d2708c04bdc7f9f188e.
• PHP 7.4 and PHP 8.2 release-validation jobs passed before publication.
• main now requires those checks, linear history, and resolved PR conversations; force pushes and branch deletion are disabled.

Rollback

Reinstall the v2.0.28 release asset from GitHub if an urgent rollback is needed. Existing diagnostic event data is intentionally retained rather than deleted during rollback.

Operational note

The release makes the update available to sites through the existing GitHub updater. It does not itself force-install onto a production site. Confirm each site's update/auto-update policy and run a post-update health check before declaring its rollout complete.

Foundation Inkfire Login 2.0.28

Fix: the branded reset-password form never actually reset the password

Found during a maintenance audit. This is more serious than 2.0.27 and has been present since 2.0.11 (13 Jan 2026).

Symptom

A user requests a password reset, receives the email, clicks the link, sets a new password — and is bounced back to Lost password with an invalidkey error. Their password is unchanged. From the user's side it simply looks like password reset is broken.

Cause

wp-login.php does not keep the reset key in the URL. On action=rp it moves the key into the wp-resetpass-<COOKIEHASH> cookie, strips it from the URL, and redirects to action=resetpass.

The branded form was still reading the key from the query string:

$rp_key = ifls_sanitize_request('key');   // empty by the time the form renders

so the hidden rp_key field posted an empty string, and core's check failed:

if ( isset( $_POST['pass1'] ) && ! hash_equals( $rp_key, $_POST['rp_key'] ) ) {
    $user = false;   // -> lostpassword&error=invalidkey
}

Fix

Read the login/key pair from the cookie exactly as core does, falling back to the request only for the initial action=rp render before the cookie exists. $rp_key is passed through unaltered because it is compared with hash_equals().

Verified

On a live site, before vs after:

	2.0.27	2.0.28
rp_key in rendered form	(empty)	populated from cookie
Submitting the form	302 → error=invalidkey	200
Password actually changed	no	yes

Security regressions checked — both still correctly rejected, password left intact:

• forged key with no reset cookie → invalidkey
• tampered key with a valid reset cookie → invalidkey

The full 12-scenario CSRF matrix introduced in 2.0.27 still passes unchanged.

Upgrading

Automatic via the bundled updater.

Foundation Inkfire Login 2.0.27

Fix: admin password reset no longer blocked by the front-end CSRF check

Symptom

Clicking Send Reset Link on a user's profile in wp-admin failed with a red Security check failed. error (HTTP 403). No reset email was ever sent, so users who asked an administrator to reset their password received nothing.

Cause

WordPress core's retrieve_password() fires the global lostpassword_post hook for its admin reset tools as well as the wp-login.php form. This plugin hooked its front-end nonce check to lostpassword_post, but the admin tools never render the ifls_form_nonce field — that field only exists on the wp-login.php forms — so every admin-initiated reset was rejected.

Two paths were affected:

• user-edit.php → Send Reset Link button (wp_ajax_send_password_reset())
• users.php → Send password reset bulk action

Fix

Both admin actions are exempted from the plugin's nonce check. Core already validates its own nonce (check_ajax_referer / check_admin_referer) and an edit_user capability check before calling retrieve_password(), so by the time this hook runs the request has already been authenticated.

The exemption is deliberately narrower than a blanket is_admin() bypass: is_admin() is also true for anonymous requests to admin-ajax.php, so the check additionally requires an authenticated user holding the same capability core requires.

No change to front-end security. Lost-password, register and reset-password forms on wp-login.php still require a valid plugin nonce.

Verified

Tested against WordPress 7.0.2 / PHP 8.2 on three live sites (base-uk.org, thatdeveloper.co.uk, flotsamfables.com — the last with WooCommerce), covering 12 scenarios:

Scenario	Expected	Result
Admin "Send Reset Link" (AJAX)	allowed	✅
Admin bulk reset (action / action2)	allowed	✅
Front-end form, valid nonce	allowed	✅
WooCommerce lost password	allowed	✅
Front-end form, no nonce	blocked	✅
Front-end form, bad nonce	blocked	✅
Anonymous admin-ajax.php spoof	blocked	✅
Subscriber targeting another user	blocked	✅
Subscriber forging bulk action	blocked	✅
Other admin action (delete)	blocked	✅

Confirmed end-to-end over real HTTP: 403 Security check failed on 2.0.26 → {"success":true} on 2.0.27.

Upgrading

Automatic via the bundled updater. Sites still pointing at the old hawks010 repository URL are unaffected — GitHub redirects the API and asset requests to the new Inkfire-limited location (verified).

Foundation Inkfire Login 2.0.26

Full Changelog: v2.0.25...v2.0.26

Foundation Inkfire Login 2.0.25

Adds a read-only shared Foundation shell dashboard while preserving the login styling and security runtime.