Problem/Motivation
When stepping through code for #2958568: Add a search api processor for view unpublished I stumbled upon the code in \Drupal\search_api\Plugin\search_api\processor\ContentAccess::preprocessSearchQuery()
, and I have to say that the flow doesn't make sense.
Here's the current code:
public function preprocessSearchQuery(QueryInterface $query) { if (!$query->getOption('search_api_bypass_access')) { $account = $query->getOption('search_api_access_account', $this->getCurrentUser()); if (is_numeric($account)) { $account = User::load($account); } if ($account instanceof AccountInterface) { $this->addNodeAccess($query, $account); } else { $account = $query->getOption('search_api_access_account', $this->getCurrentUser()); if ($account instanceof AccountInterface) { $account = $account->id(); } if (!is_scalar($account)) { $account = var_export($account, TRUE); } $this->getLogger()->warning('An illegal user UID was given for node access: @uid.', ['@uid' => $account]); } } }
So, in English:
- Load the current user from either the
'search_api_bypass_access'
query option or the current user context. - If the loaded account value is numeric, replace it with an account object.
- If the loaded account value is a user account, add node access checks.
- If the loaded account value is not a user account:
- Load the current user from either the
'search_api_bypass_access'
query option or the current user context. - If the loaded account value is a user account, get its ID.
- If the loaded account value is not an scalar value, dump it to human-readable format.
- Log a warning.
- Load the current user from either the
The parts that don't make sense are italicized/emphasized. The only way flow can get into that block is if the loaded user isn't a user account, so it doesn't make any sense to try to load it again and check if it's a user account.
Am I missing anything?
Steps to reproduce
Open \Drupal\search_api\Plugin\search_api\processor\ContentAccess::preprocessSearchQuery()
for editing.
Proposed resolution
Remove the parts that don't make sense/could not possibly apply.
Remaining tasks
Comment | File | Size | Author |
---|---|---|---|
#4 | 3315269-4--fix_wonky_error_handling_code_in_ContentAccess.patch | 776 bytes | drunken monkey |
|
Comments
Comment #2
GuyPaddock CreditAttribution: GuyPaddock at Inveniem commentedComment #3
GuyPaddock CreditAttribution: GuyPaddock at Inveniem commentedComment #4
drunken monkeyThanks for reporting this issue!
You’re right, the second
$account instanceof AccountInterface
check is definitely unnecessary, there is really no way that could happen. However, we do need to reload$account
again from the option, as$account
could beNULL
at that point if the option contains an unknown user ID. Defaulting to the current user again, on the other hand, probably doesn’t make much sense.Patch attached, please review!
Comment #6
drunken monkeyMerged. Thanks again!