Programmatically change served root + share links

sev · 2024-11-07T01:32:42+00:00

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...

sev

Karl

The issue is in urlpath(): It checks if $path is in __DIR__ and builds a relative path based on that. But if your reverse proxy is serving requests at a different URL, it can wrongly assume a relative link where one will not work.

For example:

Files Gallery index.php and _files are in /srv/www
storage_path is either the default _files or absolute path /srv/www/_files
Reverse proxy serves /srv/www/index.php for the request http://example.com/some/other/dir/
U::uinclude('js/custom.js') will return relative path _files/js/custom.js because _files is in __DIR__ next to index.php
The browser will attempt to load /some/other/dir/_files/js/custom.js which doesn't exist

So in reality, storage_path and other paths built with urlpath() end up relative to the current URL, instead of to Files Gallery.

This is the same problem you solved by adding root_url_path, and you could probably solve it the same way: by adding another config var, such as index_url_path, to override the return value of urlpath, like you do in rooturlpath/get_root_url_path.

With that, for the above example, setting index_url_path to / would make urlpath() would build the path /_files/js/custom.js instead.

Karl

sev This is the same problem you solved by adding root_url_path, and you could probably solve it the same way: by adding another config var, such as index_url_path, to override the return value of urlpath, like you do in rooturlpath/get_root_url_path.

So what files would index_url_path be used for? Like custom.css? That would only work if storage_path is in the default location relative to index.php. And if they are, we don't really need index_url_path in the first place, because we could just load the file relative to index.php which is already loaded into browser from the correct url path.

It's a bit unusual that you need to serve different requests from different urls instead of just using natural paths. Seems clumsy. Any app can only know of the path of the file on disk of course. Even with symlinks, we can just follow the symlink.

sev

Please test the example scenario I gave and you'll see the issue. I don't think I will be able to explain it well enough. Let's avoid the back and forth we had before.

sev

Files Gallery index.php and _files are in /srv/www

storage_path is either the default _files or absolute path /srv/www/_files

Reverse proxy serves /srv/www/index.php for the request http://example.com/some/other/dir/

U::uinclude('js/custom.js') will return relative path _files/js/custom.js because _files is in __DIR__ next to index.php

The browser will attempt to load /some/other/dir/_files/js/custom.js which doesn't exist

To simply reiterate, when a reverse proxy is involved, it is incorrect to assume that __DIR__ == dirname($_SERVER[REQUEST_URI]), and that's what urlpath() does right now. And again for reference, this is the part of urlpath() that is responsible for this issue:

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

We don't load cache directly by url, unless you use a special setting like image_resize_cache_direct

Didn't know that, is that a new feature? In any case, I must have missed it.

sev

Karl

So what files would index_url_path be used for?

index_url_path would override the logic in urlpath(), just like you have root_url_path to override the logic in rooturlpath() (get_root_url_path()).

storage_path and anything else that uses urlpath() would be affected. I only used U::uinclude as an obvious example, I believe it also affects cache etc.

That would only work if storage_path is in the default location relative to index.php.

I don't believe so? I don't understand what you mean by this.

And if they are, we don't really need index_url_path in the first place, because we could just load the file relative to index.php which is already loaded into browser from the correct url path.

Not if your reverse proxy serves from the "incorrect" URL path. Just like how your root may be served an "incorrect" path, which is fixed using root_url_path.

The problem where the root location on the filesystem may not directly map to where the files are reachable through the reverse proxy, also applies to urlpath().

For a real world example, if you look at my addon, I serve shared files from /s/somesharename/. But this path does not exist on the filesystem, it is a virtual path. So without patching out the __DIR__ relative check, Files Gallery will try to serve /s/somesharename/js/custom.js which doesn't exist.

It's a bit unusual that you need to serve different requests from different urls instead of just using natural paths.

That's the thing, all my application data files live next to Files Gallery. But Files Gallery incorrectly builds the URL to those files because it basically thinks __DIR__/index.php == $__DIR__/$SERVER['REQUEST_URI'], which isn't always the case.

Without virtual routing or any other funny business by the reverse proxy, this is not an issue. But you added root_url_path because of that very possibility. This is just more of the same.

sev

Aside, I found a stylesheet issue: You have this rule in files.css:

[aria-disabled=true],
[disabled],
input:read-only {
  cursor:not-allowed
}

This affects all checkboxes, including custom ones I'm making, as well as the native layout-*-range inputs:

input:read-only will always select checkbox and range inputs, because the HTML spec is funny. This is technically correct behavior and affects all major browsers. I'd recommend getting rid of that rule and relying on [disabled] and [readonly] attributes exclusively.

Karl

sev Hmm, I see something strange going on for sure. I will look into it ...

Karl

sev input:read-only will always select checkbox and range inputs

This was resolved in Files Gallery 0.13.

Karl

sev index_url_path would override the logic in urlpath(), just like you have root_url_path to override the logic in rooturlpath() (get_root_url_path()).

But with index_url_path, I am pretty sure you mean the public url to the dir that contains index.php? Assuming the url can be used to load custom.css (and other files) relative to this dir. If they can, then why use index_url_path in the first place? ... The url would just be _files/css/custom.css from browser location (which must have loaded index.php).

sev That would only work if storage_path is in the default location relative to index.php.

I don't believe so? I don't understand what you mean by this.

Because if you have set storage_path to /some/entire/different/location, then it's no longer relative to index.php and certainly isn't index_url_path ... If anything, it should need to be renamed to storage_url_path. Loading files from the storage_path is optional of course ... We only use it for stuff like custom.css and custom.js. We don't load cache directly by url, unless you use a special setting like image_resize_cache_direct. Even then, it's not clear why you need to assign your own url's for the storage_path, which should be owned by Files Gallery.

