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

Not able to upload files larger than 1Mb via download plugin #3507

Closed
OTroccaz opened this issue Oct 17, 2018 · 6 comments
Closed

Not able to upload files larger than 1Mb via download plugin #3507

OTroccaz opened this issue Oct 17, 2018 · 6 comments
Labels
plugin: download type: bug A problem that should not be happening
Milestone

Comments

@OTroccaz
Copy link
Contributor

OTroccaz commented Oct 17, 2018

Hello,
I do not know if the size is really the problem, but I have no difficulty in downloading files smaller than 1 Mb whereas for larger files I have the error message "Bad File Detected". I tested for jpg and pdf files.
As for issue #3460 (remark: 1.5Mb file size), if I comment the check

	if(e107::getFile()->isClean($filePath) !== true)
	{
	//	@unlink($filePath);
	//	die('{"jsonrpc" : "2.0", "error" : {"code": 104, "message": "Bad File Detected."}, "id" : "id"}');
	}

the file is downloaded with "blob" as the name.

I looked in more detail at the table [_files]:
If pdf file size <1Mb:

 [_files] => Array
         (
             [file] => Array
                 (
                     [name] => test.pdf
                     [type] => application / pdf
                     [error] => 0
                     [size] => 556657
                 )
 
         )

If pdf file size > 1 MB:

[_files] => Array
        (
            [file] => Array
                (
                    [name] => blob
                    [type] => application / octet-stream
                    [error] => 0
                    [size] => 317864
                )

        )

=> "blob" name with no more extension =>no identified type => "Bad File Dectected"

So I commented

	if(!empty($_FILES['file']['name'])) // dropzone support v2.1.9
	{
		//$fileName = $_FILES['file']['name'];
	}

and everything is working.

I did not find an explanation but it is mainly to inform.

@CaMer0n
Copy link
Member

CaMer0n commented Oct 18, 2018

Thank you @OTroccaz !

@CaMer0n CaMer0n added the type: bug A problem that should not be happening label Oct 18, 2018
@CaMer0n
Copy link
Member

CaMer0n commented Nov 22, 2018

@Deltik Do you have any ideas about this?

@CaMer0n CaMer0n added this to the e107 2.2.0 milestone Nov 22, 2018
@Deltik
Copy link
Member

Deltik commented Nov 23, 2018

I have run a git bisect to determine the commit that introduced the "blob" filename bug:

root@e107dev:/var/www/html/e107# git checkout master
Previous HEAD position was 4264dc6f6 Make print great again!
Switched to branch 'master'
Your branch is up to date with 'origin/master'.
root@e107dev:/var/www/html/e107# git bisect start
root@e107dev:/var/www/html/e107# git bisect bad
root@e107dev:/var/www/html/e107# git checkout 4264dc6f66b006e588f8882b44fa466bf07b7d47
Note: checking out '4264dc6f66b006e588f8882b44fa466bf07b7d47'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at 4264dc6f6 Make print great again!
root@e107dev:/var/www/html/e107# git bisect good
Bisecting: 176 revisions left to test after this (roughly 8 steps)
[5212be3e1bc748b7b5211a100b39da28b2e7877a] Issue #3103 Added {SETIMAGE} to the custom-fields bootstrap3 example.
root@e107dev:/var/www/html/e107# git bisect bad
Bisecting: 87 revisions left to test after this (roughly 7 steps)
[37017652cc2eef536cac129b7bdc0e05e4e8757d] Merge pull request #3318 from SimSync/forum_editor
root@e107dev:/var/www/html/e107# git bisect bad
Bisecting: 45 revisions left to test after this (roughly 6 steps)
[26022e45079cc321e89360273843ba59f9080772] choose editor in forum and quick reply New prefs for forum: editor & quickreply editor makes it possible to choose between bbcode or tinymce (if installed and html enabled) quickreply gives the option to choose between the standard textarea or the choosen editor (from pref editor)
root@e107dev:/var/www/html/e107# git bisect good
Bisecting: 21 revisions left to test after this (roughly 5 steps)
[74f19820b059739caee9f7c85f9f738def8d1a81] Merge pull request #3315 from yesszus/patch-2
root@e107dev:/var/www/html/e107# git bisect good
Bisecting: 10 revisions left to test after this (roughly 4 steps)
[1ca781c9f4fa5a813fff5ec5bb6612ecbc5ed8fe] Grammatical edits
root@e107dev:/var/www/html/e107# git bisect bad
Bisecting: 5 revisions left to test after this (roughly 3 steps)
[bc8ccca5c2d0dbef0d97de742ef7d9d850e7d77c] Fixes #3311 - Update routine.
root@e107dev:/var/www/html/e107# git bisect good
Bisecting: 2 revisions left to test after this (roughly 2 steps)
[baf570071e8ec131e13e88fd41a688deb8f36ab0] mediapicker() mediaselector-preview-empty css class added.
root@e107dev:/var/www/html/e107# git bisect good
Bisecting: 0 revisions left to test after this (roughly 1 step)
[96037d5ac91b74aebc884596579da80aac6663ff] Issue #3276 Fix encoding on '+' in media categories. Mediapicker fixes. Media class cleanup.
root@e107dev:/var/www/html/e107# git bisect bad
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[f1329535a5df44850d581fdd943aad54c26532bf] MediaPicker drag-n-drop upload.
root@e107dev:/var/www/html/e107# git bisect bad
f1329535a5df44850d581fdd943aad54c26532bf is the first bad commit
commit f1329535a5df44850d581fdd943aad54c26532bf
Author: Cameron <e107inc@gmail.com>
Date:   Thu Jul 26 19:13:27 2018 -0700

    MediaPicker drag-n-drop upload.

:040000 040000 ec3aee3a02db855bcf7e09add87c2db748e2ac02 41f509012d5a58035dbfbe9c20c5e68ac32dac2e M      e107_admin
:040000 040000 aac42cdce3a22cd9bcd11e0a422e12a9aa3b3d09 7bb432bb88b20324c5e606a1a87db55dcc183301 M      e107_handlers
:040000 040000 9d0749feb53d77309fce713cace42508aefd1e78 41b88edb965252203a1a7eeebe7dece19a230a57 M      e107_themes
:040000 040000 6ddcdf6c063fce6f04611f37aa1d380d71d4b834 565f05aa7522da34e3fd22341e81cd69df8e0d61 M      e107_web

f132953 (link to line) caused the file uploaded to be named "blob".

When the filename is "blob", the file type is no longer determined properly, so whatever the file is is rejected.

The logic that does this is in e_media::processAjaxUpload(). Here is the relevant snippet:

                $fileName = isset($_REQUEST["name"]) ? $_REQUEST["name"] : '';

                // Clean the fileName for security reasons
                $fileName = preg_replace('/[^\w\._]+/', '_', $fileName);

                if(!empty($_FILES['file']['name'])) // dropzone support v2.1.9
                {
                        $fileName = $_FILES['file']['name'];
                }

The $fileName gets wiped out when there is something in $_FILES['file']['name'], and $_FILES['file']['name'] is equal to "blob".

@CaMer0n
Copy link
Member

CaMer0n commented Nov 23, 2018

CaMer0n added a commit that referenced this issue Nov 23, 2018
@CaMer0n
Copy link
Member

CaMer0n commented Nov 23, 2018

@OTroccaz Please update and close this issue if the problem has been corrected. Thank you.

@OTroccaz
Copy link
Contributor Author

Everything is fine! Thanks @CaMer0n and @Deltik

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
plugin: download type: bug A problem that should not be happening
Projects
None yet
Development

No branches or pull requests

4 participants