Setting the storage behaviour 

In the backend module File Protection you can edit the Storage Settings of the currently selected folder via the dropdown menu on the top right of the window. Select "Edit storage settings" to edit the configuration.

After opening the configuration you have the following options. After saving, the configuration is immediately applied to the storage and the respective .htaccess file is updated automatically.

Updating / Repairing .htaccess 

In very rare cases it might be necessary to update the .htaccess file, if the file protection does not work. To do this you can just open the configuration of the respective storage and save it. The .htaccess will be updated automatically. Otherwise you can select "Update .htaccess" in the upper right dropdown in every folder of the storage.

Status of Folders 

To view the protection status of a folder, select it in the page tree on the left.

You will see an overview of the folder where you can create a new access rule or edit an existing one. Existing rules can also be deleted here.

• Click Create access protection to add a protection rule (only available if no rule exists yet)
• Click Edit access protection to edit an existing protection rule
• Click Delete access protection to delete an existing protection rule

Access rules are inherited by subfolders — unless those folders have their own access rules. Access rules of subfolders do not supplement the existing rules but replace them completely.

Creating or Editing a Protection Rule 

Select who is allowed to access the contents of the respective folder (including subfolders).

The available conditions are provided by the access types. See there for a detailed explanation of each condition and how it is evaluated.

How it works 

The access type evaluates the protection record in the following order:

1. If the Enable access for frontend users option is disabled for the folder, the frontend access type never grants access.
2. If no frontend user is currently logged in, access is denied.
3. If neither individual users nor user groups are configured on the protection rule, every logged-in frontend user is granted access.
4. Otherwise, access is granted if the current frontend user is one of the selected users, or is a member of one of the selected user groups.

Configuration 

The relevant fields are configured directly on the access rule in the File Protection backend module:

If both the users and the user groups list are left empty, any logged-in frontend user is granted access.

How it works 

The access type evaluates the request in the following order:

1. If no backend user is currently logged in, access is denied.
2. If the backend user is an administrator, access is always granted.
3. Otherwise, the access type looks up the file storage referenced by the protection rule among the user's own file storages. Access is granted if the protected folder lies within the file mount boundaries of that storage for the current user.

This means a backend user can access exactly those protected folders they are already allowed to see and manage in the TYPO3 file list — no additional configuration per user or group is required.

The access type class 

The heart of every access type is a class that implements \Fixpunkt\FpFileprotector\AccessType\AccessTypeInterface. Place it under Classes/AccessType/<Name>AccessType.php in your own extension.

interface AccessTypeInterface
{
    /** @param array<string, mixed> $protection Raw protection database record */
    public function isGranted(array $protection): bool;
    public function getPartials(): string;
}

isGranted()

Receives the raw protection database record as an associative array and returns whether the current visitor should be granted access. Return true to grant access, false to abstain. Because access types are combined with OR, returning false never blocks another access type from granting access.

getPartials()

Returns the partial path used to render this access type in the backend module, e.g. 'Access/MyType'. The module renders <path>/Show.html to display the rule and <path>/Edit.html to edit it (see the partials section).

<?php

declare(strict_types=1);

namespace Vendor\MyExtension\AccessType;

use Fixpunkt\FpFileprotector\AccessType\AccessTypeInterface;

class MyTypeAccessType implements AccessTypeInterface
{
    /** @param array<string, mixed> $protection Raw protection database record */
    public function isGranted(array $protection): bool
    {
        // Your access decision, based on the protection record.
        return (bool)($protection['my_field'] ?? false);
    }

    public function getPartials(): string
    {
        return 'Access/MyType';
    }
}

services:
  _defaults:
    autowire: true
    autoconfigure: true

  Vendor\MyExtension\:
    resource: '../Classes/*'

  Vendor\MyExtension\AccessType\MyTypeAccessType:
    tags:
      - { name: 'fp_fileprotector.access' }

The partials 

Each access type provides two Fluid partials, ideally located under Access/<Name>/ so they match the path returned by getPartials():

Show.html

Renders the current settings of the rule read-only. It receives the protection record as the {protection} variable.

Edit.html

Renders the form fields used to create or edit the rule. It receives all available variables ({_all}), including the current record.

<div class="col-xs-12 col-md-4">
  <div class="form-group">
    <label>My setting:</label><br>
    <f:if condition="{protection.my_field}">
      <f:then><span class="text-success">Yes</span></f:then>
      <f:else><span class="text-danger">No</span></f:else>
    </f:if>
  </div>
</div>

<div class="checkbox">
  <label>
    <f:form.checkbox name="protection[my_field]" value="1" checked="{record.my_field}" />
    My setting
  </label>
</div>

templates.fixpunkt/fp-fileprotector.1643293191 = my_vendor/my_extension:Resources/Private

The TCA override (optional) 

If your access type needs additional fields on the protection record — for example a checkbox or a relation — add them via a TCA override for the table tx_fpfileprotector_domain_model_protection.

This step is optional: if your access decision does not require any extra data stored on the rule, you can skip it entirely.

<?php

declare(strict_types=1);

defined('TYPO3') or die();

$table = 'tx_fpfileprotector_domain_model_protection';

\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addTCAcolumns($table, [
    'my_field' => [
        'label' => 'My setting',
        'exclude' => 1,
        'config' => [
            'type' => 'check',
            'renderType' => 'checkboxToggle',
        ],
    ],
]);

Despite protection, all files are publicly accessible 

Check whether a .htaccess file exists in the root directory of the storage and redirects requests to fp_fileprotector.

In general the extension updates those .htaccess file automatically. Try to open the storage settings in the fp_fileprotector Backend Modul and save the storage settings once, to update the .htaccess.

If nothing helps you can update the .htaccess on your own: A template can be found at Resources/Private/htaccess.txt.

Also verify that the web server is configured to process .htaccess files (AllowOverride All).

User groups and/or users are being ignored 

Check whether the option Enable access for frontend users is enabled in the access rule. Without this checkbox, group and user restrictions have no effect.

A user has access even though they are not in any selected group 

The selection of groups and individual users is an OR conjunction. All members of the selected groups as well as all individually selected users can access the files.

How do I lift an inherited access rule? 

This depends on the settings of the storage. If the storage is set to disallow all access by default, this is not possible right now unfortunately. This is a known limitation — see Future Plans for planned improvements.

If the storage is set to allow all access by default, just create an empty protection rule at the folder, where you want to lift all restrictions and leave all conditions unset. Access will then be open for everyone for that folder and its subfolders.

If you want to be safe and deny all access that has not been explicitly granted, you can choose to set the storage to "allow access by default" and create a protection rule on the root of the storage, which allows only backend users to access the storage. That given, all folders are restricted for frontend access, but you can use empty protection rules to allow access for designated folders.

I have another problem 

Please feel free to open a GitHub Issue! :)