Closed aducom closed 3 years ago
Please check your Apache error log for more details (your hosting provider can help you with this). The error log provides more information.
I suspect it's a server configuration security measure.
I'll try to get it. Downloading worked fine in the original version so I'm curious ;-) I will install the backup on another location to verify as well. But I doubt that this is a security issue, as I can download directly from the link, only not using the PHP download from E107.
Hi, there are 2 problems.
manual uploading is not allowed although filetypes.xml is changed
he uses external download so not uploading is not important now.
The problem is here:
Fatal error: Uncaught Error: Call to undefined function decorate_download_location() in C:\xampp8\htdocs\e107-gaia231\e107_plugins\download\request.php:224 Stack trace: #0 C:\xampp8\htdocs\e107-gaia231\e107_plugins\download\request.php(457): download_request::request() #1 C:\xampp8\htdocs\e107-gaia231\index.php(69): include_once('C:\\xampp8\\htdoc...') #2 {main} thrown in C:\xampp8\htdocs\e107-gaia231\e107_plugins\download\request.php on line 224
That file was changed from normal PHP to class and moved to plugin, but there is
e107::redirect(decorate_download_location($download_url));
but adding $this-> didn't help
The only fix was moving that function outside the download_request class.
This will be only a bug using php 8 (tested on local ) : (in addition to problem issue Jimmy08 mentioned, not at that point arrived)
Fatal error: Uncaught TypeError: count(): Argument #1 ($var) must be of type Countable|array, null given in R:\Xampp-803\htdocs\newest\e107_plugins\download\includes\admin.php:1821 Stack trace: #0 R:\Xampp-803\htdocs\newest\e107_plugins\download\includes\admin.php(418): download_main_admin_ui->submit_download() #1 R:\Xampp-803\htdocs\newest\e107_plugins\download\includes\admin.php(450): download_main_admin_ui->observe() #2 R:\Xampp-803\htdocs\newest\e107_handlers\admin_ui.php(1474): download_main_admin_ui->init() #3 R:\Xampp-803\htdocs\newest\e107_handlers\admin_ui.php(1447): e_admin_dispatcher->_initController() #4 R:\Xampp-803\htdocs\newest\e107_handlers\admin_ui.php(1333): e_admin_dispatcher->getController() #5 R:\Xampp-803\htdocs\newest\e107_handlers\admin_ui.php(1105): e_admin_dispatcher->runObservers() #6 R:\Xampp-803\htdocs\newest\e107_plugins\download\admin_download.php(244): e_admin_dispatcher->__construct() #7 {main} thrown in R:\Xampp-803\htdocs\newest\e107_plugins\download\includes\admin.php on line 1821
SInce MSI files contain some data code on front (which might be checked by/through server etc.. use FTP uload to import folder (filetypes adjusted and keep an eye out on 'naming' (space - and _ etc..).. This happens on a live php 7.4.10 site: (upload through ftp (binary !!!), MM accept, as dl file. DL created.)
edit : need to mention : not all hosters/servers accept the handling of executable files...(than store and provide in compressed form (zip/rar).
Actually I am uploading the MSI by using FileZilla and was using the external file. Jimako fixed the issue for me (I have bought the theme from him, great support), but I am running PHP 7.4 on the production server. But because of the issue I tried to upload the file using the regular way which failed. I did try to look into the htaccess, accepted filetypes, but I could not add the .msi to the accepted list of uploads, and I could not find where to do that. The MSI is also digitally signed, to avoid issues with browsers like Chrome and Edge and has been reported to several anti-virus manufacturers (fwiw). Browsers can behave strange sometimes ;-)
I don't know where you message is coming from, if you go to downloads and try to upload a file there, then you can only select files that are part of the supported list.
Alright, so it looks like it is a bug. Can you please check the Apache error log still? I am curious to see what it says. Or is that error that @Jimmi08 posted from the error log?
I suppose so, but I did ask the provider to give access to the logfiles. As it is Easter, I'm afraid that it might be problematic, because I cannot reproduce as Jimako fixed it. But we'll see.
@Moc there are 2 issues... his original problem was due to that fatal error but you don't see it on the live server, so I tested it with his download table on localhost. That workaround helped. But then he accidentally found the next problem - not able to upload msi file standard way.
Just adding imo : as i understand, the mimetype is in file class ; but is not in allowed types (eg for upload). Being an executable file it seems correct to me (sec. reason> local file upload vulnerability).
mmm, yes and no. I have a msi on my website for download to allow customers to download and install. The download is verified by Microsoft and Google, is digitally signed, and has all the marks for being a legit application.
Now download as an external file failed so I tried to do it the formal way and upload the file in a regular way. It failed.
Then there are some considerations. But first: my issue is solved in the old way so I don't have a problem currently.
Point is, that I could not find a way of configuring the system so that it worked as expected. For advanced hackers, it is not that difficult to hide their stuff in 'legal' files. Perhaps off-topic, but still.
I understand, and partial agree; can (would like to ) say more, but it is posted as issue, adding more leads to discussion and distracts. ( i (pers.) leave it at that).
@aducom Normally this last commit should fix the download part of the issue. Uploading issue still requires a fix.
@aducom Would you mind retesting?
I will.Op 14 apr. 2021 22:41 schreef Cameron @.***>: @aducom Would you mind retesting?
—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.
@caMer0n, which files do I need to replace? I don't want to do a full install due to some other mods. I have a bit of time now to look into it. I assume Issue #4478 - Fixes decorate_download_location() and check_download_l… Will start here.
@aducom you need to replace e107_plugin/download/request.php
I did. But actually I'm not sure what the modification did. The original issue was that I could not download an msi as an external file. That was fixed by Jane. The other issue is that I could not upload the msi as an accepted file and I could not add it to the list of accepted files. That is also in the download where you can upload an existing file from your local machine. Well, downloading the msi as an external file works fine with this file, so nothing changed there. But I still can't upload an msi.
Right, so you do actually need to update other files as well. You need these changes:
And then make sure filestypes.xml contains the msi
extension (it is located in your e107_system(/hash) folder)
Closing as presumed fixed. Please let us know if the issue still persists.
Bug Description
I have upgraded my website to the latest github. On my website users can download an msi file that is declared as an external file in the download manager. If you try to download then you get a 500 error message.
I thought it had to do with accepted filetypes and tried to assign it as a local file by trying to upload the msi. You can't. I couldn't find a place where I could define that except for uploads.
I can download pdf's so I think it has to do with the file type.
How to Reproduce
Steps to reproduce the behavior: Just create a download of an msi and try to download
Expected Behavior
that i can download the file
Screenshots
just 500 (internal server error)
Server Information
e107 Version 2.3.1 (git)
Security level [5] Balanced
Site Theme hestia
Admin Theme Bootstrap 3 v1.0 by e107 Inc (2013-12-25)
Install date Wednesday 11 December 2019 - 08:32
Server Apache/2 (host: www.phspeed.com)
PHP Version 7.4.14
MySQL 5.5.31 Database: aduc0madm_phspx PDO: Enabled Mode: NO_ENGINE_SUBSTITUTION
Charset utf-8
Server Time Sunday 04 April 2021 - 17:55