Prevent banned users from verifying email with a surviving session #985

New issue

Closed

opened 2026-10-19 10:14:40 -05:00 by Codex · 2 comments

Codex commented

2026-10-19 10:14:40 -05:00

Member

Copy link

Banned users must be prevented from activating their accounts through an email verification link, even if they retain a valid authenticated session.

Registration automatically logs the new user in before email verification. Normal bans invalidate database sessions and block subsequent login, but Fortify's verification endpoint previously checked only authentication, the signed URL, and the matching account/email hash. A surviving session could therefore verify the email after a ban. Verification does not remove the ban, but the activation action should still be denied.

Acceptance criteria

Reject email verification with HTTP 403 for accounts marked with banned = Y, the banned role ID, or both, even with a valid session and signed link.
Leave email_verified_at unset and do not dispatch the Verified event for denied attempts.
Preserve normal email verification and invalid-link checks.

Implementation and verification

The fix is implemented through App\Http\Requests\VerifyEmailRequest, bound to Fortify's verification request in FortifyServiceProvider::register(). It retains Fortify's existing account and email hash checks and adds the shared User::isBanned() check. Existing authentication, signed-URL validation, and throttling remain in place.

Regression coverage reproduces a surviving authenticated session for all three ban-marker combinations. The original ban regression tests failed before the fix and pass afterward.

Acceptance re-review — October 19, 2026

Reviewed the request binding, inherited authorization, verification controller, route middleware, and shared ban predicate against every acceptance criterion. No outstanding implementation gaps found.
Verify HTTP 403, unchanged unverified email state, no Verified event, and retained ban for the ban flag, banned role, and both markers.
Verify normal activation succeeds and emits Verified.
Verify invalid email hash, mismatched account ID, expired URL, and tampered signature are rejected with HTTP 403, leave both accounts unverified, and emit no Verified event.
Verify a guest following a valid link is redirected to login without verification or a Verified event.
Run email verification, authentication, and registration tests: 43 passed, 217 assertions, using the testing environment and local SQLite database.
Run Pint on the three issue-related PHP files, PHPStan, and git diff --check: passed.

No frontend assets, migrations, or dependencies changed. PR #986 lint and MariaDB CI checks passed (tasks #1316 and #1317).

Release tracking

Commit the issue-related changes and publish a PR referencing this issue: commit 6ba1f60, non-draft PR #986, assigned to jimmyb.
Complete CI/review and merge: PR #986 merged by jimmyb as d2d51d017c49efa767a9d67438d25eadacfccce6.
Deploy and verify the released behavior: dev and production deployed at d2d51d017c49efa767a9d67438d25eadacfccce6; deployed file hashes/autoload, release manifests, external HTTP health, and guest activation-route checks passed. Ban-specific regression coverage passed without modifying live accounts.

Implementation, acceptance review, PR CI, merge, and dev/production deployment are complete. This issue is closed with status/done; see the deployment comment for verification details and rollback backups. Post-merge push workflows were still running at the final check.

Banned users must be prevented from activating their accounts through an email verification link, even if they retain a valid authenticated session. Registration automatically logs the new user in before email verification. Normal bans invalidate database sessions and block subsequent login, but Fortify's verification endpoint previously checked only authentication, the signed URL, and the matching account/email hash. A surviving session could therefore verify the email after a ban. Verification does not remove the ban, but the activation action should still be denied. ## Acceptance criteria - [x] Reject email verification with HTTP 403 for accounts marked with `banned = Y`, the banned role ID, or both, even with a valid session and signed link. - [x] Leave `email_verified_at` unset and do not dispatch the `Verified` event for denied attempts. - [x] Preserve normal email verification and invalid-link checks. ## Implementation and verification The fix is implemented through `App\Http\Requests\VerifyEmailRequest`, bound to Fortify's verification request in `FortifyServiceProvider::register()`. It retains Fortify's existing account and email hash checks and adds the shared `User::isBanned()` check. Existing authentication, signed-URL validation, and throttling remain in place. Regression coverage reproduces a surviving authenticated session for all three ban-marker combinations. The original ban regression tests failed before the fix and pass afterward. ## Acceptance re-review — October 19, 2026 - [x] Reviewed the request binding, inherited authorization, verification controller, route middleware, and shared ban predicate against every acceptance criterion. No outstanding implementation gaps found. - [x] Verify HTTP 403, unchanged unverified email state, no `Verified` event, and retained ban for the ban flag, banned role, and both markers. - [x] Verify normal activation succeeds and emits `Verified`. - [x] Verify invalid email hash, mismatched account ID, expired URL, and tampered signature are rejected with HTTP 403, leave both accounts unverified, and emit no `Verified` event. - [x] Verify a guest following a valid link is redirected to login without verification or a `Verified` event. - [x] Run email verification, authentication, and registration tests: 43 passed, 217 assertions, using the testing environment and local SQLite database. - [x] Run Pint on the three issue-related PHP files, PHPStan, and `git diff --check`: passed. No frontend assets, migrations, or dependencies changed. PR #986 lint and MariaDB CI checks passed (tasks #1316 and #1317). ## Release tracking - [x] Commit the issue-related changes and publish a PR referencing this issue: commit `6ba1f60`, non-draft PR #986, assigned to `jimmyb`. - [x] Complete CI/review and merge: PR #986 merged by jimmyb as `d2d51d017c49efa767a9d67438d25eadacfccce6`. - [x] Deploy and verify the released behavior: dev and production deployed at `d2d51d017c49efa767a9d67438d25eadacfccce6`; deployed file hashes/autoload, release manifests, external HTTP health, and guest activation-route checks passed. Ban-specific regression coverage passed without modifying live accounts. Implementation, acceptance review, PR CI, merge, and dev/production deployment are complete. This issue is closed with status/done; see the deployment comment for verification details and rollback backups. Post-merge push workflows were still running at the final check.

Codex self-assigned this

2026-10-19 10:14:51 -05:00

Codex added the

Rows
Columns