Core: Feature request: Write-only anonymous upload

[Gummikavalier]

Anonymous upload with write-only permissions would be handy for gathering data from multiple external people. This would make it unnecessary to create separate accounts for that purpose.

It would also be safer than the password under the file sharing options, in case the password feature still loads a MD5 hashed password to the user's browser cache. (This was found in audit in our company early 2013. Unfortunately I never got the details so don't ask.)

[blizzz]

This feature exists already. Create a folder, share by link, check the appearing "allow public upload" check box.

[Gummikavalier]

The request is for a write-only upload feature.

The current implementation of public upload still allows anyone downloading any files in the upload directory.

[ghost]

@Gummikavalier

Could be possible that you're looking for the "File Firewall" feature included in the Enterprise Edition of ownCloud:

https://owncloud.com/products/enterprise

[blizzz]

OK, thanks for clarification.

[Gummikavalier]

@RealRancor
I'm not sure if Enterprise version makes this feature possible.

I checked
http://doc.owncloud.com/server/6.0EE/enterprise_manual/firewall/index.html
but it does not mention whether it is possible to make upload rule (write-only option) for anonymous users, even if it seems quite powerful feature.

I would still aim for simplicity for both Community and Enterprise users. A check box under the current 'Allow public upload'-feature that would say 'Allow only uploads' would be nice. :)

[PVince81]

The problem with this is that it also comes with UI implications.
Does the user who uploaded the file see the file in a list ? (as feedback)
Can the user upload more than one file ?

This was already requested before but I can't find the issue any more.

[Gummikavalier]

Thanks for the info PVince81. :)

My 2 cents would be:

Just a plain popup informing the user of a successful transfer would be more secure solution than exposing the filenames. Although names wouldn't be too bad a security breach if the uploaders are informed to use nondescriptive filenames.

Also users should be able to upload as many files as they want; they can do so currently with upload+download shares so this would not require changes. There really is no telling who is accessing public urls anyway, and doing limiting by IP would cause severe problems for all users behind proxies or in NATted networks.

[mateuszkozera]

my organization would really love this feature.

[tflidd]

Could this be done in an app? Just give an upload link, it leads to an interface where you can upload files (you only see your files). As little extra: put your e-mail address, and the system confirms the upload with a sha1-hash of each file.

[pintman]

It would be great to have such a feature. A feedback of the uploaded files would be a good decision. The upload of multiple files should be possible.

[ghost]

Hi,

it seems that something like this will be part of the OC 8.0.3 Enterprise Edition in form of the "File Drop" app: https://github.com/owncloud/documentation/pull/1062

[jospoortvliet]

@RealRancor still this feature request is valid and if somebody wants to implement it they can go ahead. Until then, yes, for enterprises the EE is helpful.

[ghost]

@jospoortvliet
Sure, this was just a hint to look for this feature in the EE.

[Xenopathic]

The Enterprise Files Drop app implements this, so for now it won't be coming to the community edition, sorry :disappointed:

[jospoortvliet]

@Xenopathic as we discussed earlier in this report - there is no reason why somebody couldn't write this feature and it would get in, too. The fact that something is in the Enterprise Edition is no reason to close feature requests.

[Xenopathic]

@jospoortvliet Ah, sorry. But in that case, it should be added to the 'app request' list, no? This is certainly not something that core should implement :smile:

[jospoortvliet]

@Xenopathic true

[pmaier1]

The Files Drop Enterprise App will become part of the Community Edition soon. Closing therefore.

[PVince81]

@pmaier1 we still need to discuss how to better integrate it, possibly in the share dialog.
Unless we just want to take the app as is ?

[pmaier1]

@PVince81 true. I would suggest to integrate it in the sharing dialog as suggested here https://github.com/owncloud/core/issues/22327#issuecomment-203340659. Would make sense to only show the checkbox when sharing a folder and to hide it when sharing a file.

[PVince81]

I suggest reopening this ticket here because https://github.com/owncloud/core/issues/22327 is a much bigger discussion with more changes.

Also files_drop usually displayed an overview of the selected drop folders in the personal page. Question is whether we want to keep this additionally to having the info available in the share dialog.

[pmaier1]

I would vote for moving this to the left sidebar and have a new entry "File Drop" or "Write-only shares". It's always nice to have an overview and it would be consistent with other "sharing filters" there.

[PVince81]

Had a quick test out of curiosity to see what happens if one removes the "READ" permission in the share.

