Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.I have an index of nodes that I am faceting by taxonomy vocabulary Category.
I have a term in Category called 'members only' and I only let users with a role of member view content with that term, via hook_node_access.
Logged in as a member everything works correctly, but as an anonymous user I see the same facet options and result counts as the members see, despite that the search results themselves are correctly access controlled.
Do I need to write a custom Processor?
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | 2942655.patch | 759 bytes | borisson_ |
Comments
Comment #2
borisson_This is a great question, we don't do any access control, and I don't think we should. But this is a great usecase that we should fix. Let's start by writing a test.
In theory this should just work, because we get the results form search api. I think that means this is a search api issue. However, I'm not sure. I'm hoping to see @drunken_monkey online soon. He might know more about this.
Comment #3
mkalkbrennerSolr doesn't have any native concept to do that. And it would be very complex to implement something like this. I think the easiest solution would be to simply configure the facet block correctly. It should be shown to "members" only.
Comment #4
drunken monkeyIn general, the Search API (any backend) will only return facet filter values that appear in the result set. (Except if the "Minimum count" is set to 0 – but that doesn't seem to be the cause here.)
It could just be a caching issue, I guess? Try clearing the whole cache (under Administration » Configuration » Development » Performance) and then right away viewing the search as an anonymous user (without visiting it as an admin/member in between). If the facets are correct (without "members only") then, it seems facet or block caching is interferring.
If that's not the problem, and unless something's going very wrong in the backend, it just seems like you haven't configured access control correctly for the search. Do you have the "Content access" processor enabled on the index? If not, enable it, re-index and then see whether the problem persists.
The search results probably seem correctly access-controlled because of the Views query plugin doing a manual extra "entity access" check on all results before viewing them. You can test that theory by temporarily disabling this in the view's "Query settings" ("Skip item access checks"). Also, if results are removed that way, paging will be incorrect (too few items per page, no results for the last pages, etc.) for anonymous users.
If the "Content access" processor is enabled but results still aren't properly access-checked (with "Skip item access checks" enabled), you might indeed need to write a custom processor to do the access checks for you. This should only happen if you're not using the default node access framework provided by Core, though.
Oh, sorry, since Chatzilla doesn't work anymore, I can't log in to IRC anymore. I guess I should register for Slack.
As I understand it, the facets block should be shown to everyone, it's just that one facet value that shouldn't be. All other categories are open to anyone, so anonymous users should see that, too.
Comment #5
borisson_Removing needs tests and setting this to a support request.
Comment #6
Jody LynnThank you @drunkenmonkey
I confirmed it is not caching related, I do have the content access processor on, and disabling the views entity access shows me that the content access processing is not working (and yes, paging is incorrect as well)
I am handing the access control via hook_node_access logic, not the node_access db table of grants. So I'm thinking I probably need to either change my access control logic or write a custom processor.
Comment #7
Jody LynnOk, I switched from hook_node_access to hook_node_access_records/hook_node_grants and all is well.
Just the usual fun with having two different node access systems in core ;)
Comment #8
borisson_Ok, that's great, let's add this as an FAQ item in the readme, so that the next person running into this doesn't have the same problem.
Comment #9
borisson_Committed and pushed, more docs is great, thanks!