solrfal indexing and fe-groups restriction not working

[baschny]

It seems that under certain circumstances files indexed with solrfal do not get the correct access restrictions set.

I had configured like documented:

plugin.tx_solr.index.queue._FILES.default {
    # Make sure the fe_groups from fal_securedownload are considered
    access = TEXT
    access {
        value = r:0
        override {
            cObject = TEXT
            cObject {
                required = 1
                field = fe_groups
                wrap = r:|
            }
        }
    }
}

Imagine that I have set the permissions using the "File" backend module like this:

+--------------------------+-----------+
| folder                   | fe_groups |
+--------------------------+-----------+
| /                        |           |
| /Downloads/              | 32        |
| /Downloads/Subfolder/    | 84        |
+--------------------------+-----------+

Any file under "Downloads/Subfolder" is wrongly indexed with r:0 and it appears in all search results (instead of only if the user has access to group 84).

When indexing, this method is called \BeechIt\FalSecuredownload\Security\CheckPermissions::getPermissions by fileMetaDataRetrieved. It will return "empty" (instead of 84) for these files because its logic seems broken.

It goes from the root folder up to the folder where the file resides, but aborts after finding any "folderRecord":

        $feGroups = [];
        // loop trough the root line of an folder and check the permissions of every folder
        foreach ($this->getFolderRootLine($resource->getParentFolder()) as $folder) {
            // fetch folder permissions record
            $folderRecord = $this->utilityService->getFolderRecord($folder);

            // if record found check permissions
            if ($folderRecord) {
                if ($feGroups === []) {
                    $feGroups = GeneralUtility::trimExplode(',', $folderRecord['fe_groups'], true);
                }
                if ($folderRecord['fe_groups']) {
                    $feGroups = ArrayUtility::keepItemsInArray($feGroups, $folderRecord['fe_groups']);
                }
                break;
            }
        }

One quick'n'dirty solution is currently to only have "folderRecords" on the leafs where the files resides.

Can anybody confirm this is a bug and maybe we can brainstorm about a solution?

[baschny]

This seems related: #134 - but I think it is not sufficient.

[rbqueo]

I got the same Problem. If a folder has no access restrictions the result for $feGroups after the run over all folders is an empty array.
If you now got a file, the $feGroups will be merged with this line:
$feGroups = ArrayUtility::keepItemsInArray($feGroups, $resource->getProperty('fe_groups'));

But this will always result in empty '[]' cause there are no groups from folders run.
I changed it to:
if ($resource instanceof File && $resource->getProperty('fe_groups')) { if ($feGroups === []) { $feGroups = GeneralUtility::trimExplode(',', $resource->getProperty('fe_groups'), true); } else { $feGroups = ArrayUtility::keepItemsInArray($feGroups, $resource->getProperty('fe_groups')); } }

With this solution the folder rights are respected but if there are no the file access restrictions will be.

[FamousWolf]

The problem here is that a user needs to have access to the file and the folder (and its parents). If the file is restricted to usergroup1 and the folder is restricted to usergroup2 the file is only accessible to users that are in both usergroup1 and usergroup2. You can add multiple groups to the record in solr, but that will give access to users in either group (so OR instead of AND). There is no easy way to add both file and folder restrictions in the correct way.

I have made a change that will check for restrictions on the file. If there are no restrictions on the file it will check for restrictions on the folder. It's not a perfect solution, but it's better than how it is now and should be fine in most cases.

Pull request: #163

[haraldwitt]

See issue #166

[FamousWolf]

If I'm not mistaken, this was solved with @213, so I'm closing this issue.