Obscure semantics of allow/disallow matching

[loisch]

First of all: File Browser is great! The UI feels real good and the feature set is consistent and matches my needs. 👍

I've tried to control which files and directories could be accessed by a user but with the current semantics of the regular and regex matching the feature is really hard to use for advanced control.

First I had to find out that the first match starting at the end is used. So if I want to include a "everything is forbidden" this rule must come first followed by the allow rules. If I include an everything is forbidden rule, regular features not related to files stop working (for example I can't change the view/listing format).
Second it's really hard to get the rules right because only the name with a prepended slash and not the full path is matched.

It would be great if

• matching would only apply to file-paths and can not break other features
• matching the full path would be possible
• the documentation would explain the matching algorithm if several rules match

Thank's a lot for the great work! I'll have to find a different way of controlling access to files but I'm still a happy user. 👍

[danielloader]

Agreed with all of the above.
Could be simplified with a toggle with whitelist or blacklist by default.
Some users I'd like to whitelist two directories, some I'd like to blacklist a few, some get all.

Hard to do easily unless I'm missing something obvious.

If anyone does have a working regex example for deny all except certain folders I'm all ears.

[hacdias]

(Dis)allow rules apply to file paths only. If the user doesn't have access it will, of course, return an error if they try to forcefully call the API. Matching the full path is possible. Just use a regular expression that matches from the start to the end or a path.

I'll then consider this issue more about documentation, so I'll move it to another repository so I don't forget to add more info about the Rules on the new documentation.