4

I'm implementing search on a site using taxonomy access control with search api and search api solr. Reading the help page node access section, I see:

Needs details on how to build a View that respects access control.

… which is exactly what I need. How can I make a search view properly respect the taxonomy access control? I've got node access turned on in the index settings, and see the field available in the views filter, so I see some items with node_access_taxonomy_access_role:n set up, I could try to filter on this, but it would not affect the facets.

I have

Additional access checks on result entities

turned on in query settings as a temporary measure, but that only filters the search results, and not any facets, etc.

One possible (though inefficient) solution seems like it could be to make two indexes and the have two displays in the search view, searching the right index depending on whether the user is authenticated or not, but I see no good way to limit the index based on the taxonomy term assigned.

It seems like my question extends beyond the boundaries of the search view, and onto the index itself.

Improve this question
0

3 Answers 3

Reset to default
3

I've gotten this to work, but it was not exactly straightforward, mainly because there wasn't a clear way to find out what to filter for in the view. Big thanks to @Shawn Conn for the idea of contacting Jon Pugh, who wrote the comment in the help page, and Jon Pugh for answering me quickly. He didn't give me the answer, but made me feel more confident that if I kept working on what I was working on, there would be some likelihood of success.

Step One: Make sure node access info is being indexed

Make sure Node Access is being indexed

Step Two: Make the field available to views:

enter image description here

Step Three: In Solr, open your core, and in the Schema Browser find the access field:enter image description here

Step Four: Click on that field, Load Term Info, and see what access term data Solr is getting:

enter image description here

Step Five: In your view, enable a filter on the node access field, and filter using the value(s) you found in step four:

enter image description here

Further Notes

Filtering this way causes the search results counts and facet counts/facets available to all give the correct information. There is another option as in Shawn Conn's answer that will filter the results for access after the query has already been made. This filters the list separately from providing results to the facets and search information blocks, etc, which causes them to provide incorrect results.

Improve this answer
2
+50

For the Search Views module there's an option that enables further access checks on indexed entities that will enable your Taxonomy Access Control permission check.

You'll find in the Views UI under Advanced > Query settings on via the Settings link. It is enabled via the Additional access checks on result entities checkbox. As a caveat, this option will make result counts, pagination, and other search result details behave oddly since permission checks can't be made at index time.

Improve this answer
7
  • I thought I had mentioned, but rereading, I guess not specifically. I have the Additional access checks on result entities checkbox checked for now, but as you mention, this means that the facets will show options for things that don't exist. and counts are incorrect. All over the place, the interface and the help hint that there is a better way to handle access checking, but I can't find anywhere where it is actually done. If there was a way to generate a different index for logged in users and non-logged in users (the only access check I need) and search the right one in the search view…
    – UltraBob
    Commented Jun 1, 2016 at 0:12
  • automatically, that would be inefficient , but it would work, but I don't immediately see a way to limit the index to only items that meet the criteria for unauthenticated access. I have the index set up to index node access information, but apparently with Taxonomy Access Control the node_access table doesn't get written to, so looking at the sm_search_api_access_node field in the solr index shows all terms with node_access__all. Where are these non last-resorts that the interface and help hint at?
    – UltraBob
    Commented Jun 1, 2016 at 0:27
  • I was wrong about taxonomy access control, and apparently something had gone wrong with the access rebuild. I think I'm going to probably simplify the access model to make this unnecessary, but I think the question is still important.
    – UltraBob
    Commented Jun 1, 2016 at 2:05
  • I see. You might want to try re-indexing. With Node Access filter it looks like it indexes anything utilizing hook_node_access_records() and hook_node_grants() (which TAC does ). Search Views allows you to filter on this information through the Indexed Node: Node access information filter but you need to know the indexed key (e.g. set = "node_access__all" for everything viewable by the anonymous user), which can't be dynamically pulled from a current user contextual filter.
    – Shawn Conn
    Commented Jun 1, 2016 at 2:07
  • You might be able to do it through a Indexed Node: Node access information that's pulling the information through PHP code, but that feels hackish.
    – Shawn Conn
    Commented Jun 1, 2016 at 2:07
0

in drupal8 , simply opt-in the

Adds content access checks for nodes and comments.

of the search api module configuration at this address:

/admin/config/search/search-api/index/article/processors

Improve this answer
1
  • This is still correct even for Drupal 9. You only need to apply this setting and it will adjust the search results based upon access without any further configuration. The only downside I have found is that any access restrictions on media content will not be considered. So if you have media items referenced within your search fields then you would still need to manually filter those out as needed within the view.
    – Ron
    Commented Aug 1, 2022 at 18:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.