When you have a file without content, for example when you cleared you were unable to save it because of an incorrect if-statement. This is the fix for that problem.
fm_get_file_mimes() was causing errors for unknown extensions as it was causing an error as array element was not defined and return value was never checked. According to https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types and several other resources, application/octet-stream is the default value for all other cases. An unknown file type should use this type. I put a check in there to use that by default so a valid value is always returned.
It might be useful to replace this function with the built-in PHP function mime_content_type() but that adds some additional dependencies as it does not always work out of the box with PHP.
Added in the preferences option to change the light or dark theme,
Now to change the theme will be in the preferences / settings area, along with other settings, and may even have other themes in the future.
Added error checking and message for when file fails to write on the server side. Before this change if a write failed on the server side it would still present the user with a misleading "Saved Successfully" Message.
Eliminates the following PHP warnings when error reporting is turned on:
Notice: A non well formed numeric value encountered in tinyfilemanager.php on line 2443
Notice: A non well formed numeric value encountered in tinyfilemanager.php on line 2444
This happens because PHP floor and round are expecting a (float), not an (int).
* Added optional configuration file loading
* First commit of optional configuration file
This file is OPTIONAL.
If this file is not present in your webserver, tinyfilemanager will works with its internal configuration.
* removed define
define is not a configuration
* Fix the RCE vuln via Upload from URL
This commit attemps to fix the Remote Code Execution
(authenticated) via Upload from URL. Some notes about
the proposed solution:
* A new function (fm_is_file_allowed) has been created to
validate if the filename is allowed. This function gets the
the filename as parameter and returns true if it validates
as allowed. Otherwise returns false (the default).
* It's better to have such validatation(s) in one place
instead of spread all over the code. There are other places in
the application where the filename is validated and they should
all be refactored to call this function. Then we can focus
all needed validations in one place only!
NOTE: This refactoring was not done - the only goal was to fix
this security vulnerability only.
* The fm_is_file_allowed() function validates the filename
based on its extension only. No other validatation(s) have been
implemented in this commit.
* File extensions are assumed to be case-insensitive.
For example, php == PHP == Php == PhP, etc. This is consitent
with some web servers. Without this, the user will have to populate
the $allowed_extensions with all possible allowed combinations.
* Although, there is one drawback to the current solution, which
is that all files must have an extension to be uploaded. This is not
consitent with modern filesystems. Maybe a better solution would be
to automatically append an extension to the filename if no
extension has been found (e.g., .html or .txt which are generally
considered to be harmless). This must be decided by the
application's maintainers.
* Fix the RCE vulns via new/rename file
Sanitize the arguments to stat using escapeshellarg()
Co-authored-by: Jorge Morgado <jorge@morgado.ch>
Setting $hide_Cols=true while having FM_IS_WIN=false will lead to a "Type error" when setting up the dataTable. The desired page is generated, but the Search function does not work, as the dataTable is broken.
With this fix the dataTable is written accordingly, with either FM_IS_WIN or $hide_Cols set or unset.
