Environment:
Drupal 6.22
OG 6.x-2.1
ApacheSolr 6.x-1.6

In general, Apachesolr is working well, and is respecting content_access and a custom node access module. However, users can definitely find content in groups they are not subscribed to, though when they click that link they get an access denied. Are there any known issues with a configuration like this?

Comments

pwolanin’s picture

pwolanin commented

As far as I know it works correctly, but if you are running multiple node access modules at once that's not well supported.

obrienmd’s picture

obrienmd commented

I'd heard that, but core seems to be working well w/ multiple node access modules in this case. Any reason why Apachesolr might be differing from core?

pwolanin’s picture

pwolanin commented

It should not be, but apachesolr uses a shortcut to expose content that is visible to anonymous users.

It's also possible that someone ran the indexing while logged in and someplace in the module cached information about the logged-in user?

Basically, you'll need to debug the data sent to Solr for a particular node where you are seeing the issue.

obrienmd’s picture

obrienmd commented

I definitely ran the index logged in as admin. So I should clear the index and let it happen on its own via cron? Then searching by various roles of users may properly respect node access rules?

obrienmd’s picture

obrienmd commented

OK, deleted index and allowed it to rebuild 'naturally' via cron, but all content is still accessible for all users, not following node access rules. ksenzee should be coming by on Wednesday to help me debug this (still a novice dev)... In the meantime, any tips for debugging data sent to Solr for a particular node?

obrienmd’s picture

obrienmd commented

I browsed through the solr data at a very high level, and it seems each nodeaccess_ field (for each realm) had to proper gid data per-node.

Does ApacheSolr send the user's gid[s] in the query, or check against them upon return of the search response?

pwolanin’s picture

pwolanin commented

It constructs filters using the gids, so the filtering happens on the Solr server before the results are returned.

obrienmd’s picture

obrienmd commented

Can you recommend a place to hook in to dpm the exact query the module is sending to Solr?

obrienmd’s picture

obrienmd commented

I'm hooking into hook_apachesolr_modify_query and dumping query, params and caller.

$params seems to have 'im_og_gid' in its filters, but no other associated data I can see.

pwolanin’s picture

pwolanin commented

Shift your module weight maybe so it runs later? Or just hack e.g. the Solr library so you are sure you get the final values.

The filters for access look like 'nodeaccess_' . apachesolr_site_hash() . '_' . $grant->realm

obrienmd’s picture

obrienmd commented

Just tried the hook at weight = 9999 (cleared all caches just to be sure)... Still same data in the filters. I am quite sure some nodeaccess_* is in there, as the user isn't returned nodes that are filtered by nodeaccess rules other than OG. Would love further input, will continue to hack on it in the meantime!

obrienmd’s picture

obrienmd commented

More digging. I hacked apachesolr_nodeaccess.module...

After line 68 runs $subquery = _apachesolr_nodeaccess_build_subquery($user);, a dpm($subquery) returns a Solr_Base_Query object with id=4 and sortstring=''.

Then, after line 78 $query->add_subquery($subquery, 'OR'); runs, a dpm($query) returns a Solr_Base_Query object with id=3 and sortstring=''.

I can deal with the implications of the OR in line 78, but I dont understand what my dpms are giving me. Shouldn't I be getting a query with a search term, bunch of realms/gids, etc?

pwolanin’s picture

pwolanin commented

The subquery object should have data in its (protected) $fields array.

If you don't see that, try printing:

$subquery->get_filters()
nick_vh’s picture

nick_vh
he/him
Location Ghent
commented
Status: Active » Closed (cannot reproduce)