I wrote down another idea how to cache denials in a design document on caching denials. However, I fear this won't fully address the problems that are described here and after some more investigations (indicated in the design page), it is completely unclear how this could work with Solr so I think the ideas outlined in the previous comment have a higher chance of actually working.
Michael Hamann on 23/Feb/26 13:02
To me, the most promising idea to fix this would be to filter results based on XWiki's authorization manager directly in Solr with a plugin that we deploy as part of our [existing Solr plugins|https://github.com/xwiki/xwiki-platform/blob/8ada6cf55c80ea9ac9820747036660229c42e7dd/xwiki-platform-core/xwiki-platform-search/xwiki-platform-search-solr/xwiki-platform-search-solr-server/xwiki-platform-search-solr-server-plugin/pom.xml#L30]. I found a [tutorial on custom security filtering in Solr|https://web.archive.org/web/20170513064616/https://dzone.com/articles/custom-security-filtering-solr] that describes using a [PostFilter|https://solr.apache.org/docs/9_10_1/core/org/apache/solr/search/PostFilter.html] to implement custom filtering based on access control lists. From my understanding, this should allow us to filter results before facet counts are computed, ensuring that facets but also pagination accurately reflects user rights. There are several challenges to solve, though:
*Accessing XWiki:* * For embedded Solr, we should make sure that we access XWiki's authorization manager directly through Java to avoid any overhead * For external Solr, we would need some HTTP (REST?) API to perform authorization checks. For this to work, we would need to ** ensure that Solr knows the current user ID and this can't be manipulated by the user (by, e.g., passing the same value that we use for this as part of the query) ** ensure that Solr can reach XWiki, taking clustering setups into account. The callback URL would need to be configurable in XWiki as Solr might not be able to access XWiki in the same way as the user as the Solr server shouldn't have internet access. A possibility could be to let XWiki pass the callback URL in the request to Solr, making it possible to use the same cluster node as the original request.
{*}Performance{*}:
A Solr query could match a million documents and to calculate accurate facet counts, we would need to check rights for all of them. From a performance point of view, this is impossible with our current authorization manager. While it can cache computed rights efficiently, the initial computation can be costly as it loads the whole document from the database. This is fine for the 10 documents that are displayed on a single page, but not for thousands or even a million total results. For this reason, I think after an initial PoC that filtering in Solr works, we need to work on making right checks more efficient. A main idea here would be to modify the security cache loader to maintain in memory a list of all rights that are defined in the wiki, loaded with efficient database queries to get all right objects on first access and then updated as documents are modified with event listeners. That way, we should be able to check the rights of a document without loading it from the database. I don't know if this would be enough, but it could be an important first step.
An option could also be to limit facets to the first x documents, where x would be configurable with a default of, e.g., 1000. This would still require the above-mentioned refactoring for good performance but it would limit the worst case performance in big wikis. It could lead to confusing results, though. I don't know if Solr provides any way to more intelligently select which documents to check, e.g., at least one document per facet and then display approximate counts for facets of which not all documents have been checked - Solr supports approximate total counts for high numbers of results but I have no idea how this works or how we could influence this.
[Edit] We should also ensure that access rights are (correctly) cached on the Solr side for the respective user. Solr has support for storing arrays for all documents in the index where we could possibly store some small integer to indicate the status (unknown, allowed, denied) for a user. Queries that just display a subset of the previous search (e.g., by filtering the query with facets or using the pagination links) shouldn't cause additional rights checks on the XWiki side.
This message was sent by Atlassian Jira (v9.3.0#930000-sha1:287aeb6)
If image attachments aren't displayed, see this article.
