Custom permission problem for moving/deleting

[jneeve]

We want to setup Collaborators so that they can add/revise documents AND move them between spaces.

From what I can tell, a move requires delteNode access so I added that to the Collaborator group in permissionDefinitions.xml

I've modified the permissions and now collaborators can move, but they can also DELETE documents in Webdav. But NOT in the Aflresco GUI.

      <permissionGroup name="Collaborator" allowFullControl="false" expose="true">
        <includePermissionGroup permissionGroup="Editor" type="cm:cmobject" />
        <includePermissionGroup permissionGroup="Contributor" type="cm:cmobject" />
         <includePermissionGroup permissionGroup="DeleteNode" type="sys:base" /><!– Added to allow collaborators to move documents  –>
      </permissionGroup>
‍‍‍‍‍‍‍

Everything is done over webscripts using Javascript so the user doesn't use the Alfresco Gui. When a document is added it's ownership is given to 'Admin' so collaborators can't delete documents. (Hence having to try and give them enough rights to move the document)

With this new permission, everything seems to work. They can add/revise documents and in Javascript I can perform a .move() command on a document fine.

When we return XML back to our custom GUI, we use Freemarker to determine if they can delete the document and it says the user can't.

<delete><#if document.hasPermission("Delete")>true<#else>false</#if></delete>‍

The alfresco GUI also doesnt allow the user to delete the document.  But, when I tried mapping a webdav drive to doublecheck, I was able to delete the document fine. Seems like a big security hole…..

Suggestions!?

[rivetlogic]

Hi,

This is what "Delete" is as per permissionDefinitions.xml. Instead of adding DeleteNode to your permission group try adding  "Delete".

<permissionGroup name="Delete" expose="true" allowFullControl="false">
           <includePermissionGroup type="sys:base" permissionGroup="DeleteNode"/>
           <includePermissionGroup type="sys:base" permissionGroup="DeleteChildren"/>
      </permissionGroup>
‍‍‍‍‍‍

I hope this helps.

Best Regards,
Shagul

[ranjitsinh_reva]

Hi RivetLogic,

Thanks for this solution. It's works for me.
Great.

[jneeve]

Wouldnt that give them more permissions?

I only want them to be able to move the document - not delete it. (Ie: they misfile it in the wrong folder and they need to move it)

Adding 'DeleteNode' seems to allow the file to be moved through a javascript .move() and through the Alfresco GUI the delete option is NOT available (Thats good!)

But I can delete it through the webdav mapping..which is why I'm confused. (Since that makes a giant security problem)

[rivetlogic]

Hi,

"DeleteNode" is not the same as "Delete".

<delete><#if document.hasPermission("Delete")>true<#else>false</#if></delete>
‍‍‍

Did you try "DeleteNode" in the above ftl?  If you have a DeleteNode permission you should be able to delete a node unless you are checking for "Delete" which the users don't have.

Since you are setting the owner of all documents to be "Admin" irrespective of who created it , then you may have to consider performing the necessary permission check and execute the move as system user or admin user in your backing code.

Best Regards,
Shagul

[jneeve]

Hmm, yes I changed the FTL to DeleteNode and sure enough that comes back as true… for some reason I didnt clue in that it was checking the exact permission name (not just some option if the user can delete or not) Ugh!

I'll have to rethink this - as a test I had tried granting the ownerShip persmission which allows the user to take back ownership from admin, perform the move, and then give ownership away again. That seems OK, but yet another security hole since now users 'could' take ownership of any document if they were to use the Alfresco GUI.

Do you have an example of how to perform just part of the webscript as a different user? I'm not sure exactly how to do that since webscripts normally run as the logged in user….

This is the task that seems to be causing us all the grief.. (its inside a larger script thats basically handling adds and revisions of documents)

 reviseDoc.move(destinationFolder); ‍

We have previously written a java app that wakes up and checks a space for document changes (adds/revisions,etc) and runs as the admin user to perform tasks for users who have limited access.. (So users can't write directly to the destination spaces)  However, we're trying to get away from that since it hasn't been withought its own problems.

[rivetlogic]

I don't have a sample code available. But you should be able to back any webscript with  a java bean. Alfresco Wiki has information on this.
In your bean you should be able to authenticate as admin user while holding on to the current ticket and revert back to the current user authentication.

String currentUserTicket=authenticationService.getCurrentTicket();
authenticationService.authenticate(adminusername,adminpassword) ;
//perform your operation
authenticationService.validate(currentUserTicket);
‍‍‍‍‍‍

This is not an ideal solution as this results in storing the adminusername,password somewhere.

Alfresco has an issue open for runAs tag in webscript.


https://issues.alfresco.com/jira/browse/ENH-229


Regards,
Shagul

[jneeve]

Just as a followup …..

This does work fine, just be carefull of the security implications of adding a feature that can basically move a file anywhere….We added a bit of code to check where the file is being moved so that someone couldnt move it to say a system folder or something.

You don't need to worry about the users ticket. We just authenticate as an administrator in our custom move class, move the file and then continue processing as normal..  The credentials are injected through spring so we don't have hard code them in the java code at least…