Only users with the "Bypass content access control" permission are able to search for users when Apache Solr Access is enabled

I too am having this problem. The permission that is making the difference in this case is "Bypass content access control". If you tick this then the user gains the ability to filter by user fields. Obviously you don't want to be ticking that permission - I am just writing this for info!

I imagine this is related to the apachesolr being all about nodes and not users or entities more generally? Is this a big deal to fix?

Sorry, bad title change

From using the Schema Browser in the Solr Admin web interface, it looks like 'status' is not being set on the users while they are indexed.

I noticed in apachesolr_user.install, status is one of the fields in the implementation of hook_schema(), and the description on it is, "Boolean indicating whether the entity is visible to non-administrators (eg, published for nodes)." Sounds like exactly what we want, right?

In the Solr Admin web interface, I noticed a field, BS_STATUS (I believe BS_ and BM_ are prefixes to denote boolean fields, per the schema). There and 1354 entries marked true, none marked false. Looking at the ENTITY_TYPE field, there are 1354 entries labeled as 'node', and 106 entries labeled 'user'.

So, it appears status is not being set on the Solr entries for users. I poked around, but I have very little experience with Solr and did not see anything obvious as to why it isn't working.

Any guidance or help on this would be really appreciated.

I was able to open the search for other users by altering the apachesolr filters:

function mymodule_apachesolr_query_alter(DrupalSolrQueryInterface $query) {
  $query->removeFilterSubQueries();
  $subquery = apachesolr_drupal_subquery();
  $subquery->addFilter('hash', apachesolr_site_hash());
  $query->addFilterSubQuery($subquery);
}

It could probably be fined tuned, but works as it is for me.

I can't reproduce this.
Roles with "Use search" and without "View user profiles" permission can even search users.

I have the same problem. You (anonymous user) need to have "Bypass content access control"
to search files, contents and so on. But if you give it to "anonymous user", they can edit any contents.

Without "Bypass content access control", you get the following message.

* Check if your spelling is correct, or try removing filters.
* Remove quotes around phrases to match each word individually: "blue drop" will match less
than blue drop.
* You can require or exclude terms using + and -: big +blue drop will require a match on
blue while big blue -drop will exclude results that contain drop.

Thanks.

Subscribing

The problem occurs when apache solr access is enabled, because it will try to apply its filters to users and that would fail the access check.

The attached patch should fix the problem.

Feedback?

