sevenhill/QSfera
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

copy feature files from core

Browse Source
This commit is contained in:
Saw-jan
2023-01-05 09:22:52 +05:45
committed by Phil Davis
parent 35d4cb53ae
commit c59392bc1e
336 changed files with 52903 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
tests/acceptance/features/coreApiWebdavUpload1/uploadFile.feature
+334
View File
@@ -0,0 +1,334 @@
@api
Feature: upload file
As a user
I want to be able to upload files
So that I can store and share files between multiple client systems
Background:
Given using OCS API version "1"
And user "Alice" has been created with default attributes and without skeleton files
@smokeTest
Scenario Outline: upload a file and check download content
Given using <dav_version> DAV path
When user "Alice" uploads file with content "uploaded content" to "<file_name>" using the WebDAV API
Then the HTTP status code should be "201"
And the following headers should match these regular expressions for user "Alice"
| ETag | /^"[a-f0-9:\.]{1,32}"$/ |
And the content of file "<file_name>" for user "Alice" should be "uploaded content"
Examples:
| dav_version | file_name |
| old | /upload.txt |
| old | /नेपाली.txt |
| old | /strängé file.txt |
| old | /s,a,m,p,l,e.txt |
| new | /upload.txt |
| new | /नेपाली.txt |
| new | /strängé file.txt |
| new | /s,a,m,p,l,e.txt |
@skipOnOcV10 @personalSpace
Examples:
| dav_version | file_name |
| spaces | /upload.txt |
| spaces | /नेपाली.txt |
| spaces | /strängé file.txt |
| spaces | /s,a,m,p,l,e.txt |
Scenario Outline: upload a file and check download content
Given using <dav_version> DAV path
When user "Alice" uploads file with content "uploaded content" to <file_name> using the WebDAV API
Then the HTTP status code should be "201"
And the content of file <file_name> for user "Alice" should be "uploaded content"
Examples:
| dav_version | file_name |
| old | "C++ file.cpp" |
| old | "file #2.txt" |
| new | "C++ file.cpp" |
| new | "file #2.txt" |
@skipOnOcV10 @personalSpace
Examples:
| dav_version | file_name |
| spaces | "C++ file.cpp" |
| spaces | "file #2.txt" |
@issue-ocis-reva-265
#after fixing all issues delete this Scenario and merge with the one above
Scenario Outline: upload a file and check download content
Given using <dav_version> DAV path
When user "Alice" uploads file with content "uploaded content" to <file_name> using the WebDAV API
Then the HTTP status code should be "201"
And the content of file <file_name> for user "Alice" should be "uploaded content"
Examples:
| dav_version | file_name |
| old | "file ?2.txt" |
| old | " ?fi=le&%#2 . txt" |
| old | " # %ab ab?=ed " |
| new | "file ?2.txt" |
| new | " ?fi=le&%#2 . txt" |
| new | " # %ab ab?=ed " |
@skipOnOcV10 @personalSpace
Examples:
| dav_version | file_name |
| spaces | "file ?2.txt" |
| spaces | " ?fi=le&%#2 . txt" |
| spaces | " # %ab ab?=ed " |
Scenario Outline: upload a file with comma in the filename and check download content
Given using <dav_version> DAV path
When user "Alice" uploads file with content "file with comma" to <file_name> using the WebDAV API
Then the HTTP status code should be "201"
And the content of file <file_name> for user "Alice" should be "file with comma"
Examples:
| dav_version | file_name |
| old | "sample,1.txt" |
| old | ",,,.txt" |
| old | ",,,.," |
| new | "sample,1.txt" |
| new | ",,,.txt" |
| new | ",,,.," |
@skipOnOcV10 @personalSpace
Examples:
| dav_version | file_name |
| spaces | "sample,1.txt" |
| spaces | ",,,.txt" |
| spaces | ",,,.," |
Scenario Outline: upload a file into a folder and check download content
Given using <dav_version> DAV path
And user "Alice" has created folder "<folder_name>"
When user "Alice" uploads file with content "uploaded content" to "<folder_name>/<file_name>" using the WebDAV API
Then the HTTP status code should be "201"
And the content of file "<folder_name>/<file_name>" for user "Alice" should be "uploaded content"
Examples:
| dav_version | folder_name | file_name |
| old | /upload | abc.txt |
| old | /strängé folder | strängé file.txt |
| old | /C++ folder | C++ file.cpp |
| old | /नेपाली | नेपाली |
| old | /folder #2.txt | file #2.txt |
| new | /upload | abc.txt |
| new | /strängé folder (duplicate #2 &) | strängé file (duplicate #2 &) |
| new | /C++ folder | C++ file.cpp |
| new | /नेपाली | नेपाली |
| new | /folder #2.txt | file #2.txt |
@skipOnOcV10 @personalSpace
Examples:
| dav_version | folder_name | file_name |
| spaces | /strängé folder | strängé file.txt |
| spaces | /upload | abc.txt |
| spaces | /C++ folder | C++ file.cpp |
| spaces | /नेपाली | नेपाली |
| spaces | /folder #2.txt | file #2.txt |
@issue-ocis-reva-265
#after fixing all issues delete this Scenario and merge with the one above
Scenario Outline: upload a file into a folder and check download content
Given using <dav_version> DAV path
And user "Alice" has created folder "<folder_name>"
When user "Alice" uploads file with content "uploaded content" to "<folder_name>/<file_name>" using the WebDAV API
Then the HTTP status code should be "201"
And the content of file "<folder_name>/<file_name>" for user "Alice" should be "uploaded content"
Examples:
| dav_version | folder_name | file_name |
| old | /folder ?2.txt | file ?2.txt |
| old | /?fi=le&%#2 . txt | # %ab ab?=ed |
| new | /folder ?2.txt | file ?2.txt |
| new | /?fi=le&%#2 . txt | # %ab ab?=ed |
@skipOnOcV10 @personalSpace
Examples:
| dav_version | folder_name | file_name |
| spaces | /folder ?2.txt | file ?2.txt |
| spaces | /?fi=le&%#2 . txt | # %ab ab?=ed |
Scenario Outline: attempt to upload a file into a nonexistent folder
Given using <dav_version> DAV path
When user "Alice" uploads file with content "uploaded content" to "nonexistent-folder/new-file.txt" using the WebDAV API
Then the HTTP status code should be "409"
And as "Alice" folder "nonexistent-folder" should not exist
And as "Alice" file "nonexistent-folder/new-file.txt" should not exist
Examples:
| dav_version |
| old |
| new |
@skipOnOcV10 @personalSpace
Examples:
| dav_version |
| spaces |
@issue-ocis-reva-15
Scenario Outline: Uploading file to path with extension .part should not be possible
Given using <dav_version> DAV path
When user "Alice" uploads file "filesForUpload/textfile.txt" to "/textfile.part" using the WebDAV API
Then the HTTP status code should be "400"
And the DAV exception should be "OCA\DAV\Connector\Sabre\Exception\InvalidPath"
And the DAV message should be "Can`t upload files with extension .part because these extensions are reserved for internal use."
And the DAV reason should be "Can`t upload files with extension .part because these extensions are reserved for internal use."
And user "Alice" should not see the following elements
| /textfile.part |
Examples:
| dav_version |
| old |
| new |
@skipOnOcV10 @personalSpace
Examples:
| dav_version |
| spaces |
Scenario Outline: upload a file into a folder with dots in the path and check download content
Given using <dav_version> DAV path
And user "Alice" has created folder "<folder_name>"
When user "Alice" uploads file with content "uploaded content for file name ending with a dot" to "<folder_name>/<file_name>" using the WebDAV API
Then the HTTP status code should be "201"
And as "Alice" file "/<folder_name>/<file_name>" should exist
And the content of file "<folder_name>/<file_name>" for user "Alice" should be "uploaded content for file name ending with a dot"
Examples:
| dav_version | folder_name | file_name |
| old | /upload. | abc. |
| old | /upload. | abc . |
| old | /upload.1 | abc.txt |
| old | /upload...1.. | abc...txt.. |
| old | /... | ... |
| new | /..upload | ..abc |
| new | /upload. | abc. |
| new | /upload. | abc . |
| new | /upload.1 | abc.txt |
| new | /upload...1.. | abc...txt.. |
| new | /... | ... |
@skipOnOcV10 @personalSpace
Examples:
| dav_version | folder_name | file_name |
| spaces | /upload. | abc. |
| spaces | /upload. | abc . |
| spaces | /upload.1 | abc.txt |
| spaces | /upload...1.. | abc...txt.. |
| spaces | /... | ... |
@issue-ocis-reva-174
Scenario Outline: upload file with mtime
Given using <dav_version> DAV path
When user "Alice" uploads file "filesForUpload/textfile.txt" to "file.txt" with mtime "Thu, 08 Aug 2019 04:18:13 GMT" using the WebDAV API
Then the HTTP status code should be "201"
And as "Alice" file "file.txt" should exist
And as "Alice" the mtime of the file "file.txt" should be "Thu, 08 Aug 2019 04:18:13 GMT"
Examples:
| dav_version |
| old |
| new |
@skipOnOcV10 @personalSpace
Examples:
| dav_version |
| spaces |
@issue-ocis-reva-174
Scenario Outline: upload a file with mtime in a folder
Given using <dav_version> DAV path
And user "Alice" has created folder "testFolder"
When user "Alice" uploads file "filesForUpload/textfile.txt" to "/testFolder/file.txt" with mtime "Thu, 08 Aug 2019 04:18:13 GMT" using the WebDAV API
Then the HTTP status code should be "201"
And as "Alice" file "/testFolder/file.txt" should exist
And as "Alice" the mtime of the file "/testFolder/file.txt" should be "Thu, 08 Aug 2019 04:18:13 GMT"
Examples:
| dav_version |
| old |
| new |
@skipOnOcV10 @personalSpace
Examples:
| dav_version |
| spaces |
@issue-ocis-reva-174
Scenario Outline: moving a file does not change its mtime
Given using <dav_version> DAV path
And user "Alice" has created folder "testFolder"
When user "Alice" uploads file "filesForUpload/textfile.txt" to "file.txt" with mtime "Thu, 08 Aug 2019 04:18:13 GMT" using the WebDAV API
And user "Alice" moves file "file.txt" to "/testFolder/file.txt" using the WebDAV API
Then the HTTP status code should be "201"
And as "Alice" file "/testFolder/file.txt" should exist
And as "Alice" the mtime of the file "/testFolder/file.txt" should be "Thu, 08 Aug 2019 04:18:13 GMT"
Examples:
| dav_version |
| old |
| new |
@skipOnOcV10 @personalSpace
Examples:
| dav_version |
| spaces |
@issue-ocis-reva-174
Scenario Outline: overwriting a file changes its mtime
Given using <dav_version> DAV path
And user "Alice" has uploaded file with content "first time upload content" to "file.txt"
When user "Alice" uploads a file with content "Overwrite file" and mtime "Thu, 08 Aug 2019 04:18:13 GMT" to "file.txt" using the WebDAV API
Then the HTTP status code should be "201"
And as "Alice" file "file.txt" should exist
And as "Alice" the mtime of the file "file.txt" should be "Thu, 08 Aug 2019 04:18:13 GMT"
And the content of file "file.txt" for user "Alice" should be "Overwrite file"
Examples:
| dav_version |
| old |
| new |
@skipOnOcV10 @personalSpace
Examples:
| dav_version |
| spaces |
Scenario Outline: upload a hidden file and check download content
Given using <dav_version> DAV path
And user "Alice" has created folder "/FOLDER"
When user "Alice" uploads the following files with content "hidden file"
| path |
| .hidden_file |
| /FOLDER/.hidden_file |
Then the HTTP status code of responses on all endpoints should be "201"
And as "Alice" the following files should exist
| path |
| .hidden_file |
| /FOLDER/.hidden_file |
And the content of the following files for user "Alice" should be "hidden file"
| path |
| .hidden_file |
| /FOLDER/.hidden_file |
Examples:
| dav_version |
| old |
| new |
@skipOnOcV10 @personalSpace
Examples:
| dav_version |
| spaces |
Scenario Outline: upload a file of size zero byte
Given using <dav_version> DAV path
When user "Alice" uploads file "filesForUpload/zerobyte.txt" to "/zerobyte.txt" using the WebDAV API
Then the HTTP status code should be "201"
And as "Alice" file "zerobyte.txt" should exist
Examples:
| dav_version |
| old |
| new |
@skipOnOcV10 @personalSpace
Examples:
| dav_version |
| spaces |
tests/acceptance/features/coreApiWebdavUpload1/uploadFileAsyncUsingNewChunking.feature
+184
View File
@@ -0,0 +1,184 @@
@api @issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321
Feature: upload file using new chunking
As a user
I want to be able to upload "large" files in chunks asynchronously
So that I do not have to wait for the long MOVE operation on assembly to finish
Background:
Given using new DAV path
And user "Alice" has been created with default attributes and without skeleton files
And the owncloud log level has been set to debug
And the owncloud log has been cleared
And the administrator has enabled async operations
Scenario: Upload chunked file ordered asc using async MOVE
When user "Alice" uploads the following chunks asynchronously to "/myChunkedFile.txt" with new chunking and using the WebDAV API
| number | content |
| 1 | AAAAA |
| 2 | BBBBB |
| 3 | CCCCC |
Then the HTTP status code should be "202"
And the following headers should match these regular expressions for user "Alice"
| OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/%username%\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ |
And the oc job status values of last request for user "Alice" should match these regular expressions
| status | /^finished$/ |
| fileId | /^[0-9a-z]{20,}$/ |
And the content of file "/myChunkedFile.txt" for user "Alice" should be "AAAAABBBBBCCCCC"
And the log file should not contain any log-entries containing these attributes:
| app |
| dav |
Scenario: Upload chunked file ordered desc using async MOVE
When user "Alice" uploads the following chunks asynchronously to "/myChunkedFile.txt" with new chunking and using the WebDAV API
| number | content |
| 3 | CCCCC |
| 2 | BBBBB |
| 1 | AAAAA |
Then the HTTP status code should be "202"
And the following headers should match these regular expressions for user "Alice"
| OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/%username%\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ |
And the oc job status values of last request for user "Alice" should match these regular expressions
| status | /^finished$/ |
| fileId | /^[0-9a-z]{20,}$/ |
And the content of file "/myChunkedFile.txt" for user "Alice" should be "AAAAABBBBBCCCCC"
And the log file should not contain any log-entries containing these attributes:
| app |
| dav |
Scenario: Upload chunked file in random order using async MOVE
When user "Alice" uploads the following chunks asynchronously to "/myChunkedFile.txt" with new chunking and using the WebDAV API
| number | content |
| 2 | BBBBB |
| 3 | CCCCC |
| 1 | AAAAA |
Then the HTTP status code should be "202"
And the following headers should match these regular expressions for user "Alice"
| OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/%username%\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ |
And the oc job status values of last request for user "Alice" should match these regular expressions
| status | /^finished$/ |
| fileId | /^[0-9a-z]{20,}$/ |
And the content of file "/myChunkedFile.txt" for user "Alice" should be "AAAAABBBBBCCCCC"
And the log file should not contain any log-entries containing these attributes:
| app |
| dav |
Scenario: Upload chunked file overwriting existing file using async MOVE
Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
And user "Alice" has copied file "/textfile0.txt" to "/existingFile.txt"
When user "Alice" uploads the following chunks asynchronously to "/existingFile.txt" with new chunking and using the WebDAV API
| number | content |
| 1 | AAAAA |
| 2 | BBBBB |
| 3 | CCCCC |
Then the HTTP status code should be "202"
And the following headers should match these regular expressions for user "Alice"
| OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/%username%\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ |
And the oc job status values of last request for user "Alice" should match these regular expressions
| status | /^finished$/ |
| fileId | /^[0-9a-z]{20,}$/ |
And the content of file "/existingFile.txt" for user "Alice" should be "AAAAABBBBBCCCCC"
And the log file should not contain any log-entries containing these attributes:
| app |
| dav |
Scenario: New chunked upload MOVE using old DAV path should fail
Given user "Alice" has created a new chunking upload with id "chunking-42"
And user "Alice" has uploaded new chunk file "2" with "BBBBB" to id "chunking-42"
And user "Alice" has uploaded new chunk file "3" with "CCCCC" to id "chunking-42"
And user "Alice" has uploaded new chunk file "1" with "AAAAA" to id "chunking-42"
When using old DAV path
And user "Alice" moves new chunk file with id "chunking-42" asynchronously to "/myChunkedFile.txt" using the WebDAV API
Then the HTTP status code should be "404"
Scenario: Upload file via new chunking endpoint with wrong size header using async MOVE
Given user "Alice" has created a new chunking upload with id "chunking-42"
And user "Alice" has uploaded new chunk file "1" with "AAAAA" to id "chunking-42"
And user "Alice" has uploaded new chunk file "2" with "BBBBB" to id "chunking-42"
And user "Alice" has uploaded new chunk file "3" with "CCCCC" to id "chunking-42"
When user "Alice" moves new chunk file with id "chunking-42" asynchronously to "/myChunkedFile.txt" with size 5 using the WebDAV API
Then the HTTP status code should be "202"
And the following headers should match these regular expressions for user "Alice"
| OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/%username%\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ |
And the oc job status values of last request for user "Alice" should match these regular expressions
| status | /^error$/ |
| errorCode | /^400$/ |
| errorMessage | /^Chunks on server do not sum up to 5 but to 15$/ |
Scenario: Upload file via new chunking endpoint with correct size header using async MOVE
Given user "Alice" has created a new chunking upload with id "chunking-42"
And user "Alice" has uploaded new chunk file "1" with "AAAAA" to id "chunking-42"
And user "Alice" has uploaded new chunk file "2" with "BBBBB" to id "chunking-42"
And user "Alice" has uploaded new chunk file "3" with "CCCCC" to id "chunking-42"
When user "Alice" moves new chunk file with id "chunking-42" asynchronously to "/myChunkedFile.txt" with size 15 using the WebDAV API
Then the HTTP status code should be "202"
And the following headers should match these regular expressions for user "Alice"
| OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/%username%\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ |
And the oc job status values of last request for user "Alice" should match these regular expressions
| status | /^finished$/ |
| fileId | /^[0-9a-z]{20,}$/ |
And as "Alice" file "/myChunkedFile.txt" should exist
And the content of file "/myChunkedFile.txt" for user "Alice" should be "AAAAABBBBBCCCCC"
And the log file should not contain any log-entries containing these attributes:
| app |
| dav |
Scenario Outline: Upload files with difficult names using new chunking and async MOVE
When user "Alice" creates a new chunking upload with id "chunking-42" using the WebDAV API
And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API
And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API
And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API
And user "Alice" moves new chunk file with id "chunking-42" asynchronously to "/<file-name>" using the WebDAV API
Then the HTTP status code should be "202"
And the following headers should match these regular expressions for user "Alice"
| OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/%username%\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ |
And the oc job status values of last request for user "Alice" should match these regular expressions
| status | /^finished$/ |
| fileId | /^[0-9a-z]{20,}$/ |
And as "Alice" file "/<file-name>" should exist
And the content of file "/<file-name>" for user "Alice" should be "AAAAABBBBBCCCCC"
And the log file should not contain any log-entries containing these attributes:
| app |
| dav |
Examples:
| file-name |
| &#? |
| TIÄFÜ |
Scenario: disabled async operations leads to original behavior
Given the administrator has disabled async operations
When user "Alice" uploads the following chunks asynchronously to "/myChunkedFile.txt" with new chunking and using the WebDAV API
| number | content |
| 1 | AAAAA |
| 2 | BBBBB |
| 3 | CCCCC |
Then the HTTP status code should be "201"
And the following headers should not be set
| header |
| OC-JobStatus-Location |
And the content of file "/myChunkedFile.txt" for user "Alice" should be "AAAAABBBBBCCCCC"
Scenario: enabling async operations does no difference to normal MOVE - Upload chunked file
When user "Alice" uploads the following chunks to "/myChunkedFile.txt" with new chunking and using the WebDAV API
| number | content |
| 1 | AAAAA |
| 2 | BBBBB |
| 3 | CCCCC |
Then the HTTP status code should be "201"
And the following headers should not be set
| header |
| OC-JobStatus-Location |
And as "Alice" file "/myChunkedFile.txt" should exist
And the content of file "/myChunkedFile.txt" for user "Alice" should be "AAAAABBBBBCCCCC"
And the log file should not contain any log-entries containing these attributes:
| app |
| dav |
tests/acceptance/features/coreApiWebdavUpload1/uploadFileToBlacklistedName.feature
+76
View File
@@ -0,0 +1,76 @@
@api
Feature: users cannot upload a file to a blacklisted name
As an administrator
I want to be able to prevent users from uploading files to specified file names
So that I can prevent unwanted file names existing in the cloud storage
Background:
Given using OCS API version "1"
And user "Alice" has been created with default attributes and without skeleton files
@issue-ocis-reva-15 @notToImplementOnOCIS
Scenario Outline: upload a file to a filename that is banned by default
Given using <dav_version> DAV path
When user "Alice" uploads file with content "uploaded content" to ".htaccess" using the WebDAV API
Then the HTTP status code should be "403"
And as "Alice" file ".htaccess" should not exist
Examples:
| dav_version |
| old |
| new |
@issue-ocis-reva-54
Scenario Outline: upload a file to a banned filename
Given using <dav_version> DAV path
And the administrator has updated system config key "blacklisted_files" with value '["blacklisted-file.txt",".htaccess"]' and type "json"
When user "Alice" uploads file with content "uploaded content" to "blacklisted-file.txt" using the WebDAV API
Then the HTTP status code should be "403"
And as "Alice" file "blacklisted-file.txt" should not exist
Examples:
| dav_version |
| old |
| new |
@skipOnOcV10 @personalSpace
Examples:
| dav_version |
| spaces |
@issue-ocis-reva-54
Scenario Outline: upload a file to a filename that matches (or not) blacklisted_files_regex
Given using <dav_version> DAV path
And user "Alice" has created folder "FOLDER"
# Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it
# The actual regular expressions end up being .*\.ext$ and ^bannedfilename\..+
And the administrator has updated system config key "blacklisted_files_regex" with value '[".*\\.ext$","^bannedfilename\\..+","containsbannedstring"]' and type "json"
When user "Alice" uploads to these filenames with content "uploaded content" using the webDAV API then the results should be as listed
| filename | http-code | exists |
| .ext | 403 | no |
| filename.ext | 403 | no |
| bannedfilename.txt | 403 | no |
| containsbannedstring | 403 | no |
| this-ContainsBannedString.txt | 403 | no |
| /FOLDER/.ext | 403 | no |
| /FOLDER/filename.ext | 403 | no |
| /FOLDER/bannedfilename.txt | 403 | no |
| /FOLDER/containsbannedstring | 403 | no |
| /FOLDER/this-ContainsBannedString.txt | 403 | no |
| .extension | 201 | yes |
| filename.txt | 201 | yes |
| bannedfilename | 201 | yes |
| bannedfilenamewithoutdot | 201 | yes |
| not-contains-banned-string.txt | 201 | yes |
| /FOLDER/.extension | 201 | yes |
| /FOLDER/filename.txt | 201 | yes |
| /FOLDER/bannedfilename | 201 | yes |
| /FOLDER/bannedfilenamewithoutdot | 201 | yes |
| /FOLDER/not-contains-banned-string.txt | 201 | yes |
Examples:
| dav_version |
| old |
| new |
@skipOnOcV10 @personalSpace
Examples:
| dav_version |
| spaces |
tests/acceptance/features/coreApiWebdavUpload1/uploadFileToBlacklistedNameAsyncUsingNewChunking.feature
+64
View File
@@ -0,0 +1,64 @@
@api @issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321
Feature: users cannot upload a file to a blacklisted name using new chunking
As an administrator
I want to be able to prevent users from uploading files to specified file names
So that I can prevent unwanted file names existing in the cloud storage
Background:
Given using new DAV path
And user "Alice" has been created with default attributes and without skeleton files
And the owncloud log level has been set to debug
And the owncloud log has been cleared
And the administrator has enabled async operations
Scenario: Upload to a filename that is banned by default using new chunking and async MOVE
When user "Alice" creates a new chunking upload with id "chunking-42" using the WebDAV API
And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API
And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API
And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API
And user "Alice" moves new chunk file with id "chunking-42" asynchronously to "/.htaccess" using the WebDAV API
Then the HTTP status code should be "403"
And as "Alice" file "/.htaccess" should not exist
Scenario: Upload to a banned filename using new chunking and async MOVE
Given the administrator has updated system config key "blacklisted_files" with value '["blacklisted-file.txt",".htaccess"]' and type "json"
When user "Alice" creates a new chunking upload with id "chunking-42" using the WebDAV API
And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API
And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API
And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API
And user "Alice" moves new chunk file with id "chunking-42" asynchronously to "/blacklisted-file.txt" using the WebDAV API
Then the HTTP status code should be "403"
And as "Alice" file "/blacklisted-file.txt" should not exist
Scenario Outline: upload a file to a filename that matches blacklisted_files_regex using new chunking and async MOVE
# Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it
# The actual regular expressions end up being .*\.ext$ and ^bannedfilename\..+
Given the administrator has updated system config key "blacklisted_files_regex" with value '[".*\\.ext$","^bannedfilename\\..+","containsbannedstring"]' and type "json"
When user "Alice" creates a new chunking upload with id "chunking-42" using the WebDAV API
And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API
And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API
And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API
And user "Alice" moves new chunk file with id "chunking-42" asynchronously to "<filename>" using the WebDAV API
Then the HTTP status code should be "403"
And as "Alice" file "<filename>" should not exist
Examples:
| filename |
| filename.ext |
| bannedfilename.txt |
| this-ContainsBannedString.txt |
Scenario: upload a file to a filename that does not match blacklisted_files_regex using new chunking and async MOVE
# Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it
# The actual regular expressions end up being .*\.ext$ and ^bannedfilename\..+
Given the administrator has updated system config key "blacklisted_files_regex" with value '[".*\\.ext$","^bannedfilename\\..+","containsbannedstring"]' and type "json"
When user "Alice" creates a new chunking upload with id "chunking-42" using the WebDAV API
And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API
And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API
And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API
And user "Alice" moves new chunk file with id "chunking-42" asynchronously to "not-contains-banned-string.txt" using the WebDAV API
Then the HTTP status code should be "202"
And as "Alice" file "not-contains-banned-string.txt" should exist
tests/acceptance/features/coreApiWebdavUpload1/uploadFileToExcludedDirectory.feature
+86
View File
@@ -0,0 +1,86 @@
@api
Feature: users cannot upload a file to or into an excluded directory
As an administrator
I want to be able to exclude directories (folders) from being processed. Any attempt to upload a file to one of those names should be refused.
So that I can have directories on my cloud server storage that are not available for syncing.
Background:
Given using OCS API version "1"
And user "Alice" has been created with default attributes and without skeleton files
@issue-ocis-reva-54
Scenario Outline: upload a file to an excluded directory name
Given using <dav_version> DAV path
And the administrator has updated system config key "excluded_directories" with value '[".github"]' and type "json"
When user "Alice" uploads file with content "uploaded content" to ".github" using the WebDAV API
Then the HTTP status code should be "403"
And as "Alice" file ".github" should not exist
Examples:
| dav_version |
| old |
| new |
@skipOnOcV10 @personalSpace
Examples:
| dav_version |
| spaces |
@issue-ocis-reva-54
Scenario Outline: upload a file to an excluded directory name inside a parent directory
Given using <dav_version> DAV path
And user "Alice" has created folder "FOLDER"
And the administrator has updated system config key "excluded_directories" with value '[".github"]' and type "json"
When user "Alice" uploads file with content "uploaded content" to "/FOLDER/.github" using the WebDAV API
Then the HTTP status code should be "403"
And as "Alice" folder "/FOLDER" should exist
But as "Alice" file "/FOLDER/.github" should not exist
Examples:
| dav_version |
| old |
| new |
@skipOnOcV10 @personalSpace
Examples:
| dav_version |
| spaces |
@issue-ocis-reva-54
Scenario Outline: upload a file to a filename that matches (or not) excluded_directories_regex
Given using <dav_version> DAV path
And user "Alice" has created folder "FOLDER"
# Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it
# The actual regular expressions end up being endswith\.bad$ and ^\.git
And the administrator has updated system config key "excluded_directories_regex" with value '["endswith\\.bad$","^\\.git","containsvirusinthename"]' and type "json"
When user "Alice" uploads to these filenames with content "uploaded content" using the webDAV API then the results should be as listed
| filename | http-code | exists |
| endswith.bad | 403 | no |
| thisendswith.bad | 403 | no |
| .git | 403 | no |
| .github | 403 | no |
| containsvirusinthename | 403 | no |
| this-containsvirusinthename.txt | 403 | no |
| /FOLDER/endswith.bad | 403 | no |
| /FOLDER/thisendswith.bad | 403 | no |
| /FOLDER/.git | 403 | no |
| /FOLDER/.github | 403 | no |
| /FOLDER/containsvirusinthename | 403 | no |
| /FOLDER/this-containsvirusinthename.txt | 403 | no |
| endswith.badandotherstuff | 201 | yes |
| thisendswith.badandotherstuff | 201 | yes |
| name.git | 201 | yes |
| name.github | 201 | yes |
| not-contains-virus-in-the-name.txt | 201 | yes |
| /FOLDER/endswith.badandotherstuff | 201 | yes |
| /FOLDER/thisendswith.badandotherstuff | 201 | yes |
| /FOLDER/name.git | 201 | yes |
| /FOLDER/name.github | 201 | yes |
| /FOLDER/not-contains-virus-in-the-name.txt | 201 | yes |
Examples:
| dav_version |
| old |
| new |
@skipOnOcV10 @personalSpace
Examples:
| dav_version |
| spaces |
tests/acceptance/features/coreApiWebdavUpload1/uploadFileToExcludedDirectoryAsyncUsingNewChunking.feature
+67
View File
@@ -0,0 +1,67 @@
@api @issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321
Feature: users cannot upload a file to or into an excluded directory using new chunking
As an administrator
I want to be able to exclude directories (folders) from being processed. Any attempt to upload a file to one of those names should be refused.
So that I can have directories on my cloud server storage that are not available for syncing.
Background:
Given using new DAV path
And user "Alice" has been created with default attributes and without skeleton files
And the owncloud log level has been set to debug
And the owncloud log has been cleared
And the administrator has enabled async operations
Scenario: Upload to an excluded directory name using new chunking and async MOVE
Given the administrator has updated system config key "excluded_directories" with value '[".github"]' and type "json"
When user "Alice" creates a new chunking upload with id "chunking-42" using the WebDAV API
And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API
And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API
And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API
And user "Alice" moves new chunk file with id "chunking-42" asynchronously to "/.github" using the WebDAV API
Then the HTTP status code should be "403"
And as "Alice" file "/.github" should not exist
Scenario: Upload to an excluded directory name inside a parent directory using new chunking and async MOVE
Given user "Alice" has created folder "FOLDER"
And the administrator has updated system config key "excluded_directories" with value '[".github"]' and type "json"
When user "Alice" creates a new chunking upload with id "chunking-42" using the WebDAV API
And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API
And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API
And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API
And user "Alice" moves new chunk file with id "chunking-42" asynchronously to "/FOLDER/.github" using the WebDAV API
Then the HTTP status code should be "403"
And as "Alice" folder "/FOLDER" should exist
But as "Alice" file "/FOLDER/.github" should not exist
Scenario Outline: upload a file to a filename that matches excluded_directories_regex using new chunking and async MOVE
# Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it
# The actual regular expressions end up being endswith\.bad$ and ^\.git
Given the administrator has updated system config key "excluded_directories_regex" with value '["endswith\\.bad$","^\\.git","containsvirusinthename"]' and type "json"
When user "Alice" creates a new chunking upload with id "chunking-42" using the WebDAV API
And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API
And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API
And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API
And user "Alice" moves new chunk file with id "chunking-42" asynchronously to "<filename>" using the WebDAV API
Then the HTTP status code should be "403"
And as "Alice" file "<filename>" should not exist
Examples:
| filename |
| thisendswith.bad |
| .github |
| this-containsvirusinthename.txt |
Scenario: upload a file to a filename that does not match excluded_directories_regex using new chunking and async MOVE
# Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it
# The actual regular expressions end up being endswith\.bad$ and ^\.git
Given the administrator has updated system config key "excluded_directories_regex" with value '["endswith\\.bad$","^\\.git","containsvirusinthename"]' and type "json"
When user "Alice" creates a new chunking upload with id "chunking-42" using the WebDAV API
And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API
And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API
And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API
And user "Alice" moves new chunk file with id "chunking-42" asynchronously to "not-contains-virus-in-the-name.txt" using the WebDAV API
Then the HTTP status code should be "202"
And as "Alice" file "not-contains-virus-in-the-name.txt" should exist