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.

We're retiring the forums!

The SilverStripe forums have passed their heyday. They'll stick around, but will be read only. We'd encourage you to get involved in the community via the following channels instead:

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   887 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.