SFTPGO: Allow collaboration on documents/ability to edit shared files

[mohamedamer453]

Description

In SFTPGO there are options to share a document and add read/write permissions, however these options only affect download/upload for the directory and it doesn't allow editing.

a use case for this is collaborating on a document using OnlyOffice, from the UI there's a collaboration tab and settings

However i couldn't find a way to share this document so multiple users can view/edit it at the same time.

[alichaddad]

SFTPGO doesn't support sharing files for editing. What is explained above are the only use cases that SFTPGO supports natively. Implementing sharing for writing file would require extensive changes to the code base, with changes to the authentication flow since there is no sharing between users and additional sharing metadata to be stored.

There is a way to achieve live editing by creating a virtual folder. This operation is exclusive to the admin and it allows creating a folder and then assigning it to multiple users, in a way achieving sharing and making live editing of an Only office file possible.

[AbdelrahmanElawady]

After looking around the system and considering @alichaddad comments there is an approach with features mostly implemented in SFTPGO.

The current behavior allows for live editing as mentioned using Virtual Folders. However, only the Admin can create these folders and manage adding them to different users. The current sharing options does not offer anymore than just downloading the files.

We can extend Virtual Folders with ACLs to ensure a seamless process for sharing files or directories to different users as follows:

• A user (user1 for example) creates a directory dir1 with some content in it.
• user1 decides to share dir1 with user2 and user3.
• A new endpoint for users wanting to share files or directories will receive the request and does the following:
  • Create a new Virtual Folder (vdir1 for example) and mount it to user1 storage.
  • Move the content to be shared to vdir1
  • Add metadata either next to files/dirs in the vdir1 or stored in database. This metadata contains information on where the original data was stored.
  • Mount vdir1 to user2 and user3.
  • Configure ACL for user2 and user3 to only allow file manipulation and prevent them from any extra permissions (changing owner, removing files ..etc)

The issue that remains is how exactly to design an endpoint that take request from unprivileged user to perform privileged operations. There are few options:

• During SFTPGO startup an admin account is created for only the server to use and the endpoint perform all operations with this admin account.
• Use already defined admin credentials that the server administrator is using.
• Expose an unprotected endpoints for managing Virtual Folders and ACLs that only accept requests from localhost (to avoid security concerns).

Using the suitable approach for the new endpoint will offer a way to share any content using Virtual Folders and ACLs.

There are still some cases that may or may not be needed but still worth discussing, for each case here an endpoint with the proper validation that the user requesting is the owner will be created too:

• Adding/Removing a user from the shared directory users:
  • The owner of the files can't be removed.
  • New user added will have the shared directory mounted and ACL configured.
  • User removed will remove the directory with the ACL on it.
• Changing ownership of a shared directory:
  • Remove all permissions of the owner on the directory.
  • Add these permissions to the new owner.
  • The new owner will be prompted for a new metadata as to where the files should go to in case of no longer sharing (more on that next case).
• Stopping directory sharing:
  • Every user with access to the Virtual Folder will have their access revoked and all ACL removed.
  • Using the metadata with shared directory the content of the Virtual Folder will be moved again to it's original path.
  • Extra care will be required here as there are conflicts that might arise, for example:
    • The parent directory of the original shared directory might be removed.
    • Some files in the original path might have the same name and could cause some collision.
  • We could take the user input on what to do in these cases or choose a suitable solution and document the behavior.
• Adding guest support:
  • All approaches of adding guest support right now involve creating some arbitrary user that access the shared directory. However they add some security concerns as they have access to creating directory and files and there is no way to track that (they are guests). It may be possible if creating a user stripped down of all permissions is available but right now there is not.

Pros of using this approach:

• Virtual Folders and ACLs are already implemented and working.
• Works with all storage backends that support Virtual Folders.
• No multiple versions of the same files exist.

Cons of using this approach:

• Implementing new endpoints to handle this flow.
• If not handled properly collisions with some files on users system will be problematic.

[despiegk]

ps

• is ok that user who has edit access has full access

[muhamadazmy]

However i couldn't find a way to share this document so multiple users can view/edit it at the same time

is this even possible over sftp protocol? sftp as far as i know (and correct me if i am wrong) can upload/download full objects so multiple users won't be able to edit the same file at the same time or they will be stepping on each others toes!

Unless this is supported by sftpgo it won't work out of the box.

[rawdaGastan]

We drafted a pr that includes:

1- Support for live collaboration on files 2- A link is added to edit the shared files 3- If a shared directory has some files that could be edited , edit icons is displayed for them

• An example for live collaboration on a shared file

Screencast from 24 أغس, 2023 EEST 04:45:30 م.webm

• This is how a shared directory looks like:

• still needs some CI fixes

[despiegk]

wow, cant wait to try