Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upload at root dir cause change file url #3216

Closed
golee opened this issue Oct 16, 2020 · 3 comments
Closed

Upload at root dir cause change file url #3216

golee opened this issue Oct 16, 2020 · 3 comments

Comments

@golee
Copy link

golee commented Oct 16, 2020

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',
        ),                   
    ),
);
@tamcy
Copy link

tamcy commented Jan 14, 2021

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.

@nao-pon
Copy link
Member

nao-pon commented Jun 10, 2021

This may be a bug in elFinder. I will start the investigation.

@nao-pon
Copy link
Member

nao-pon commented Jun 13, 2021

@tamcy @golee I fixed the problem maybe.

Can you see if the nightly build fixes this issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants