Since this is a modification to FCKeditor made by FormHandler, I'm filing this bug here.
It is possible to delete files from the File Browser in FCKeditor. However, after deleting a file, it is no longer possible to browse through the various folders or create a new folder.
This is because the delete.php is loaded into the same frame where the "Create a folder" button is located, which also happens to be home to the various javascript functions needed to browse. This frame is not reloaded to the "Create a folder" page.
The fix:
Add the following line to FH3/FHTML/FCKeditor/editor/filemanager/connectors/php/delete.php below the refresh of the frmResourcesList frame (inside the <script>-block):
Also, this file is incredibly sensitive to attacks in its current state, a user can potentially delete any file from your server (assuming file system permissions will allow it).
Unrelated to this is another bug in the version of FCKeditor used, that can break file browser functionality, depending on server configuration.
This happens to be the case on my test-server, which has a document root set to "/var/www", with some settings to automatically create subdomains for all subdirectories, so that fh.test.server will grab its files from "/var/www/fh". Using a feature of Apache to allow a PHP script to be run before anything else, the $_SERVER['DOCUMENT_ROOT'] variable is overwritten before the website is processed.
This makes sure all paths are correct for PHP, however, Apache still believes /var/www to be the document root.
To determine the server path for the file browser, FCKeditor uses a built-in Apache function to determine what the actual path is, so instead of browsing to /var/www/fh/images/uploads, it tries to browse to /var/www/images/uploads.
The fix:
In FH3/FHTML/FCKeditor/editor/filemanager/connectors/php/io.php, find these lines:
<?php
// Emulate the asp Server.mapPath function.
// given an url path return the physical directory that it corresponds to
function Server_MapPath( $path )
{
// This function is available only for Apache
if ( function_exists( 'apache_lookup_uri' ) )
{
$info = apache_lookup_uri( $path ) ;
return $info->filename . $info->path_info ;
}
// This isn't correct but for the moment there's no other solution
// If this script is under a virtual directory or symlink it will detect the problem and stop
return GetRootPath() . $path ;
}
?>
I have not submitted this bug to FCKeditor, because it takes some very specifically tweaked Apache-settings to recreate, and besides, FormHandler uses FCKeditor 2.5.1, whereas the current version is 2.6.2.
We are working on a newer version of FH which uses the latest FCKEditor.
We will include your fixes in the next version and in a bug fix we will put online tomorrow
Regarding the delete option, in the browser, we normaly use a login verification for this.
I will remove the delete option and think about a solution or this.
Any suggetions?
I always use FormHandler for CMS-like implementations, so there's always a password verification in there. However, the delete.php does not check whether the user is logged in. Nor should it, because there's no way for that file to know how a developer chooses to remember whether or not a user is logged in.
I think a minimum amount of verification that could be in there is to check the given path for "../" at any level, and only allowing it to delete files in the ServerPath and subdirectories. If I'm not allowed to browse somewhere, I surely shouldn't be allowed to delete files from there.
Maybe also a check on the file type being displayed? If only images are being displayed in the file browser, I should only be allowed to delete images. But maybe this will require delving too deep into the FCKeditor source code to find out when to allow it.
we discussed it add PHP-GLOBE HQ and decided to put an alert and a die in the delete.php and leave it to the developer to activate and secure the delete funtion.
That way we don't bring out dangerous software and every developer can use the function his own way.
