Elfinder: Upload at root dir cause change file url

Created on 16 Oct 2020 · 3Comments · Source: Studio-42/elFinder

I'm using aws s3 plugin for elfinder and there is a little issue on upload

If I upload a file to root directory then file url is changed weird.
(file.url from getFileCallback, handlers.select: just after upload):
http://localhost/elfinder/connector?cmd=file&target=fls1_7Iqk7YGs66aw7IO3IDIwMjAtMTAtMTMg7Jik7ZuEIDQzNC41MjExLjEyLTEucG5n

After refresh or reconnect to finder, the file.url changes to normal.
For example (what i want):
https://davmobxdwmerj.cloudfront.net/storage/myfilename.png

In case of uploading to subfolder (not root), there are no problems. It shows correct cloudfront path.

Followings are my settings

studio-42/elfinder 2.1.57
barryvdh/elfinder-flysystem-driver v0.2.1
league/flysystem-aws-s3-v3 1.0.29

$opts = array(
    'maxTargets' => 1,
    'roots' => array(
        array(
            'driver'        => 'Flysystem',           // driver for accessing file system (REQUIRED)
            'path'          => '/',                 // path to files (REQUIRED)
            'URL'           => 'https://'.$bucket['domain'] . '/' . $base . '/',         // URL to files (REQUIRED)
            'filesystem'    => new FileSystem(new AwsS3Adapter($client, $bucket['name'], $base, $opt)),
            'cache'         => 'session',
            'acceptedName'  => 'fileNameValidate',
        ),                   
    ),
);

connector connector bug

Source

golee

All 3 comments

I think I have encountered the exact same issue as yours. I sort of figured out the cause of the issue, but due to my limited experience on this library I am really not sure what’s the best way to resolve it.

When the finder is first initialized, the directory data is returned by the open command. In this command, the options data in the options key comes from the $volume->options($hash) function. The ['options']['url'] key returned by this function is not empty.

Now, when a file is uploaded via the upload command, the updated directory information is returned. This time, the directory information comes from the $sessionCache property of the elFinderVolumeDriver class, which has an empty ['options']['url'].

This new directory information with an empty ['options']['url'] is then sent back to the client via the changed attribute of the result JSON, and adapted by the client.

So, simply put, the root directory now no longer has a base URL defined.

According to my testing, the above also happens when the local file system driver is used. But you won't see a connector URL being returned when using this driver, because in this driver, every file entry has its own URL parameter defined. When this is set, the finder will use/return this URL directly, without relying on the directory's URL to generate the file path.

Now it's the barryvdh/elfinder-flysystem-driver. Unlike the local file system driver, this driver doesn't set the url parameter of the file entries -- the driver requires a getUrl() method to exist in the FlySystem adapter or it will not be able to return the public URL of the entry. But, adapters that implement \League\Flysystem\AdapterInterface do not contain this method by default.

As a result, since (1) the file entry doesn't have a public URL attached to it, and (2) the base URL of the root directory is now empty, the finder cannot serve the direct link. It falls back to the last resort to serve the connector’s URL, which acts as a proxy to the actual file content.

I can think of a quick and dirty fix, which is to add unset($dstDir['options']); before this line. This gets around with the issue, but may not really resolve the matter - like, is it correct to have a empty options.url in the file cache? Is it correct for the elfinder-flysystem-driver to not having the URL attribute to the file entries?

Update 2021/1/16: I decided to extend the FlySystem adapter class and implement the getUrl() method to see how it goes.