Programmatically change served root + share links

sev

I have been looking for a good file browser app for a long time and have tried File Browser, Filestash, Nextcloud, and more... I recently saw FileRun but it is far far too expensive and license too restrictive for me. Files Gallery is the next on my list to try, and so far I am quite impressed. However, there are some missing features I'd like to implement.

Change root at runtime

I would like to use Files Gallery to show individual directories for each user. I can't use a common root and specify the path in the URL, because users would easily be able to navigate up and into other user directories. I have in the past facilitated this via the proxy headers (File Browser, Filestash, ...) or with the service itself managing files (Nextcloud, Seafile, ...). Files Gallery is different in that there seems to be no way to shim the root at runtime, without editing the script itself. Which I don't mind doing, I only wonder if/wish there were a more streamlined way to do it. Would there be a way to provide config vars at runtime via a HTTP callback, or some sort of plugin system that loads custom PHP code? What would be the best approach for this?

Share links

One requirement for my hunt was share links. I don't care if I have to write my own implementation or wrapper for it, as long as that functionality can smoothly be implemented into Files Gallery.

Is this functionality present in Files Gallery already somewhere?
If not, is there a plugin system that I could use to inject functionality to e.g. right click menus to generate a link?
If no plugin system, are the internal interfaces workable for third party code so I can make it myself? How open is the codebase to changes, and how difficult would it be to rebase on new versions?

Checklist

Ideally, the functionality I am looking for to act as a drop-in replacement with my current implementation is:

Change root based on REMOTE_USER or etc. proxy header
Create share link with toggleable view, edit, and upload flags
- Separate interface for shared files vs shared directory
  - Q: Is there an endpoint for viewing files directly without loading the rest of the interface? Maybe Embed?
- Upload flag results in a link where users cannot view contents but can upload. Would be cool if they could also view/modify/delete files they upload during their session but this is not at all required, and I don't mind if they simply disappear into the aether after upload is done (i.e. can't view directory tree). Naturally this would not apply to sharing files directly, only directories.
Expiry date for links
Toggle to require users to be logged in to access link
- I would facilitate this with checking proxy headers before showing the page since there is no concept of users in Files Gallery
Allow only specific logged in users to access link
- Same as above
Option for email authentication (to support external users without an account in the system)
- There are multiple ways to do this an each has their own merit. This could either:
  - Send a unique access link to each specified user instead of the default share link flow
  - Send a unique code to each specified user, which is then put into the share link from the usual flow
  - Ask the user when accessing the page to enter their email, and do a verification check then
Option to allow users to re-share from the share link, with permissions either matching or more restrictive than the parent link
Allow users to view, edit, rename, and delete existing shared links

As mentioned I am fully capable of developing most of the additional functionality here, though I would do as much as possible in the proxy/PHP since the JavaScript stuff is icky. If you could at least point me in the right direction I would be happy to see how much effort would be required to get this all working as I want.

Another thing that is probably out of scope for the project is WebDAV support. I'd probably implement that separately to Files Gallery, using whatever backend I end up scavenging from/writing for Files Gallery. Normally not having an integrated WebDAV server would be a dealbreaker, but Files Gallery is so smooth I am willing to give it a shot and implement the server myself.

Best regards and great work on this project.

Karl

sev Hi. Thanks for all the feedback.

sev Change root at runtime

The best way to do this, would be to edit the config file _files/config/config.php. For example some logic like this:

<?php

// your script that creates $myroot var. Or just include your logic directly here.
require 'yourScriptThatGetsUserRootDir.php';

