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, biapar, Willr, Ingo, swaiba, simon_w

Asset files prone to deletion by other users


Reply

4 Posts   492 Views

Avatar
simples

28 September 2012 at 12:29am (Last edited: 2 October 2012 1:41am), Community Member, 76 Posts

Hi,

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

Thanks.

Avatar
simples

30 September 2012 at 11:30pm (Last edited: 1 October 2012 11:37am), Community Member, 76 Posts

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
$ID=$this->getField('ID');
      if(!$member) $member = Member::currentUser();
    if(Permission::checkMember($member, 'ADMIN') || $ID==0){
return true;
}else{
// 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\AssetAdmin_left.ss.

<% 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\AssetAdmin_left.ss which referenced functions in AssetAdmin.php.

Avatar
simples

2 October 2012 at 1:28am (Last edited: 2 October 2012 1:39am), Community Member, 76 Posts

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?

Avatar
simples

4 October 2012 at 9:21am Community Member, 76 Posts

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.