Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

General Questions /

General questions about getting started with SilverStripe that don't fit in any of the categories above.

Moderators: martimiz, Sean, Ed, biapar, Willr, Ingo, swaiba

Asset files prone to deletion by other users

Go to End

4 Posts   882 Views


Community Member, 77 Posts

28 September 2012 at 12:29am

Edited: 02/10/2012 1:41am


I am building a community web site and I am looking for a way which will allow a user to upload a document to the server in the CMS without the ability to delete files and images uploaded by other users.

Perhaps I am overlooking an available option or a solution which involves little coding.

I have looked at the Secure Files module and this appears to do more than I need. I really do not want to add a module which may have noticeable impact on performance.

I am using Version 2.4.7 because I am limited to using PHP 5.2



Community Member, 77 Posts

30 September 2012 at 11:30pm

Edited: 01/10/2012 11:37am

If I understand correctly, permissions are solely group-based. In the Files and Images section of the CMS, permissions based on a file's owner cannot be set as standard. Unless I have overlooked something, in order to give a user the ability to upload documents, you also have to give that user delete-access to documents uploaded by other users - even users belonging to different groups.

In order to resolve this vulnerability, I have come up with a solution but it is extremely hacky, documents are uploaded to the root assets folder only, and I do not like it. For what it is worth this is what I did. Changes were made in 4 areas as follows. I am using Version 2.4.7 because I am limited to using PHP 5.2.

The following changes were made to sapphire\filesystem\File.php

	function canEdit($member = null) {
		if(!$member) $member = Member::currentUser();

		$result = $this->extendedCan('canEdit', $member);
		if($result !== null) return $result;

		return Permission::checkMember($member, 'CMS_ACCESS_AssetAdmin');

        // Gives edit capability to admin members for all files
		if(!$member) $member = Member::currentUser();
	    if(Permission::checkMember($member, 'ADMIN') || $ID==0){
            return true;
            // Gives edit capability to the owner of the folder/file
            $ownerid=My::returnValue("select ownerid from File where ID=$ID");
            if($member->ID==$ownerid)return true;
        return false;

where My::returnValue is a function which I wrote so I could use standard SQL. (This is probably not recommended)

When browsing admin/assets, the above change allows edit/delete links to appear for records belonging to the file owner only unless the user is an administrator.

The following two lines were added at Line 391 in sapphire\filesystem\Folder.php

	$member = Member::currentUser();
	if(!Permission::checkMember($member, 'ADMIN'))$deleteButton=new HiddenField('deletemarked');

This removes the Delete Selected Files button at the bottom of the right hand frame.

The following two lines were added to the top and bottom of cms\templates\Includes\

<% if isAdministrator %>
<% end_if %>

This removes all content in the left hand frame. This was necessary to remove folder deletion capability.

The following code was added to cms\code\AssetAdmin.php.

	function isAdministrator() {
		return Permission::checkMember($this, 'ADMIN');

The above function had to be created because use of a conditional statement which called the isAdmin function in sapphire\security\Member.php caused issues with variables in cms\templates\Includes\ which referenced functions in AssetAdmin.php.


Community Member, 77 Posts

2 October 2012 at 1:28am

Edited: 02/10/2012 1:39am

Since I was not happy with the hacky solution shown in my last posting, I decided to implement the Secure Files module and take any performance hit which this may introduce.

On doing this, I uncommented the line in _config.php which assigns file security by the individual member, ran /dev/build?flush=1 and browsed the Files & Images page using ?Flush=all.

However it would appear that files uploaded to the root folder are still vulnerable to deletion by other users. Unless I have overlooked something, only files uploaded to subfolders can be set up with restricted access. This is of little consolation because users would have a natural tendency to upload files to the root folder.

Uncommenting all 3 options in _config.php, re-running /dev/build?flush=1 and browsing the Files & Images page with ?Flush=all did not appear to address this particular issue.

Is this a red herring due to something which I have overlooked?


Community Member, 77 Posts

4 October 2012 at 9:21am

OK, I have now reverted back to using my hacky solution.

I hope this issue is due to something which I have overlooked.

If not, this is the only aspect of Silverstripe which I have found to be lacking and disappointing.