To quote the option in the views advanced settings
By default, an additional access check will be executed for each item returned by the search query. However, since removing results this way will break paging and result counts, it is preferable to configure the view in a way that it will only return accessible results. If you are sure that only accessible results will be returned in the search, or if you want to show results to which the user normally wouldn't have access, you can enable this option to skip those additional access checks. This should be used with care.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | 28946670-2-fix-result-count-with-access-control.patch | 551 bytes | geekygnr |
Comments
Comment #2
geekygnr commentedI am not sure if I am on the right track here but this seems to solve the problem with the results count. It doesn't fix the pager though.
Comment #3
drunken monkeyIt would probably make the result count a bit more correct, but not completely, and wouldn't do anything for the pager.
The problem here is not that we were to lazy or anything to implement this correctly, it's that there's just no way to do this correctly (except by first retrieving ALL results, checking the access for each and then reducing the returned results according to paging rules – but that's, of course, hardly an option). It's like the description says: you should just set things up so this is needed as rarely as possible (if ever), just present as a last-ressort safety net.
So, I also don't know whether we should commit this minimal improvement. The result will be wrong either way. Waiting for feedback from others here.
Comment #4
geekygnr commentedI have a few hours from my employer to work on this. A combination of solr and access control is a requirement that comes up from time to time so I need to find a solution for it.
If there is some other way to do this please point me in the direction of an example. I am not sure how I would go about setting up such a search so this is needed as rarely possible.
I am going to leave this ticket active until I have run out of time to work on it and then whatever I come up with can be reviewed to see if any of it is worth using.
Comment #5
drunken monkeyIf you are using normal "Content" (aka "nodes"), the "Content access" processor should do a good job of implementing the correct access checks. Otherwise, you'll just have to look at what data is used for access checks on your site and try to reproduce this as well as possible with Search API (i.e., indexing all relevant information and then placing adequate filters on the query).
Also, see this "common pitfall": if items aren't indexed immediately when they change, old data could be used for the access check included in the query, which would lead to items being included that the "last ressort" access check will then filter out.
For a better general solution, as said in #3: don't think that's possible, sorry.
Comment #6
geekygnr commentedI built a custom version of content access to solve my immediate problem.
For a more general solution did you try adding a processor that stored for every entity what roles had access to it. When indexing you could quickly loop through all the roles and do an access check.
This wouldn't solve all of the access control problems but it would make it a little more generic especially since just about everything in D8 is an entity, belongs to an entity or both.
Comment #7
drunken monkeyHm, that's an interesting idea, thanks!
As you say, it wouldn't be a 100% solution, but might still be a significant improvement. I opened #2898334: Add a "Role-based access" processor to discuss (and implement) this idea. Thanks again!
Comment #8
geekygnr commentedYour very welcome.
With that new issue open I don't think there is any reason to keep this one open.