sev That's the thing, all my application data files live next to Files Gallery. But Files Gallery incorrectly builds the URL to those files because it basically thinks DIR/index.php == $DIR/$SERVER['REQUEST_URI'], which isn't always the case.

It's unclear what you mean "my application data files". Files Gallery has it's own storage_path, and we know the absolute path to that. Even if you are using this for your own files, we can only in PHP assume that those files are accessible based on their physical path on disk, not some unknown virtual path.

If you have /var/www/website/public/index.php then you would normally have /var/www/website/public/_files/css/custom.css. It's unclear then why we can't just load _files/css/custom.css in browser relative to index. It doesn't sounds like you have even changed storage_path so I don't see why this wouldn't work. If it doesn't, surely we are complicating things here ...

Karl

It's hard to read your explanations.

sev 1. Files Gallery index.php and _files are in /srv/www

I had to read the above a couple of times, but it then means you have:

/srv/www/index.php
/srv/www/_files
/srv/www/_files/css/custom.css

When index.php is loaded into browser, the custom.css must be accessible from browser by relative url _files/css/custom.css. If it's not, then it seems strange that you need to block this access path by Nginx.

sev storage_path is either the default files or absolute path /srv/www/files

What do you mean "either" 🤔 What's the difference between the two above? You just said index.php and _files are in /srv/www so that would mean storage_page is in /srv/www/_files. What does "default _files" mean here anyway? Default in this case would be /srv/www/_files. I can't extract any "either" in the above.

sev To simply reiterate, when a reverse proxy is involved, it is incorrect to assume that DIR == dirname($_SERVER[REQUEST_URI])

There is nothing in the code like that. We are just assuming that your servers document root does not change per request, because if it does, PHP doesn't know what the url's would be anyway ... It's definitely not "wrong" to assume this, because I would say this works fine for everyone who uses Files Gallery for many years, and it's not like there are any other options. It seems pretty logical for an app to assume urls based on the physical structure of the application, especially when there are no other ways.

sev and that's what urlpath() does right now.

It definitely does not check __DIR__ == dirname($_SERVER[REQUEST_URI]) ... Not even sure what you are trying to say here. All PHP requests go to index.php. All file requests go directly to the file from javascript. I would never need $_SERVER[REQUEST_URI] anyway, because we already know it goes to index.php. It's not like we can intercept requests to files from PHP.

sev > We don't load cache directly by url, unless you use a special setting like image_resize_cache_direct

Didn't know that, is that a new feature? In any case, I must have missed it.

I'm really not sure what you mean. There is nothing loaded directly into browser from inside the _files dir, unless you have specific features like custom.css or image_resize_cache_direct enabled. Never was. We need to load data through PHP, for several reasons, including validation and checking the cache files exist.

sev

Karl It's hard to read your explanations.

Trust me, I also have trouble explaining in a way that can get my point across...

Your post doesn't get anywhere near the actual issue I am trying to describe. Frankly I am at a loss.

This isn't a big issue, and in most normal uses cases of Files Gallery, no one would even run into it. So I don't really want to put any more energy into this.

Thanks for your time.

edit: I guess it may be helpful to try to clear up some misunderstandings:

What do you mean "either":

I meant storage_path could be set to either:

unset, so using default value
set to _files
set to /srv/www/_files

For the purposes of the example, the end result would be the same regardless of storage_path being set to any of these values.

There is nothing in the code like that.

__DIR__ == dirname($_SERVER[REQUEST_URI]) was not meant to be taken as a literal piece of code you've written. It wouldn't even work as-is. It was an abstraction. My point was that urlpath() behaves as if the location of index.php is always related to the request URI, but reverse proxy routing does not have to obey this.

Karl

In next release (coming soon), I will add an improvement for urlpath(), at least for files loaded from within storage_path. When the storage_path is relative to index.php (which is default, any very rarely changed), then it should be safe to assume that any file can be loaded by app-relative url _files/css/custom.css. Only if you have have a custom storage_path would this not be possible.

Karl

sev I do understand you are creating custom url's in nginx. But it's a bit strange how you assume there is something "wrong", as if Files Gallery has any other way of extracting URL's apart from the logical structure of the file system. I already created root_url_path for you, which I think only you are using. However, creating a storage_url_path for the _files dir which should belong to Files Gallery, seems a stretch.

sev DIR == dirname($_SERVER[REQUEST_URI]) was not meant to be taken as a literal piece of code you've written. It wouldn't even work as-is. It was an abstraction. My point was that urlpath() behaves as if the location of index.php is always related to the request URI, but reverse proxy routing does not have to obey this.

Although it's pointless to debate this, the above definitely isn't entirely accurate. By default, we don't really care about the "location" of index.php, wether you speak of the url path location or physical location. It's already loaded into browser. When we extrapolate urls to files (which must be generated from index.php of course), we initially compare their path vs document root to extract the url. This has nothing to do with the __DIR__ or the REQUEST_URI. As a "fallback" option, we check if the requested file is in the same dir as index.php, which should make the url relative to the app. Yes, I am aware none of the above works for you with custom nginx urls, but then of course nothing would work in your case apart from having to assign multiple url paths manually.

Considering we only have these limited options to calculate the url's, which work for everyone that don't need to create custom nginx urls, it doesn't seem logical to claim "it is incorrect to assume ...", when there are no other options.

« Previous Page