Crafted post search query can skip Post::getTypePermissionConstraints

[Xon]

Affected version

2.2.12

This is related to this bug, but is a deeper design issue.

Both actionSearch/actionMembers allow a search query to target the thread search handler without loading the post search handler's getTypePermissionConstraints values. These search constraints would normally be loaded if a "thread" search was done via the advanced search form.

Thread::getTypePermissionConstraints returns an empty array, unlike Post::getTypePermissionConstraints which returns constraints. This is because Post::getTypePermissionConstraints and Thread::getTypePermissionConstraints are both called during a 'general' search and it is desirable to avoid duplicate conditions.

Making Thread::getTypePermissionConstraints call Post::getTypePermissionConstraints would not solve this issue in the general case, which includes 3rd party add-ons, around parent/child searchable content types which follow the same pattern of the child-content type implementing search constraints.

Basically, XF should resolve from the thread to post handler and use the post handler + a thread filter instead for searches to ensure getTypePermissionConstraints is called in the same way. Conveniently, search handlers can return a list of search types they cover and if they are grouped by another search type. A lack of grouping is effectively how to determine what is the "parent" search type.

actionMembers probably needs to call prepareSearchQuery instead of setting up an ad-hoc Query object, and then it would inherit the above fixes.

XF still does canView validation php-side, but this can result in more results being filtered out and which displays less results than expected to the end-user.