Content Access + Domain Access - ApacheSolr returns all the results not respecting the node access permissions

This seems silly to ask but you used apache solr node access module right?

Yes, I did enabled the apachesolr_nodeaccess module... didn't find any settings for it - so I assume it should just work once enabled. But it really didn't produce the results I expect.

I'm not that proficient in D6 node access, the only thing I noticed is that Domain Access still adds one entry to the node_access table on the install (even when using the Domain Advanced module):

And then from looking into the code of apachesolr_nodeaccess module I see that it tries to handle the node_access grants... probably the above entry somehow confuses the apachesolr_nodeaccess algorithm. But still, another module figured it out correctly...

Let me know if I can provide anything else to get to the root cause of this behavior.

Changing to bug report, I believe it is appropriate.

The trick is actually really simple. Give each subdomain a different apachesolr_site_hash.

That will filter the results for you per domain. so you search from suba.domain.com will only be suba results

you search from subb.domain.com will only be subasubb results

This is centered around the node_access module saying "Anything user 0 can see, it is node_access_all"

Thanks Scott. It seems I didn't describe it correctly. I do want to search both domains content from any domain (be it kb.example.com or forum.example.com).

And we restrict the access to the content not by domain, but by roles (using the Content Access module). So that we have roleA, roleB and roleC and want these roles to get the search results with only the content items they have access to.

Any help with this one, please? Can someone point me to the right direction if I don't get it right?...

Up... still can't figure it out.

...not critical.

Yes, it is not - the search still works :) People tend to raise the priority if the issue is not closed in the expected timeframe ;)

Anyway, I figured it out by writing the custom module based of the apachesolr_nodeaccess. Removed some stuff from it and slightly modified the queries (basically, they were around the multisite that is not critical for me as I don't use it). Not sure what was causing the issue.

Attaching it here for reference.

Attachment	Size
acronissolr_nodeaccess.zip	1.99 KB

I had the same problem.

Apachesolr_node_access makes the assumption that if the anonymous user can access a node that there is no node access to worry about. This is not true when using domain module because the anonymous user can access content on one domain but not on another.

This patch does the same thing as the .zip module above, removing that flawed assumption.

Attachment	Size
apachesolr-556426.patch	1.84 KB

A new version to test. I'm testing against 6.2 but it should apply to 6.1 as well.

Attachment	Size
node_access.patch	4.15 KB

Same patch with a corrected code comment.

Attachment	Size
node_access.patch	4.14 KB

Note: The domain_all grant is put there by Domain Access for just the situation you describe. DA has a setting -- read the documentation -- for "Search content on active domain" or "search content from all domains." It also allows path-based registration of URLs on which you want to disable DA.

In those cases, we pass the 'domain_all' grant, which effectively removes DA from the node access query. However, I do not know if Domain Access Advanced (a separate module that I do not maintain), actually respects this setting.

See domain_grant_all() and domain_node_grants() in domain.module.

SOLR module + DA respects this setting properly. I do not know how the patch would affect that.

Yeah. It's complicated. Any direct testing is greatly appreciated. Thanks!

The hard part is using multiple node access modules, which doesn't really work in Drupal anyway. And Domain Access Advanced, technically, is not a node access module. It replaces the node access elements with its own db_rewrite_sql.

I think in some cases, people will have to write their own versions of the nodeaccess module - it's only ~100 lines...

I'm basically with Peter on this. If ApacheSolr can support one node access module at a time (which is basically all core can do), then it's ok, and anything else requires custom code.

Good, we agree on that (#17 & #18)

Hopefully we can get some review of #13 http://drupal.org/node/556426#comment-2304968

What are we actually testing in #13? I never had a DA+Solr problem. The issue may be DA Advanced and its use of hook_db_rewrite_sql().

testing #13 for general compatibility with node_access. If you could test it with DA that'd be great. I tested it with workflow_access. The current implementation doesn't work with workflow access. I think this is more robust.

The main reason I had the anonymous check there and did not bypass all checkes for adminiuster nodes was to maintain the viability of doing multi-site searches. The proposed patch destroys that.

Ok, since I started it all - here is my take on this.

I'm using the two node access modules as I need the Content Access to control the actual access and the Domain Access to have two different domains. Basically, all the content should be searchable from any domain. I'm using the Domain Access Advanced as it is recommended not to have 2 modules that are using the node_access table.

I will refer to the situation before the patch. The apachesolr_nodeaccess handles the things quite good and is able to handle the multi-site setups using the node_access('view', $node, drupal_anonymous_user()) check. This check runs fine and returns the correct information. I removed it only for the sake of simplicity as I didn't need the multi-site options.

But when the above check returns FALSE - there is a query to a node_access table:

which is when parsed and added as fields to the Apache SOLR index.

Even when using the Domain Access Advanced module there is one record in the node_access table:

and if we apply the above SQL query to this row - we will get the nodeaccess_sitehash_domain_all field added to the Apache SOLR index for all nodes that return FALSE on the node_access('view', $node, drupal_anonymous_user()) check. For me this is where it all fails (though not confirmed). So that when the subquery is being added it effectively adds the OR condition against this nodeaccess_sitehash_domain_all field which returns TRUE and all the nodes are exposed to every user.

Probably this is not 100% correct. But from looking into how the Lucene API module handles it - it doesn't query the node_access table for the rows that contain nid=0 and it works just fine. The interesting thing is that Chris wrote in comments for his Lucene API node access implementation that he got the idea on how to make it from this project.

Hope this helps.

Thank you all for you hard work on this Apache SOLR initiative, really saves time and money.