PHP 8.x compatibility issues in UserKeyAuthForm: TypeError and nullable type deprecations

Problem/Motivation

A fatal TypeError is thrown when accessing a user's API key management page (/user/{user}/key-auth) under certain conditions (e.g. when the route is resolved without a fully authenticated user context, or triggered via a redirect from the login page).

The error message is:

Uncaught PHP Exception TypeError: "Drupal\key_auth\KeyAuth::access(): Argument #1 ($user)
must be of type Drupal\user\UserInterface,
Drupal\Core\Session\AccountProxy given, called in
/modules/contrib/key_auth/src/Form/UserKeyAuthForm.php on line 118"
at /modules/contrib/key_auth/src/KeyAuth.php line 114

The root cause is in UserKeyAuthForm::checkAccess(): when checking whether the current user may view their own key, $this->keyAuth->access($account) is called with $account (an AccountInterface / AccountProxy instance), but KeyAuth::access() declares its parameter as UserInterface. PHP 8 enforces this type declaration strictly and throws a TypeError.

Additionally, PHP 8.4 emits two deprecation notices for implicitly nullable parameters in buildForm() (line 40) and checkAccess() (line 109). The explicit ?UserInterface syntax is required.

Steps to reproduce

1. Install the key_auth module.
2. Log in as a regular user (or be redirected to login and back).
3. Visit /user/{uid}/key-auth for your own account.
4. Observe the TypeError in the PHP error log and a blank/error page in the browser.

Proposed resolution

In UserKeyAuthForm::checkAccess(), replace $account with $user in the call to $this->keyAuth->access(). The $user argument is already resolved to a UserInterface object by the route's parameter upcasting, making it the correct argument to pass.

Before (line ~118):

return AccessResult::allowedIf($this->keyAuth->access($account))

After:

return AccessResult::allowedIf($this->keyAuth->access($user))

This is semantically correct as well: the intent is to check whether the user whose key page is being viewed has access enabled, not the currently logged-in session account (which may differ in edge cases such as masquerading or admin acting as user).

Remaining tasks

• Review the proposed fix.
• Add a regression test covering the checkAccess() method with a standard authenticated user.
• Commit and release a patch release.

User interface changes

None.

API changes

None.

Data model changes

None.