// Uncomment the parameters you want to edit.
return array (
  'root' => $myroot,

Perhaps there are more elegant ways to achieve this, which might be considered in the future. On a related note, Files Gallery will soon have it's own "USER" system (per login), where you could assign separate root options per user. However, if you need to implement your own logic, this may have to be done per custom code anyway.

sev Share links

It depends on what you mean by "share links". In Files Gallery, there is already "copy link" for all files and folders, in addition to be able to share directly from browser (mobile browser usually have their own "share"). Unlike some of the other file manager apps you mention (Nextcloud, Filerun), Files Gallery is simply a 1:1 representation of your own file system, so the shareable link to an item will always be the link to the item in the browser and/or the result of "copy link". Therefore, I don't see much need for "share", as I can't see where it will be used, and I haven't had many requests for this. In other database-applications, when you "share" an item, the app may actually create a persistent or temporary virtual link and store it in database, because the real path may be obscured or protected. This is obviously required in database apps where all paths are virtual and controlled by the app, but not so much Files Gallery where all paths simply mirror the existing file system.

sev If not, is there a plugin system that I could use to inject functionality to e.g. right click menus to generate a link?

It is possible to create custom right click menu items. It's not clear however exactly what a "share" button should do in this case. You want to implement something where you can share directly to services like Facebook etc?

sev Create share link with toggleable view, edit, and upload flags

I'm struggling to understand this. If you mean a link with properties that can decide what the user that clicked the link can do, this is beyond Files Gallery. This is typical for a more complex database app, which may then also need to control the file system entirely.

sev Separate interface for shared files vs shared directory

I'm not sure what you mean by "shared" in this context. Anything that is visible in your Files Gallery, eg. available within the root, and not hidden by files_exclude or dirs_exclude, are visible and therefore shared with anyone that can view the gallery. There is no such concept shared or non-shared.

With "separate interface", you mean entirely separating folders and files into two different layouts? This won't work with sorting, filtering or search, or at best will be very clumsy.

sev Q: Is there an endpoint for viewing files directly without loading the rest of the interface? Maybe Embed?

No. That would need to be embed.files.gallery, but this is a separate application that needs to be implemented into your own html page (although the page could be blank). It's mainly for adding galleries to website pages, using the Files Gallery as engine.

sev Expiry date for links
Toggle to require users to be logged in to access link
I would facilitate this with checking proxy headers before showing the page since there is no concept of users in Files Gallery
Allow only specific logged in users to access link
Same as above
Option for email authentication (to support external users without an account in the system)
There are multiple ways to do this an each has their own merit. This could either:
Send a unique access link to each specified user instead of the default share link flow
Send a unique code to each specified user, which is then put into the share link from the usual flow
Ask the user when accessing the page to enter their email, and do a verification check then
Option to allow users to re-share from the share link, with permissions either matching or more restrictive than the parent link
Allow users to view, edit, rename, and delete existing shared links

I think this can all go into one response. You are asking for features that can't possibly go into a file browser that simply reflects the existing file system and doesn't use a database. The features you are asking for, requires the file system to be controlled by the application, and synched with a database ... So that the app can control everything, including links, permissions, access etc. This is not possible in Files Gallery. You would need to consider more complex apps like Filerun or Nextcloud.

In a release later this year, there will be multi-user login, which will allow different config options per login. For example different roots, different permissions for file manager actions, different exclude options (hide files or dirs). However, this will not allow virtual links, with different options per link, or expire time per link.

In conclusion, your share and link feature requirements seem beyond the scope of what Files Gallery is capable of, and not anything I could recommend trying to implement yourself.

Thanks again.

sev

Hi,

Thanks for following up.

Karl I'm struggling to understand this.

First of all, I think there may have been some confusion in terminology. By "shared file/link", in the context of a multi-user file storage environment, I simply mean "a link that someone can click to access [a certain subset of] another user's files [with certain permissions applied]". I'll go into more detail as I respond to individual points.

Karl For example some logic like this:

I can't believe I didn't think of that. That should work. What I really wanted was to avoid editing the PHP with every upgrade to add my own customizations, so I'm happy with it.

Karl Files Gallery will soon have it's own "USER" system (per login), where you could assign separate root options per user.

This is basically what I want and what I was planning to implement, on a basic level.

Can you explain a bit more about the user authentication you're thinking of adding? How will that look and what authentication scheme will it use? How will the per-user data be stored? Will you accept reverse proxy header authentication instead of native prompts?

Files Gallery is simply a 1:1 representation of your own file system, [...] Therefore, I don't see much need for "share", as I can't see where it will be used

Adding user authentication to Files Gallery is the perfect grounds for this use-case though. In a multi-user configuration, there are going to be times a user wants to access the files of another user, or provide access to their own files for another user.

Karl I haven't had many requests for this.

Of course not, since what I'm proposing starts leaning slightly into groupware rather than personal/single-directory file browser as Files Gallery is now. It is simply not the market you have targeted, so no one interested in that has come forward. However, I still wanted to ask, since I wasn't sure about where the project was at and what your goals were.

Karl The features you are asking for, requires the file system to be controlled by the application

Not really. I don't think I explained myself very well. The only thing that will be controlled is the root and some other configuration values, which is something you were already planning to do. At the end of the day, it will all still be bare files on the file system with no control by Files Gallery or any other application as to how they are presented or translated. The files on disk will always be represented 1:1 as you said, just at a different root or with other modified settings depending on the situation.

TL;DR: I will be using Files Gallery isolated behind a reverse proxy. The objective is to have users authenticate via the reverse proxy before accessing the page, and then be sent to their own personal directory by updating the value of root. If a special link is used, the root and potentially other configuration values are changed based on the values associated with the link.

Let me give some examples to better illustrate my goals.

User login flow

User visits my.files.gallery and is served by the reverse proxy.
User does not have login cookie and is redirected to authentication service by the reverse proxy.
Authentication service provides a cookie and sends the user back to my.files.gallery.
The reverse proxy connects to the PHP backend, and sends various headers along with it, such as REMOTE_USER.
Files Gallery loads up, and the custom configuration sets $myroot to /some/file/path/$_ENV[REMOTE_USER].
The user sees only their files and no one else's.

I think this is very straightforward and should be very easy to implement. Even if you set up a native solution, I wouldn't use it, since I use SSO for my web apps, so I will go ahead and do it anyway before the next release.

Share files with another user

Now, since the file path the user is accessing is specific to them and is not accessible by anyone else, consider this workflow:

User Bob wants to give user Alice access to his directory.
Bob right-clicks the directory and selects “Create share link…”.
Bob gets a popup that allows him to change settings for this “virtual link”, and picks options that allow Alice to view the directory only.
The link and settings are saved to a database or other persistent store.
Bob sends the link to Alice, and she opens it.
The reverse proxy does not send Alice to the authentication service, since she accessed the site via the shared link, and sends Alice to Files Gallery directly.
The custom config detects that no authentication was used, and that the link being accessed is a shared link, and reads the configuration from the database for the link.
The Files Gallery configuration is updated to not allow writing files and sets the root to the directory specified in the database.
Alice sees the directory Bob shared with her, and she is only able to view.

I think this is very much possible and should be quite easy to implement. The only issue would be getting it to play nice with Files Gallery's interface. Is it possible to e.g. open a custom iframe inside the Files Gallery UI based on a right-click action? If so that would easily allow me to make this work.

I understand that groupware is beyond File Gallery's scope, and I did expect that, but honestly every other solution I've tried has either been overengineered and clunky, or too underdeveloped and full of issues. Files Gallery seems very robust and easy to configure, and shimming the config like that with my own logic seems like a very straightforward path for implementing this. It might not be the prettiest solution, but I think it will be perfect for my needs.

Thank you for your time. If I can get this working I'd be more than happy to buy a license. And if it's portable enough, others in my situation may be able to use it as well, if you'd want to host a tutorial or something in your docs 🙂

Karl

This is a lot to take in, with some features beyond Files Gallery, or definitely borderline beyond Files Gallery. I will answer as best I can without things getting too complicated.

sev Can you explain a bit more about the user authentication you're thinking of adding? How will that look and what authentication scheme will it use?

I think the idea, like Files Gallery itself, is to keep it as simple as possible. Just like the current login method uses [HTTP authentication](HTTP authentication), multi-user login will also use this method. This of course protects the app and prevents the app from displaying anything without login (although it will also be possible to have a non-login "public" user, with it's own restrictions). This does not however protect from direct access to your actual files (if anyone knew the direct links), as this isn't considered a responsibility of Files Gallery. For this, you would need to implement your own logic, eg root outside server document_root or blocking direct access by Apache/Nginx and/or using Cloudflare.

sev How will the per-user data be stored?

I assume you speak of per-user settings? Files Gallery doesn't store anything else from the user, and you simply point the users root setting to where you want to the user to be able to read/manage files from. As for user settings, they would probably be stored in an array in a file _files/users/users.php, with encrypted passwords.

sev Will you accept reverse proxy header authentication instead of native prompts?

This may require some customization. By default, because Files Gallery is a single-file and because I want to keep it simple, I won't put too much effort into accepting all kinds of 3rd party login methods.

sev In a multi-user configuration, there are going to be times a user wants to access the files of another user, or provide access to their own files for another user.

This is where I'm not sure what you are expecting. You could have userB with access to dir/userB and userA with access to dir and therefore also access to subdirs owned by other users. Or you could create a symlink from one users files from another's. There won't be any option "share my files with user [abc]" as that is not really logical. Files Gallery doesn't "control" the file system, and a user will simply be able to access files from with a defined root dir.

sev However, I still wanted to ask, since I wasn't sure about where the project was at and what your goals were.

I think it's reasonable to request a "share" feature, because there are some conveniences, especially from mobile when sharing to other apps. However, I think it needs to be clear that a "share" feature won't create virtual and/or temporary links, that provide specific permissions and features for that link. It will link to a file or dir on your file system, and the person that clicks it will need the link to be non-login (public) or they will need the login.

sev The objective is to have users authenticate via the reverse proxy before accessing the page, and then be sent to their own personal directory by updating the value of root.

I'm sure this can be done without too many complications. I won't personally be giving too much through to this when working with the multi-user update, but it can probably be implemented by modifying the users root setting dynamically.

sev User login flow

I think this is very straightforward and should be very easy to implement. Even if you set up a native solution, I wouldn't use it, since I use SSO for my web apps, so I will go ahead and do it anyway before the next release.

Yes, it should be possible. Even with current version, as you would simply be modifying the root option dynamically. Technically, you could also change other dynamically also.

sev Share files with another user

Now, since the file path the user is accessing is specific to them and is not accessible by anyone else, consider this workflow:

User Bob wants to give user Alice access to his directory.
Bob right-clicks the directory and selects “Create share link…”.
Bob gets a popup that allows him to change settings for this “virtual link”, and picks options that allow Alice to view the directory only.
The link and settings are saved to a database or other persistent store.

This is where it gets diffuse. Files Gallery does not use a database, and even if it did, or we store the data in some JSON file, what "settings" is it supposed to save that allows Alice to access Bob's dir? I did read through 1-9, and maybe you can implement it in a "hacky" kind of way, but my personal opinion is that this is beyond the scope of Files Gallery.

sev Alice sees the directory Bob shared with her, and she is only able to view.

If the shared link bypasses authentication, how will only she be able to view it? Anyway, this is just one question of many ...

sev Is it possible to e.g. open a custom iframe inside the Files Gallery UI based on a right-click action? If so that would easily allow me to make this work.

Custom iframe seems to suggest you want to add the iframe into the actual document where Files Gallery exists. Why not just open a popup window? Or why does it have to be an iframe? Essentially, you can create a custom right-click button that can trigger your own Javascript, and essentially do anything you want it to do.

sev every other solution I've tried has either been overengineered and clunky, or too underdeveloped and full of issues.

Indeed. That's why I'm conscious about what can and can't easily be included into Files Gallery while maintaining a useful interface. Other app definitely offer more "sharing" features, but can also be more clunky, unintuitive and complicated.

sev Thank you for your time. If I can get this working I'd be more than happy to buy a license. And if it's portable enough, others in my situation may be able to use it as well, if you'd want to host a tutorial or something in your docs 🙂

Thanks for your feedback. Happy to assist, as long as we are within reasonable limitations of the application.

sev

Great, I think we're starting to get more on the same page here.

Karl This may require some customization. By default, because Files Gallery is a single-file and because I want to keep it simple, I won't put too much effort into accepting all kinds of 3rd party login methods.

Karl Even with current version, as you would simply be modifying the root option dynamically. Technically, you could also change other dynamically also.

It sounds like it would be better for me to ignore the implementation, then. I will programmatically define the root, and likely won't change any other settings.

...Unless I add a page to allow users to customize their experience. Might as well if I go all-in on it, right? If I end up doing that, I could write the Files Gallery config array into the file you are expecting in that directory, and craft an Authorization header from the reverse proxy. I would leave the password blank, and block the header from being forwarded from client requests. Then I can make use of your infrastructure seamlessly with my own customizations.

Karl I'm sure this can be done without too many complications. I won't personally be giving too much through to this when working with the multi-user update, but it can probably be implemented by modifying the users root setting dynamically.

I already got it working. It was very easy, and I'm ashamed I didn't think to try it before posting here.

  'root' => "/srv/userfiles/$_ENV[REMOTE_USER]",

With that single line, I have already reached feature parity with my Filestash installation, minus the shared links. Filestash was a bitch to configure honestly, so I am super happy it was this easy. (Of course, other solutions were even more difficult to configure, no shade on Filestash. It's a decent project.)

Karl why does it have to be an iframe?

Cuz it looks nicer. Popups are sooo 2000's.

I just want any of my customizations to fit in with the rest of the UI. Files Browser is a very slick project and the last thing I want to do is hinder that by adding a clunky browser popup.

Are there any docs for adding to the right click menu, or any of these more advanced features? I didn't see anything on the docs site.

Karl For this, you would need to implement your own logic, eg root outside server document_root

Karl There won't be any option "share my files with user [abc]" as that is not really logical. Files Gallery doesn't "control" the file system, and a user will simply be able to access files from with a defined root dir.

Karl it needs to be clear that a "share" feature won't create virtual and/or temporary links, that provide specific permissions and features for that link. It will link to a file or dir on your file system, and the person that clicks it will need the link to be non-login (public) or they will need the login.

So I think I understand what you're getting at, and the scope you intend for Files Browser.

By default, you want to have the webserver serve the files, right? And Files Gallery just acts as a fancy index, with a few advanced features if you want them. All user files are stored under the webroot, and Files Gallery is able to craft a link to the files relative to the webroot that the webserver will be able to serve. In this configuration, you're right that there would be no need for shared links or anything, since each user can access all files, even if they are not shown the path in Files Gallery because of their root setting. I honestly really like how this works, and if that's the sole-supported configuration for Files Browser, makes sense.

But if you change the root to an absolute path pointing outside the webroot, things change. There is no longer a way for the webserver to serve the files directly, and instead of providing direct links, Files Gallery proxies the downloads itself. If you were to use “Copy link” and give that link to someone else, if they have a different root when they visit the page for whatever reason, they won't be able to access the file. Under this configuration, it is absolutely logical to have share links, and it's under such a configuration that I want to implement it. (This is not entirely true, but let's say it is for simplicity’s sake.)

Of course, I am not advocating you build out this shared link system or anything, just to serve this single use-case, which seems isn't even a supported configuration of Files Gallery. I plan to make it myself after all. But I hope you understand what I'm getting at and why such a system might be useful.

Karl If the shared link bypasses authentication, how will only she be able to view it?

I meant “she is only able to view the files and cannot modify them like Bob can”, not she is the only one able to use the link. In the example I gave, I was working under the assumption that Bob has full file manager access, while Alice does not, and can only view the files using the link Bob provides.

Karl what "settings" is it supposed to save that allows Alice to access Bob's dir?

Well, I did not go into specifics on purpose. But for this example, the link would be a public, unauthenticated link. The settings could simply be an array of config options to pass to Files Browser.

Karl

sev It sounds like it would be better for me to ignore the implementation, then. I will programmatically define the root, and likely won't change any other settings.

...Unless I add a page to allow users to customize their experience. Might as well if I go all-in on it, right? If I end up doing that, I could write the Files Gallery config array into the file you are expecting in that directory, and craft an Authorization header from the reverse proxy. I would leave the password blank, and block the header from being forwarded from client requests. Then I can make use of your infrastructure seamlessly with my own customizations.

A bit difficult for me to tell you exactly what to do as I don't know exactly what you intend to do. You can definitely modify the entire config based on your own login/environment.

sev I already got it working. It was very easy, and I'm ashamed I didn't think to try it before posting here.

'root' => "/srv/userfiles/$_ENV[REMOTE_USER]",

Indeed 👏

sev Are there any docs for adding to the right click menu, or any of these more advanced features? I didn't see anything on the docs site.

Start with the link below, and see contextmenu in the example code:
https://www.files.gallery/docs/javascript-config/

There are a few discussions using the contextmenu here:
https://forum.files.gallery/d/233-create-custom-link-for-sharing
https://forum.files.gallery/d/160-how-into-asig-to-item-action-call-exrternal-function
https://forum.files.gallery/d/518-how-replace-google-maps-with-leaflets

sev By default, you want to have the webserver serve the files, right?

That is beneficial, but that's not the point. Even if Files Gallery serves files via proxy .php?file=, it's still only serving files that are contained inside a dir that is within the users root dir. What you are asking for, is virtual groups of files, which is not a concept in Files Gallery, and not possible without a database, normally from an app that also needs to hi-jack your entire file system and virtualize it.

sev But if you change the root to an absolute path pointing outside the webroot, things change. There is no longer a way for the webserver to serve the files directly, and instead of providing direct links, Files Gallery proxies the downloads itself.

This is irrelevant though. Files Gallery will proxy files that are outside the document root, but they will still maintain in your own fixed directory structure. It only proxies the file for convenience because it's otherwise inaccessible by direct link.

sev If you were to use “Copy link” and give that link to someone else, if they have a different root when they visit the page for whatever reason, they won't be able to access the file.

Correct. Why would it work though? The users are operating with two entirely different roots. Maybe one user has a different file, but in the exact same location. It's not logical that they could access a different file in a different from a path relative to their own location. Of course, if there is a public (non-login) link, it would be persistent for all visitors.

sev Under this configuration, it is absolutely logical to have share links, and it's under such a configuration that I want to implement it.

How you intend to achieve that from a physical file system, I do not know ...

As noted, this would require a database, and a virtual file system, controlled by the application. Something entirely different than Files Gallery is.

sev I meant “she is only able to view the files and cannot modify them like Bob can”, not she is the only one able to use the link. In the example I gave, I was working under the assumption that Bob has full file manager access, while Alice does not, and can only view the files using the link Bob provides.

I think the point here, is what will this "link" look like, where will it get stored, and how are you going to assign specific settings to a single link? Is it temporary? If so, what mechanism will control this? And this link is public? I would assume so, because I don't see how you are supposed to limit this link to certain other users.

sev Well, I did not go into specifics on purpose. But for this example, the link would be a public, unauthenticated link. The settings could simply be an array of config options to pass to Files Browser.

At the very least here, you are looking at building a custom system using a database, that stores a link as a hash (for example). The database then contains the /path/ to the dir you want to share, and a json object of settings that you want to merge when this link is accessed. Accessing this link would then show the shared dir, but not anything else, not the original users dir, as this link is public (non-user specific). You would make sure that someone doesn't rename the original shared folder path name, else the DB entry path will become invalid.

The above is basically moving Files Gallery towards a virtual, database app (like Filerun and Nextcloud), where dirs can be virtualized, because they are owned by the application and managed entirely in the database.

sev

Karl I think the point here, is what will this "link" look like, where will it get stored, and how are you going to assign specific settings to a single link? Is it temporary? If so, what mechanism will control this? And this link is public? I would assume so, because I don't see how you are supposed to limit this link to certain other users.

Karl How you intend to achieve that from a physical file system, I do not know ...

Maybe an example will help 🙂

Here is my current Nginx config:

upstream files_gallery {
    server unix:/run/php-fpm83/files_gallery.sock;
}

server {
    server_name files.local;

    set $logname files_gallery;
    include includes/logging_access.conf;
    error_log /var/log/nginx/files_gallery.error.log;

    include includes/defaults.conf;
    include includes/authentik/outpost.conf;

    # timeout for choked downloads
    send_timeout 10m;

    # explore directories in the ui
    if ($uri ~ ^/(.+)/$) {
        return 302 /?$1;
    }

    # NOTE: files gallery has internal links pointing here
    location = /index.php {
        # if user has files with internal names in their dir that they're
        # trying to open, proxy them through the script instead of serving the
        # internal file with nginx
        set $x $arg_action#$arg_resize#$arg_file;
        if ($x ~ ^file##(?!(?:index|db)\.php$|_files_assets(?:$|/))) {
            # use rewrite for uri normalization
            rewrite ^ /$arg_file? redirect;
        }

        root /userfiles/$authentik_username;

        fastcgi_pass files_gallery;
        include fastcgi.conf;

        fastcgi_param SCRIPT_FILENAME /srv/www/files_gallery/index.php;

        # tuning upload buffers for http2
        # https://blog.cloudflare.com/delivering-http-2-upload-speed-improvements/
        client_body_buffer_size 512k;
        # set max upload size and increase upload timeout
        client_max_body_size 5G;
        client_body_timeout 2h;

        # more response buffers for better large file perf
        fastcgi_buffers 64 8k;
        # timeout for choked downloads
        fastcgi_read_timeout 10m;

        include includes/authentik/location.conf;
    }
    # open files gallery at root dir
    location = / {
        rewrite / /index.php last;
    }

    # custom db accessor
    location = /db.php {
        root /srv/www/files_gallery;

        fastcgi_pass files_gallery;
        include fastcgi.conf;

        include includes/authentik/location.conf;
    }

    # serve assets
    location /_files_assets/ {
        alias /srv/www/files_gallery/assets/;
        include includes/authentik/location.conf;
    }
    # serve user files
    location / {
        alias /userfiles/$authentik_username/;
        error_page 404 @show_file_in_ui;

        include includes/authentik/location.conf;
    }
    # make 404's go back to ui, looking for the specific file
    location @show_file_in_ui {
        rewrite ^/(.*)/([^/]+)$ /?$1#$2 redirect;
        rewrite ^/(.*) /?#$1 redirect;
    }
}

# vim:ft=nginx:sts=4:sw=4:et

If you couldn't tell, I use authentik for SSO, and get the username from it.

And the script for shared links (WIP but working):

<?php
require_once __DIR__ . '/_files/lib/vendor/autoload.php';

use Opis\JsonSchema\{
    Validator,
    Errors\ErrorFormatter,
};

$success = false;
$msg = 'unknown error';

try {
  $db = __DIR__ . '/_files/db.sql';

  $actions = ['initdb', 'share.create', 'share.get', 'share.auth'];
  if (empty($_GET['action']) || !in_array($action = $_GET['action'], $actions)) {
      throw new InvalidArgumentException('Parameter "action" must be one of "' .
        implode('", "', $actions) . '"');
  }

  if ($action == 'initdb') {
    if (file_exists($db)) {
      throw new RuntimeException('database already exists');
    }
    $db = new SQLite3($db);
    $db->enableExceptions(true);
    $db->exec('
      CREATE TABLE share (
        name TEXT,
        path TEXT,
        owner_uid TEXT,
        expiry INTEGER,
        perms TEXT
      );
      CREATE TABLE usersettings (
        uid TEXT PRIMARY KEY,
        path TEXT,
        owner TEXT,
        expiry INTEGER,
        perms TEXT
      );');
    $msg = 'created database';
    $success = true;
    goto end;
  }
  if (!file_exists($db)) {
    throw new RuntimeException('database does not exist, create it with action=initdb');
  }
  if (str_starts_with($action, 'share.')) {
    if ($action == 'share.create') {
      if (empty($_GET['name']) || empty($_GET['path'])) {
        throw new InvalidArgumentException('Must specify "name" and "path"');
      }
      $name = $_GET['name'];
      $path = $_GET['path'];
      $owner = $_SERVER['X_AUTHENTIK_UID'];
      $expiry = (int) @$_GET['expiry'];
      if ($expiry <= 0) {
        $expiry = time() + 60 * 60 * 24 * 7;
      }
      if (empty($_GET['perms'])) {
        $perms = json_decode('[{"type": "authenticated", "value": true}]', false);
      } else {
        $perms = json_decode($_GET['perms'], false, 4, JSON_THROW_ON_ERROR);
      }
      $result = (new Validator())->validate($perms, '{
        "$schema": "http://json-schema.org/draft-07/schema#",
        "type": "array",
        "additionalItems": false,
        "items": {
          "type": "object",
          "additionalProperties": false,
          "required": ["type"],
          "allOf": [{
            "if": {"properties": {"type": {"const": "default"}}},
            "then": {"required": ["config"]},
            "else": {"required": ["value"]}
          }, {
            "if": {"properties": {"type": {"const": "authenticated"}}},
            "then": {"properties": {"value": {"type": "boolean"}}},
            "else": {
              "if": {"properties": {"type": {"const": "access_count"}}},
              "then": {"properties": {"value": {"type": "integer"}}},
              "else": {"properties": {"value": {"type": "string"}}}
            }
          }],
          "properties": {
            "type": {
              "title": "Access control type",
              "enum": ["default", "authenticated", "uid", "email", "password", "access_count", "agree_terms"]
            },
            "value": {},
            "config": {
              "type": "object",
              "minProperties": 1,
              "additionalProperties": false,
              "properties": {
                "load_images": {
                  "title": "Show image previews",
                  "type": "boolean"
                },
                "video_thumbs": {
                  "title": "Show video thumbnails",
                  "type": "boolean"
                },
                "folder_preview_image": {
                  "title": "Show folder previews",
                  "type": "boolean"
                },
                "menu_enabled": {
                  "title": "Enable the navigation sidebar",
                  "type": "boolean"
                },
                "menu_max_depth": {
                  "title": "Menu directory depth",
                  "type": "boolean"
                },
                "menu_sort": {
                  "title": "Menu sort order",
                  "type": "string",
                  "enum": ["name_asc", "name_desc", "date_asc", "date_desc"]
                },
                "layout": {
                  "title": "Layout",
                  "type": "string",
                  "enum": ["list", "imagelist", "blocks", "grid", "rows", "columns"]
                },
                "sort": {
                  "title": "Sort order",
                  "type": "string",
                  "enum": ["name_asc", "name_desc", "date_asc", "date_desc"]
                },
                "sort_dirs_first": {
                  "title": "Sort directories first",
                  "type": "boolean"
                },
                "files_exclude": {
                  "title": "Exclude files matching pattern",
                  "type": "string"
                },
                "dirs_exclude": {
                  "title": "Exclude directories matching pattern",
                  "type": "string"
                },
                "click": {
                  "title": "Mouse click action",
                  "type": "string",
                  "enum": ["popup", "modal", "download", "window", "menu"]
                },
                "context_menu": {
                  "title": "Enable right-click context menu",
                  "type": "boolean"
                },
                "prevent_right_click": {
                  "title": "Block right-click on images",
                  "type": "boolean"
                },
                "allow_upload": { "type": "boolean" },
                "allow_delete": { "type": "boolean" },
                "allow_rename": { "type": "boolean" },
                "allow_new_folder": { "type": "boolean" },
                "allow_new_file": { "type": "boolean" },
                "allow_duplicate": { "type": "boolean" },
                "allow_text_edit": { "type": "boolean" },
                "allow_zip": { "type": "boolean" },
                "allow_unzip": { "type": "boolean" },
                "allow_move": { "type": "boolean" },
                "allow_copy": { "type": "boolean" },
                "allow_download": { "type": "boolean" },
                "allow_mass_download": { "type": "boolean" },
                "allow_mass_copy_links": { "type": "boolean" },
                "upload_allowed_file_types": {
                  "title": "Allowed file types for upload",
                  "type": "string"
                },
                "upload_max_filesize": {
                  "title": "Max size of uploaded files",
                  "type": "integer",
                  "minimum": 0
                },
                "lang_default": {
                  "title": "Default interface language",
                  "type": "string"
                }
              }
            },
            "onerror": {
              "type": "string"
            }
          }
        }
      }');
      if (!$result->isValid()) {
        throw new InvalidArgumentException('Error validating "perms": ' .
          json_encode((new ErrorFormatter)->format($result->error())));
      }
      $db = new PDO('sqlite:'.$db, options: [
        PDO::ATTR_TIMEOUT => 1,
        PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION
      ]);
      $db
        ->prepare('INSERT INTO share VALUES (:name, :path, :owner, :expiry, :perms)')
        ->execute([':name'=>$name, ':path'=>$path, ':owner'=>$owner,
                   ':expiry'=>$expiry, ':perms'=>json_encode($perms)]);
      $msg = ['id' => $db->lastInsertId()];
      $success = true;
      goto end;
    }
  }
  http_response_code(502);
  $msg = 'Not implemented';
} catch (Throwable $e) {
  $msg = $e->__toString();
  while($e = $e->getPrevious()) {
    $msg .= "\nPrevious exception: " . $e->__toString();
  }
  $msg = str_replace(__DIR__, '', $msg);
}

end:
header('Content-Type: application/json');
if (is_array($msg)) {
  $msg['success'] = $success;
  echo json_encode($msg, JSON_THROW_ON_ERROR, 2);
} else {
  echo json_encode(['success'=>$success, 'msg'=>$msg]);
}

// vim:et:sts=2:sw=2
?>

Currently I only have the database and adding new entries done. For example, to add the shared link https://files.local/s/MyShareName, and have it show the files in the directory somepath inside my files, and to only allow authenticated users to be able to access the link, you might do:

> GET https://files.local/db.php?action=share.create&name=MyShareName&path=/sev/somepath&perms=[{%22type%22:%20%22authenticated%22,%20%22value%22:%20true}]
< {"id":"4","success":true}

I think it's pretty straightforward.

You may also notice the usersettings table; I do plan to also add persistent per-user settings. If your implementation ends up being better I will look at supplanting it.

I also wrote a JSON validator to ensure correctness before writing to the database. I am planning to use the hinting in the schema to build the UI programmatically, if that ends up being feasible.

The config is basically done for now, though I have not yet added routing for the shared link. Routing from Nginx will be pretty simple:

Use auth_request /db.php?action=share.auth&name=$1 to send a subrequest to authenticate the user accessing the share
db.php will look up the share to see if it exists, and validate the requested permissions
If any permissions require user interaction, redirect to db.php?action=share.validate (real link TBD)
If passing (either original subrequest or redirect), start a PHP session to store the success and share path, and redirect back to original page with a header containing the share path
Use e.g. auth_request_set $files_gallery_share_root $upstream_http_x_files_gallery_share_root to pull in the share path from the subrequest; can pull it from the PHP session if already authenticated, to avoid multiple DB lookups for successive requests

The (not) fun part is going to be the JavaScript for the UI, because I'm not really a fan of writing it 🙂

Anyway, I do still disagree on calling this a virtualization of the filesystem. All I am doing is changing the root. I am not in any way interfering with how Files Gallery works, if anything I am merely extrapolating on its strengths. I wonder if this example might help you understand what it is I am trying to do.

Karl

Looks good to me, as long as you have a database and full code in place to create and maintain the virtual link.

This isn't "sharing" on the same level as other similar apps, where a user could for example log in as usual and see shared files in addition to their own folders. That normally requires the file system to be locked to the database, so we can virtualize what "folders" each user could view. In your case, you are creating a unique link to view a unique folder, regardless of "user" (although it could be restricted to certain users in your own system). It's also fragile, as if someone renames the path (the user that owns the dir, or someone renames directly on the file system), the link will become invalid. But if this is not really a concern, then I assume it should work nicely.

sev The (not) fun part is going to be the JavaScript for the UI, because I'm not really a fan of writing it 🙂

What do you intend to do? If you just want to create a share button, that is not too complicated.

Anyway, really good work. I don't mean to be negative about custom implementations. I just want to make it crystal clear up front about what I consider "limitations", before I get you and me intro trouble.

sev

Karl But if this is not really a concern, then I assume it should work nicely.

It isn't. I intend my services to be used by people that have some idea of what they're doing. And I just thought of this, but I could also save inodes instead of paths... though I've never tried to look up a path by inode before (and it varies by FS) so I'll have to figure that out.

Karl What do you intend to do? If you just want to create a share button, that is not too complicated.

Share button in file/folder context menu
"Share" UI popup that asks for information and sends to db.php XHR GET
Show response from API

User button on top right (maybe replacing the light/dark button)
Context menu/popup for clicking user icon, containing "View all shares", "User settings", and (if it was moved) light/dark toggle
"View all shares" UI popup
"User settings" UI popup

Design for db.php when prompting for user information

If I can figure out how you make popups and if I can hook into that, things should be pretty easy. The rest is moving elements around either with Nginx sub_filter, CSS, or JS, and adding a few buttons.

Karl I don't mean to be negative about custom implementations. I just want to make it crystal clear up front about what I consider "limitations", before I get you and me intro trouble.

I understand. And with this being a commercial product, you have to focus more on your image to customers, and not set them up for failure 🙂 But I am here to break limitations and implement hacky shit, I know what I'm doing is not optimal.

In any case, I appreciate all the support and truly excellent community interaction.

Karl

sev Share button in file/folder context menu
"Share" UI popup that asks for information and sends to db.php XHR GET
Show response from API

User button on top right (maybe replacing the light/dark button)
Context menu/popup for clicking user icon, containing "View all shares", "User settings", and (if it was moved) light/dark toggle
"View all shares" UI popup
"User settings" UI popup

Design for db.php when prompting for user information

The first item "Share button in file/folder context menu" can be done from custom JS contextmenu API, which then can be assigned to do anything you want, like open a popup or a modal of some sort, that displays whatever you want.

All the separate "UI"'s you mention however, need to be designed and implemented by yourself. Even if you design these interfaces separately in your own html (iframe or popup), this would be a design challenge. If you additionally want to try to "bake" them into the existing Files Gallery interface, then it gets very complicated. Personally, I would try to keep it abstract, either in popup or an iframe in a modal.

As for adding buttons in the topbar, this is slightly easier, but you still need to design them with icons, and check how they render on small screens. And you would need to assign some javascript that triggers an interface when clicked.

sev

Ran into an issue. I tried to set up custom.js like your guide says but found it wasn't being linked. I looked into it and noticed Path::urlpath bails early if the path is not within document_root. While this probably makes sense in normal usage, if you're using a reverse proxy with split routing like I am, it's trivial to root URIs in other directories during routing. And if you want to share files in other directories without changing the location of Files Gallery, changing document root is essential. It would be great if there were an option to bypass the docroot check and allow searching and returning paths based on __dir__, even if outside docroot.

These are the features that I can see are disabled because of this:

Dir::set_json_cache_url() doesn't work
Client access to menu caches doesn't work, same as if menu_cache_validate is set
image_resize_cache_direct doesn't work
Watermark files can't be loaded
U::uinclude doesn't work, which prevents plugins and custom JS/CSS/HTML/etc from loading

Also, _files* is forcefully excluded, even if __dir__ where _files would otherwise live is not under docroot.

Could you consider adding a check to bypass the docroot check? For now I've done so myself on my local copy.

Karl

sev I'm not sure how you are setup, but a CSS file needs to be within document root to be able to load from browser. No matter what you do with symlinks and/or Nginx, the url would need to be public ... How else is it supposed to load in browser?

sev And if you want to share files in other directories without changing the location of Files Gallery, changing document root is essential.

You share files in other directories by setting the Files gallery config root option. I don't see what this has to do with changing the document root of your nginx server. PHP and Files Gallery will use $_SERVER['DOCUMENT_ROOT'] to determine what files are readable from the www, as this is kinda the point of having a document root.

sev Dir::set_json_cache_url() doesn't work
Client access to menu caches doesn't work, same as if menu_cache_validate is set
image_resize_cache_direct doesn't work
Watermark files can't be loaded
U::uinclude doesn't work, which prevents plugins and custom JS/CSS/HTML/etc from loading

They will only work if there is access for the www yes. For example, as in the name image_resize_cache_direct, means the browser could load cache files (*.jpg) directly by url path, if they are available. If not, PHP will need to load them as proxy. I don't see how Files Gallery is supposed to create an URL for these images, if they are not in document root ... What would that url look like?

sev Also, _files* is forcefully excluded, even if dir where _files would otherwise live is not under docroot.

I'm not sure what you mean by this. Yes all _files* are always excluded. If a user has root set to somewhere in document root, or outside document root, it doesn't really matter ... These files are supposed to be hidden. Why would you want them visible? I mean, this is kinda the entire point of underscore _files.

sev Could you consider adding a check to bypass the docroot check? For now I've done so myself on my local copy.

This isn't logical. The point of document root check, is to be able to calculate the URL a file would load from in the browser. If you have document root /var/www/website/public and then you have a file /some/other/path (outside document root), then what is the "url" for that file? That is the entire point of the document root check, to see if the file can be loaded from browser. How else is that file loadable from the browser, and even if it is, how is Files Gallery supposed to know this, and can create the url for the browser?

sev

Karl I really have to say, I think you are confused.

That's what I'd say about you, unfortunately. Despite my best efforts it seems I haven't been able to convey the actual issue that I am encountering and we are talking about two different things at every step.

Case in point:

Karl Files Gallery root might not be inside Config::$__dir__

I'm not talking about where root is! I haven't ever been talking about that, and it isn't the source of any issues. If you look at my first post about this, you will see where the problem comes from:

sev I tried to set up custom.js like your guide says but found it wasn't being linked. I looked into it and noticed Path::urlpath bails early if the path is not within document_root.

The problem there is that the file custom.js—which normally lives in /_files/js, not talking about root or any user files here—doesn't have a link inserted for it, because it is technically outside of DOCUMENT_ROOT.

...But, if I disable the check that sees if it is outside DOCUMENT_ROOT, the link is still made (since it is relative to __DIR__, and it can build links relative to __DIR__) and _files/js/custom.js is now inserted into the page. And my proxy sends the file, because that's what I configured it to do. Even though, yes, it is outside of PHP's DOCUMENT_ROOT. It still builds a link and the file is still served to the client.

From there I have just been trying to explain the issue, and the details around it... Our misunderstanding eachother started from the very first post:

Karl I'm not sure how you are setup, but a CSS file needs to be within document root to be able to load from browser.

This simply isn't true, and I would like to think I showed you how such a thing is possible, and explained how and why it's possible, and why you might want or need to do such a thing.

Karl PHP and Files Gallery will use $_SERVER['DOCUMENT_ROOT'] to determine what files are readable from the www, as this is kinda the point of having a document root.

But the Files Gallery root I want to serve is outside of DOCUMENT_ROOT. Unfortunately, there is simply no way I can have it be inside of DOCUMENT_ROOT, unless I point DOCUMENT_ROOT at where I am pointing root, which is what I have done. But now checks fail related to $storagepath, caching, and etc., because now they are outside of DOCUMENT_ROOT. I am unable to have both root and $storagepath be inside of DOCUMENT_ROOT, I can only have one or the other. It just doesn't work in my environment. Now you may certainly argue that this situation is outside of the use-case and support of Files Browser, and that's fine if so. But otherwise, this is clearly a limitation of the software.

Karl If you have document root /var/www/website/public and then you have a file /some/other/path (outside document root), then what is the "url" for that file?

It can be whatever you want it to be. There is no limitation or restriction. DOCUMENT_ROOT is merely a guideline and a convention. It's not even part of the CGI spec that the [F]CGI SAPI modules were based on, it's an Apache-derived thing. In this case, I merely suggested that __DIR__ could be used as a common root for building URLs around $storagepath if it is outside DOCUMENT_ROOT. If $storagepath isn't inside __DIR__, then that does change things, and the logic would need to account for that as well.

Another approach would simply be to have a config setting that tells Files Gallery "my $storagepath is available on my web server at the URI /_files" and then Files Gallery can build its URLs out of that. If the URL can be automatically created without this configuration, great... but if it can't, that value can be used as a fallback—or it can alternatively override whatever Files Gallery would otherwise generate based on the filesystem and DOCUMENT_ROOT.

If you still don't understand what the issue is, let's just move on. I have deployed changes to make it work for me, and I have no problem maintaining them myself. At the very least, I must thank you for providing Files Gallery in such an open and modifiable manner 🙂

Back to the JavaScript:

sev What is _h, and what code have you added, and/or perhaps a screenshot?

Error: Uncaught ReferenceError: _h is not defined

The code

sev

_c.config = {

  // custom context menu (dropdown) options
  contextmenu: {
    rotate: {
      text: 'rotate',
      // icon name, or include custom icon <path d="..."> value from https://pictogrammers.com/library/mdi/
      icon: 'rotate_right',
      condition: (item) => item.browser_image,
      // href: (item) => { return item.url_path; },
      action: (item) => _h.popup(null, null, null, item.url_path),
      // class: 'mybutton'
    },
  },

}

This is copied 1:1 from the Advanced Javascript Config documentation. And I looked inside the Files Browser bundle, and I can see where var _h is defined. I can only imagine it isn't in scope, so the action is unable to call it.

sev

Karl I'm not sure how you are setup, but a CSS file needs to be within document root to be able to load from browser.

No, it doesn't. My configuration is living proof. The "document root" that Files Gallery sees is not always the document root. It can change based on the processing of the proxy.

Hell, I don't even need a docroot. I can serve files directly without ever setting it. I can call PHP without setting it. There's nothing stopping that other than convention.

Karl No matter what you do with symlinks and/or Nginx, the url would need to be public ... How else is it supposed to load in browser?

    location = /index.php {
        root /userfiles/$authentik_username;

        fastcgi_pass files_gallery;
        include fastcgi.conf;

        fastcgi_param SCRIPT_FILENAME /srv/www/files_gallery/index.php;
    }
    [...]
    location /_files/ {
        alias /srv/www/files_gallery/_files/;
    }

Just because the document root isn't the same in Files Gallery, doesn't mean the URL isn't public. This is rather a side-effect of the assumption that all web servers maintain a consistent root, when every single one has some kind of built in internal redirection that you can use to make that not true. Or just straight up change the root entirely.

Fact is, I have configured my system so that the files in _files—despite the fact they are not in what Files Gallery knows to be the document root—resolve correctly when the client asks for them. They are still, however, in the application directory, so Files Gallery can still build links for them.

Karl I don't see how Files Gallery is supposed to create an URL for these images, if they are not in document root ... What would that url look like?

Exactly as you have it coded... using Config::$__dir__ as the root, instead of Config::$document_root:

  public static function urlpath($path){

    // return if item is not within server document root, because it can't be accessed by www url
    // vvv    commented this   vvv
    //if(!self::is_within_docroot($path)) return false;

    // if item is within application dir, we can return relative path
    // vvv   this code gets used   vvv
    if(self::is_within_path($path, Config::$__dir__)) return $path === Config::$__dir__ ? '.' : substr($path, strlen(Config::$__dir__) + 1);

    // return root-relative path
    return $path === Config::$document_root ? '/' : substr($path, strlen(Config::$document_root));
  }

Karl These files are supposed to be hidden. Why would you want them visible? I mean, this is kinda the entire point of underscore _files.

They aren't visible. That path does not exist on the filesystem under the docroot. It exists under the application directory __dir__. Using PHP file proxying as can be enabled, I can have an index.php or a _files or whatever else in the new docroot just fine, and if I forcefully disable the exclusion check, it works with no issue. Rather, it may be confusing to users if they try to make a file curiously named _filexyz and it disappears on them.

Karl How else is that file loadable from the browser, and even if it is, how is Files Gallery supposed to know this, and can create the url for the browser?

Proxies.
It doesn't know that, that's why you would add a config value to bypass the check. It is an exercise of the administrator to make sure it works, not the application.
Use __dir__ as mentioned.

sev

Karl You share files in other directories by setting the Files gallery config root option. I don't see what this has to do with changing the document root of your nginx server. PHP and Files Gallery will use $_SERVER['DOCUMENT_ROOT'] to determine what files are readable from the www, as this is kinda the point of having a document root.

I neglected to respond to this. Yes, Files Gallery will use DOCUMENT_ROOT, which in Nginx's fastcgi.conf, is set to $document_root:

fastcgi_param  DOCUMENT_ROOT      $document_root;

What Nginx's root is doesn't matter at all in this situation, I am only using it to populate $document_root. There are no file-related directives being used—Nginx will never attempt to look up a file in the root. You could replace root /userfiles/$authentik_username with fastcgi_param DOCUMENT_ROOT /userfiles/$authentik_username and the effect would be the same.

Karl

PHP doesn't know about your nginx aliases. Just removing the check for document root, doesn't mean the path can be converted to an url.

sev Exactly as you have it coded... using Config::$dir as the root, instead of Config::$document_root:

This would assume there is a dir in document_root by that name, but then you are pointing it elsewhere via nginx. If the dir, which you are not using, is not there, it would fail.

sev Proxies.

I don't know what this is an answer about.

sev It doesn't know that, that's why you would add a config value to bypass the check. It is an exercise of the administrator to make sure it works, not the application.

I don't know what you mean " It is an exercise of the administrator to make sure it works, not the application.". You just happen to have your own files and dirs starting with _files* that are supposed to be visible?

sev Use dir as mentioned.

This is the dir of the index.php file, which is int he document dir, but your root may (and in your case probably does) point somewhere entirely different, so the __dir__ for the index.php would be irrelevant.

sev

That aside, after getting the script loading and using your contextmenu extension as shown in Advanced Javascript Config, _h is coming up undefined, so I can't make popups.

Karl

sev That aside, after getting the script loading and using your contextmenu extension as shown in Advanced Javascript Config, _h is coming up undefined, so I can't make popups.

What is _h, and what code have you added, and/or perhaps a screenshot? It's already difficult to diagnose with a direct testing link, but I need to see your code to understand why something isn't working.

sev

I really think we're having trouble understanding each other.

Karl PHP doesn't know about your nginx aliases.

Karl If the dir, which you are not using, is not there, it would fail.

Yes, exactly. That is what "It is an exercise of the administrator to make sure it works, not the application." means. If the administrator does not do the proper pre-configuration, and were to enable such an option as I suggest, it is their fault if it doesn't work, not Files Gallery.

Karl Just removing the check for document root, doesn't mean the path can be converted to an url.

Yes, it does in my situation.

Karl This would assume there is a dir in document_root by that name

No, it doesn't.

U::uinclude uses Config::$__dir__ as an alternative to Config::$storagepath if the file is outside of $storagepath but still inside the Config::$document_root. But as I explained, my DOCUMENT_ROOT in PHP is pointed at the user files I want to show in Files Gallery, not the application directory where the PHP file is.

Config::$__dir__ (or rather, __DIR__) is where the index.php lives. PHP's DOCUMENT_ROOT does not have to be this path. And in my configuration, it is not. PHP (at least the [F]CGI SAPI) can load files outside of DOCUMENT_ROOT. More specifically, the file it loads is SCRIPT_FILENAME, irrelevant of any other setting. It is only convention, later standardized in PHP documentation, that __DIR__ and DOCUMENT_ROOT are equivalent, but this is not at all required or enforced in any way. In fact, DOCUMENT_ROOT is not necessary at all for PHP to function. It is only ever used inside PHP if you have cgi.fix_pathinfo enabled, otherwise it is passed on to the script and PHP does nothing else with it.

Checking if Config::$storagepath is inside DOCUMENT_ROOT will not always be true, and instead, it would be trivial to also or alternatively check where the script lives, Config::$__dir__. And as I said, it can be left up to the administrator to make sure these paths are routable.

By commenting out the line that I did, uinclude is able to construct a URL, because the files are still inside Config::$__dir__. And in Nginx, I route that manually to the correct location. Does this make sense?

Let me rephrase my original question: Would it be possible to allow Files Browser to build links based on Config::$document_root or Config::$__dir__, depending on a configuration setting? Because in my case, Config::$storagedir will never be inside DOCUMENT_ROOT, it will always be inside __DIR__.

Karl

Karl What is _h, and what code have you added, and/or perhaps a screenshot? It's already difficult to diagnose with a direct testing link, but I need to see your code to understand why something isn't working.

I am using the example present in the documentation. I have not modified it at all.

_c.config = {

  // custom context menu (dropdown) options
  contextmenu: {
    rotate: {
      text: 'rotate',
      // icon name, or include custom icon <path d="..."> value from https://pictogrammers.com/library/mdi/
      icon: 'rotate_right',
      condition: (item) => item.browser_image,
      // href: (item) => { return item.url_path; },
      action: (item) => _h.popup(null, null, null, item.url_path),
      // class: 'mybutton'
    },
  },

}

Karl

About public urls to be loaded from the browser. Let's say you have document root /var/www/mywebsite/public and application at /var/www/mywebsite/public/index.php. Then you have assigned Files Gallery root to /some/abstract/path. How is PHP supposed to know the browser path /some/abstract/path/image.jpg? By default, the file would be inaccessible by direct link in browser. You may have assigned it via location and alias in Nginx, but PHP doesn't know that of course.

Karl

sev Yes, exactly. That is what "It is an exercise of the administrator to make sure it works, not the application." means. If the administrator does not do the proper pre-configuration, and were to enable such an option as I suggest, it is their fault if it doesn't work, not Files Gallery.

But the main reason we check if a file is in document root in the first place, is BEFORE we attempt to extrapolate the url path that the browser will use to load files. For example document root /var/www/website and file path /var/www/website/path/to/file.jpg. From this, we can extrapolate the URL /path/to/file.jpg.

If you have document root /var/www/website and file path /something/else/file.jpg, yes you can skip the test to check if the file is within document root, but then Files Gallery will FAIL to calculate the public www path to the file. It will fail and/or be wrong. Besides the fact that we can't calculate the public www path from /something/else/file.jpg because it's not in the document root, and Files Gallery has no means to think it's available by public url.

sev Yes, it does, and no, it doesn't.

No examples, just yes and no. This is plain wrong. Many files are inaccessible from the web. Yes they can be made available in Nginx, but PHP doesn't know this.

sev And in my configuration, it is not. PHP (at least the [F]CGI SAPI) can load files outside of DOCUMENT_ROOT.

Yes, but now you are talking about loading files by PHP proxy. For example index.php?file=get/css/file.css. This is possible, but it's NOT direct file access in browser, as surely we are discussing. This is why we have checks in Files Gallery, to check files that are DIRECTLY accessible in browser. It is possible to proxy EVERYTHING by PHP, but this should be avoided when possible, because proxying by PHP is slower.

So just to conclude, yes of course you can load files via PHP into browser, but the point of checking if files are within document root, is to check if the file can be loaded directly in browser. Surely that makes sense.

sev

Karl But the main reason we check if a file is in document root in the first place, is BEFORE we attempt to extrapolate the url path that the browser will use to load files. For example document root /var/www/website and file path /var/www/website/path/to/file.jpg. From this, we can extrapolate the URL /path/to/file.jpg.

Exactly, so replace the document root in that calculation with Config::$__dir__. I have already shown it works with a little bit of extra configuration on the proxy side.

Karl but then Files Gallery will FAIL to calculate the public www path to the file. It will fail and/or be wrong.

It won't, if you use __DIR__ or really any other directory that Files Gallery knows about, and is able to traverse, and configure your proxy to serve those files, as I am trying to explain.

Karl No examples, just yes and no.

Please read the text immediately below that. I went into great detail to give you as much information as possible.

Karl This is plain wrong.

I told you how it works. I don't know how else to explain it to you. I have a working setup right this moment, I have provided the configs, I have provided the research. We are not making a connection somewhere and I don't know what else I can do to help.

Karl Many files are inaccessible from the web. Yes they can be made available in Nginx, but PHP doesn't know this.

But it does know the files exist on the filesystem, and with that knowledge, it can still build paths based on assumptions. And if your proxy is configured correctly, those links WILL work and WILL be accessible. Again, it is up to the person configuring the service to ensure that the links work. Files Gallery does not have an easy way of confirming if they do or not.

If you want to be pedantic, Files Gallery already makes the (incorrect) assumption that the files will always be in DOCUMENT_ROOT, which is not a given. It is true in 99% of configurations but not 100%, and that last 1% is not necessarily a misconfiguration.

Karl Yes, but now you are talking about loading files by PHP proxy.

No I'm not. By "files" I meant scripts, like index.php. I apologize if I was not clear.