+++ b/apachesolr_user.moduleundefined
@@ -53,6 +53,7 @@ function apachesolr_index_user_solr_document(ApacheSolrDocument $document, $acco
+  $document->bs_status = $account->status;

Where in the patch are you using bs_status?

+++ b/apachesolr_user.moduleundefined
@@ -141,6 +149,15 @@ function apachesolr_user_apachesolr_query_alter(DrupalSolrQueryInterface $query)
+
+  if (module_exists('apachesolr_access') && user_access('access user profiles')) {
+    $qs =& $query->getFilterSubQueries();
+    $q = array_shift($qs);
+    $q->addFilter('access__user', TRUE);
+    $subquery = apachesolr_drupal_subquery();
+    $subquery->addFilter('access__user', TRUE);
+    $query->addFilterSubQuery($q, 'OR');

this code could really use some comments as it should explain what it is doing?

Not sure why this was set back to "active"? The patch looks like a good start at solving this.

For what it's worth, I had some luck in the meantime with the following code in a custom module to work around this:

  // Apache Solr Access will prevent non-administrators from searching for any
  // users, so we need to override that if the current user can access user
  // profiles (we'll replace it with our own restrictions below).
  if (user_access('access user profiles')) {
    foreach ($query->getFilterSubQueries() as $sub_query) {
      // If the sub-query performs access control, add an OR condition on the
      // user bundle so that access control on user entities is skipped.
      if ($sub_query->hasFilter('access__all', 0)) {
        $sub_query->addFilter('bundle', 'user');
      }
    }
  }

  // For non-administrators viewing the search results, add additional
  // restrictions.
  if (!user_access('administer users')) {
    // Additional restrictions go here...
  }

The additional restrictions is where you'd put things like filtering to exclude users who are blocked, which might be something like $query->addFilter('bs_status', 0, TRUE) (although I didn't try that myself since the site I was using this on had different, more complicated restrictions for which users should be excluded from search results when a non-administrator is searching for them).

Er, and I forgot to mention that the above code would go in an implementation of hook_apachesolr_query_alter() (just like in #4).

I could have found why the user status is not set.
Look at how the status callback is defined.

/**
 * Status callback for ApacheSolr, for users.
 */
function apachesolr_user_status_callbackapachesolr_user_status_callback($user, $type) {
  return $user->status;
}

The status callback is supposed to be apachesolr_user_status_callback(), as that is the function referred by apachesolr_user_apachesolr_entity_info_alter().

  $entity_info['user']['status callback'][] = 'apachesolr_user_status_callback';

See #1837462: Isn't the function name wrong?

oops, paste twice...
fixed #13

shenzhuxi, please post the patch that you used to fix a certain issue. Now we do not know what you altered in the module.

-function apachesolr_user_status_callbackapachesolr_user_status_callback($user, $type) {
+function apachesolr_user_status_callback($user, $type) {

It needs to be fixed indeed, but I don't know is it related to this issue.

Is some advance on this? I tried to figure out some solution but I don't understand why they must use "bypass" to being able to search... and give that permission is the same as expose your web to attacks.

I think the solution in #16 does not have anything to do with this because this is an error existing in " ApacheSolr Search Integration " - I know it because I am not using " ApacheSolr User " and I have the problem as well. So it is in the core of ApacheSolr in Drupal.

Yeah, #16 might not be related (though is definitely a legitimate bugfix on its own)...

However, this issue is about the inability to search for users, which is a feature that the Apachesolr User module provides. If you are experiencing a similar bug when searching for content (and not using the Apachesolr User module) it might be a different problem; you should probably provide more details on the steps to reproduce and likely create a separate issue.

Problem should be here:

In apachesolr_access.module, line 38:

function apachesolr_access_build_subquery($account) {
  if (!user_access('access content', $account)) {
    throw new Exception('No access');
  }

The access is based on 'access content' permission instead of 'use search' permission.

Here is a patch that solves this problem.

It needs testing.

Thank you.

Could more people test it? For me it worked nicely but it is necessary more testing to tag this issue as " tested & reviewed by the community ".

Thank you.

+++ b/apachesolr_access/apachesolr_access.moduleundefined
@@ -84,7 +84,9 @@ function apachesolr_access_build_subquery($account) {
-    $subquery = apachesolr_access_build_subquery($user);

Please state what you are doing here and why?

+++ b/apachesolr_access/apachesolr_access.moduleundefined
@@ -84,7 +84,9 @@ function apachesolr_access_build_subquery($account) {
+		$query->removeFilterSubQueries();

please remove the tabs

The patch in #8 appears to have already been committed? In fact, it was committed one day after it was posted (http://drupalcode.org/project/apachesolr_user.git/commitdiff/b461f7c) but I don't think anyone mentioned that here yet.

I'm not sure if the code in that patch was correct or not, but using the latest dev version of the module I no longer experience the bug. Anyone else?

@Nick_vh, should delete the filters by $user because if not does not let 'anonymous' users to make the search. :S

Indeed today I uploaded Apachesolr search integration, Again I was not able to make a search with anonymous user. After apply the last patch, it works like a charm :)

I was having trouble with Solr not searching attachments unless Bypass content access control was enabled for the user, so I tried the patch in #23. The good news is that document content is now getting searched, however it does filter results by access at all. So search results (including content snippets) for nodes and files the user cannot access come up in the search results.

The system still prevents them from viewing the full node, or private files attached to the node, but the results should not be there in the first place.

Since the patch #23 is against the main Apache Solr Access submodule, the remaining issues are really more related to that module. There is already a related issue in the queue for that module: https://drupal.org/node/1783766

#28

however it does filter results by access at all. So search results (including content snippets) for nodes and files the user cannot access come up in the search results.

Has anyone managed to fix this or find a work around?

Thanks in advance.

Patch in #23 tested as follow:

1) Had 2.5 years old website. Update core + all modules (including Apachesolr).
2) The problem came again.
3) Applied patch to the module "Apachesolr"
4) Now the search is again correct, all users can use it and retrieve correct resutls.

Confirm the patch worked for me again after 2 years :)

Marking this as fixed as the remainder of the issue lies with the apachesolr_access module