1. Create a link share and write down the token
2. update oc_share set permissions=4 where token='thetoken';. Replace "thetoken" with the share token. This will set "create-only" permissions.
3. Open the link in the web UI

Apparently the missing read permission isn't checked by the Webdav code (public.php/webdav), so the folder contents can still be listed.

[PVince81]

Question is also whether directory creation is allowed... at least on Webdav level. Because technically the CREATE permission allows both upload (PUT) and directory creation (MKCOL)

[hodyroff]

Creation: Yes, thats fine, write allowance means additional files, but also the creation of additional directories, as long as they inherit the rights from above = no read/listing

[PVince81]

There should probably also be some obfuscation happening.

For example if someone uploads a file "bacon.txt".
Then someone else tried "DELETE bacon.txt", that will give 403 Forbidden because there are no delete permissions.
However if you do "DELETE unexist.txt" it gives 404.

Ideally all operations should always return 404 not found to simulate non-existence of files and only PUT works.

Note that PUT + overwrite also returns 403 because there are no UPDATE permissions.

[PVince81]

• [x] fix Webdav backend to support removing READ property https://github.com/owncloud/core/pull/27245
• [x] make it difficult to detect existing files by returning 404 for various operations ?
  
  
  
  • PUT + overwrite
  
  
  • DELETE
  
  
  • MOVE
  
  
  • PROPFIND on file directly
  
  
  • PROPPATCH on file
  
  
• [x] adjust share dialog to have a new checkbox to set "CREATE" permissions alone wiht no "READ" permission: https://github.com/owncloud/core/pull/27548
• [x] adjust public web UI page for when the READ permission is missing
  
  
  
  • [x] don't display "Download" button not "Add to your ownCloud"
  
  
  • [x] remove file listing
  
  
  • [x] add simple upload field (needs to use Webdav PUT from file-upload.js)
  
  

[pmaier1]

Nice to see some progress here. Should be interesting for @felixheidecke as well.
Regarding UI I think we decided on having a checkbox 'Hide file listing' in the permissions part of the sharing dialog. This of course may only be tickable for folders, not for files.

[PVince81]

WIP PR for the checkbox and everything else: https://github.com/owncloud/core/pull/27548

[PVince81]

Side note: will not work with web UI chunk upload until this is sorted out: https://github.com/owncloud/core/pull/26306#issuecomment-290762884

[PVince81]

• [ ] what to do when someone uploads a folder (with subfolders) with drag and drop (Chromium only): I suggest blocking this as the upload should not allow folder creation

[PVince81]

Ok, here we go, a working very crude POC: https://github.com/owncloud/core/pull/27548

Drag and drop onto the button also works (drop zone a bit small currently).

It doesn't solve conflicts so uploading the same file twice will fail silently for now.
It looks ugly, needs styling.

[pmaier1]

what to do when someone uploads a folder (with subfolders) with drag and drop (Chromium only): I suggest blocking this as the upload should not allow folder creation

Basically yes, but what speaks against subfolder creation actually?

It doesn't solve conflicts so uploading the same file twice will fail silently for now.
It looks ugly, needs styling.

I guess we spoke about this in person and concluded to add a '(2)' or something to files with identical names. Would be the next step then.

[PVince81]

Basically yes, but what speaks against subfolder creation actually?

More conflict resolution logic because folders could overlap...
But also it might be more confusing for the receiver who might not know about the ability to upload folders in the browser (only Chromium supports this).

I guess we spoke about this in person and concluded to add a '(2)' or something to files with identical names. Would be the next step then.

Ok, so now the challenge is "do we break Webdav compliance for that specific endpoint or invent a separate mechanism for uploading files that allows for server-side deduplication" (Webdav doesn't have server-side deduplication as per spec).

[pmaier1]

More conflict resolution logic because folders could overlap...
But also it might be more confusing for the receiver who might not know about the ability to upload folders in the browser (only Chromium supports this).

Ok fine, so files only.

Ok, so now the challenge is "do we break Webdav compliance for that specific endpoint or invent a separate mechanism for uploading files that allows for server-side deduplication" (Webdav doesn't have server-side deduplication as per spec).

I guess we don't want to break WebDAV compliance. Actually we have
a) Name-based deduplication -> rename would be nice (easier approach would be to throw an error to rename the file but that would then reveal contents of course)
b) Content-based deduplication -> handling via checksum would be nice (withdraw files with matching checksums in the respective folder)

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.