copy feature files from core
This commit is contained in:
Saw-jan
@@ -0,0 +1,291 @@
|
||||
@api @skipOnOcV10
|
||||
Feature: checksums
|
||||
|
||||
Background:
|
||||
Given user "Alice" has been created with default attributes and without skeleton files
|
||||
|
||||
|
||||
Scenario Outline: Uploading a file with checksum should work
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has created a new TUS resource on the WebDAV API with these headers:
|
||||
| Upload-Length | 5 |
|
||||
# dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt
|
||||
| Upload-Metadata | filename dGV4dEZpbGUudHh0 |
|
||||
When user "Alice" uploads file with checksum "<checksum>" to the last created TUS Location with offset "0" and content "12345" using the TUS protocol on the WebDAV API
|
||||
Then the HTTP status code should be "204"
|
||||
And the content of file "/textFile.txt" for user "Alice" should be "12345"
|
||||
Examples:
|
||||
| dav_version | checksum |
|
||||
| old | MD5 827ccb0eea8a706c4c34a16891f84e7b |
|
||||
| new | MD5 827ccb0eea8a706c4c34a16891f84e7b |
|
||||
| old | SHA1 8cb2237d0679ca88db6464eac60da96345513964 |
|
||||
| new | SHA1 8cb2237d0679ca88db6464eac60da96345513964 |
|
||||
|
||||
@personalSpace
|
||||
Examples:
|
||||
| dav_version | checksum |
|
||||
| spaces | MD5 827ccb0eea8a706c4c34a16891f84e7b |
|
||||
| spaces | SHA1 8cb2237d0679ca88db6464eac60da96345513964 |
|
||||
|
||||
|
||||
Scenario Outline: Uploading a file with checksum should return the checksum in the propfind
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has created a new TUS resource on the WebDAV API with these headers:
|
||||
| Upload-Length | 5 |
|
||||
# dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt
|
||||
| Upload-Metadata | filename dGV4dEZpbGUudHh0 |
|
||||
When user "Alice" uploads file with checksum "MD5 827ccb0eea8a706c4c34a16891f84e7b" to the last created TUS Location with offset "0" and content "12345" using the TUS protocol on the WebDAV API
|
||||
And user "Alice" requests the checksum of "/textFile.txt" via propfind
|
||||
Then the HTTP status code should be "207"
|
||||
And the webdav checksum should match "SHA1:8cb2237d0679ca88db6464eac60da96345513964 MD5:827ccb0eea8a706c4c34a16891f84e7b ADLER32:02f80100"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
@personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
|
||||
|
||||
Scenario Outline: Uploading a file with checksum should return the checksum in the download header
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has created a new TUS resource on the WebDAV API with these headers:
|
||||
| Upload-Length | 5 |
|
||||
# dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt
|
||||
| Upload-Metadata | filename dGV4dEZpbGUudHh0 |
|
||||
And user "Alice" has uploaded file with checksum "MD5 827ccb0eea8a706c4c34a16891f84e7b" to the last created TUS Location with offset "0" and content "12345" using the TUS protocol on the WebDAV API
|
||||
When user "Alice" downloads file "/textFile.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "200"
|
||||
And the header checksum should match "SHA1:8cb2237d0679ca88db6464eac60da96345513964"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
@personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
|
||||
|
||||
Scenario Outline: Uploading a file with incorrect checksum should not work
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has created a new TUS resource on the WebDAV API with these headers:
|
||||
| Upload-Length | 5 |
|
||||
# dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt
|
||||
| Upload-Metadata | filename dGV4dEZpbGUudHh0 |
|
||||
When user "Alice" uploads file with checksum "<incorrect_checksum>" to the last created TUS Location with offset "0" and content "12345" using the TUS protocol on the WebDAV API
|
||||
Then the HTTP status code should be "406"
|
||||
And as "Alice" file "textFile.txt" should not exist
|
||||
Examples:
|
||||
| dav_version | incorrect_checksum |
|
||||
| old | MD5 827ccb0eea8a706c4c34a16891f84e7a |
|
||||
| new | MD5 827ccb0eea8a706c4c34a16891f84e7a |
|
||||
| old | SHA1 8cb2237d0679ca88db6464eac60da96345513963 |
|
||||
| new | SHA1 8cb2237d0679ca88db6464eac60da96345513963 |
|
||||
|
||||
@personalSpace
|
||||
Examples:
|
||||
| dav_version | incorrect_checksum |
|
||||
| spaces | MD5 827ccb0eea8a706c4c34a16891f84e7a |
|
||||
| spaces | SHA1 8cb2237d0679ca88db6464eac60da96345513963 |
|
||||
|
||||
|
||||
Scenario Outline: Uploading a chunked file with correct checksum should work
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has created a new TUS resource on the WebDAV API with these headers:
|
||||
| Upload-Length | 10 |
|
||||
# dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt
|
||||
| Upload-Metadata | filename dGV4dEZpbGUudHh0 |
|
||||
When user "Alice" sends a chunk to the last created TUS Location with offset "0" and data "01234" with checksum "MD5 4100c4d44da9177247e44a5fc1546778" using the TUS protocol on the WebDAV API
|
||||
And user "Alice" sends a chunk to the last created TUS Location with offset "5" and data "56789" with checksum "MD5 099ebea48ea9666a7da2177267983138" using the TUS protocol on the WebDAV API
|
||||
Then the HTTP status code should be "204"
|
||||
And the content of file "/textFile.txt" for user "Alice" should be "0123456789"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
@personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
|
||||
|
||||
Scenario Outline: Uploading a chunked file with correct checksum should return the checksum in the propfind
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has created a new TUS resource on the WebDAV API with these headers:
|
||||
| Upload-Length | 10 |
|
||||
# dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt
|
||||
| Upload-Metadata | filename dGV4dEZpbGUudHh0 |
|
||||
And user "Alice" has uploaded a chunk to the last created TUS Location with offset "0" and data "01234" with checksum "MD5 4100c4d44da9177247e44a5fc1546778" using the TUS protocol on the WebDAV API
|
||||
And user "Alice" has uploaded a chunk to the last created TUS Location with offset "5" and data "56789" with checksum "MD5 099ebea48ea9666a7da2177267983138" using the TUS protocol on the WebDAV API
|
||||
When user "Alice" requests the checksum of "/textFile.txt" via propfind
|
||||
Then the HTTP status code should be "207"
|
||||
And the webdav checksum should match "SHA1:87acec17cd9dcd20a716cc2cf67417b71c8a7016 MD5:781e5e245d69b566979b86e28d23f2c7 ADLER32:0aff020e"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
@personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
|
||||
|
||||
Scenario Outline: Uploading a chunked file with checksum should return the checksum in the download header
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has created a new TUS resource on the WebDAV API with these headers:
|
||||
| Upload-Length | 10 |
|
||||
# dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt
|
||||
| Upload-Metadata | filename dGV4dEZpbGUudHh0 |
|
||||
And user "Alice" has uploaded a chunk to the last created TUS Location with offset "0" and data "01234" with checksum "MD5 4100c4d44da9177247e44a5fc1546778" using the TUS protocol on the WebDAV API
|
||||
And user "Alice" has uploaded a chunk to the last created TUS Location with offset "5" and data "56789" with checksum "MD5 099ebea48ea9666a7da2177267983138" using the TUS protocol on the WebDAV API
|
||||
When user "Alice" downloads file "/textFile.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "200"
|
||||
And the header checksum should match "SHA1:87acec17cd9dcd20a716cc2cf67417b71c8a7016"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
@personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
|
||||
|
||||
Scenario Outline: Uploading second chunk of file with incorrect checksum should not work
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has created a new TUS resource on the WebDAV API with these headers:
|
||||
| Upload-Length | 10 |
|
||||
# dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt
|
||||
| Upload-Metadata | filename dGV4dEZpbGUudHh0 |
|
||||
When user "Alice" sends a chunk to the last created TUS Location with offset "0" and data "01234" with checksum "MD5 4100c4d44da9177247e44a5fc1546799" using the TUS protocol on the WebDAV API
|
||||
And user "Alice" sends a chunk to the last created TUS Location with offset "5" and data "56789" with checksum "MD5 781e5e245d69b566979b86e28d23f2c7" using the TUS protocol on the WebDAV API
|
||||
Then the HTTP status code should be "409"
|
||||
And as "Alice" file "textFile.txt" should not exist
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
@personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
|
||||
|
||||
Scenario Outline: Uploading a file with correct checksum and overwriting an existing file should return the checksum for new data in the propfind
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has created a new TUS resource on the WebDAV API with these headers:
|
||||
| Upload-Length | 10 |
|
||||
# dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt
|
||||
| Upload-Metadata | filename dGV4dEZpbGUudHh0 |
|
||||
And user "Alice" has uploaded a chunk to the last created TUS Location with offset "0" and data "01234" with checksum "MD5 4100c4d44da9177247e44a5fc1546778" using the TUS protocol on the WebDAV API
|
||||
And user "Alice" has uploaded a chunk to the last created TUS Location with offset "5" and data "56789" with checksum "MD5 099ebea48ea9666a7da2177267983138" using the TUS protocol on the WebDAV API
|
||||
When user "Alice" overwrites existing file with offset "0" and data "hello" with checksum "<overwriteChecksum>" using the TUS protocol on the WebDAV API with these headers:
|
||||
| Upload-Length | 5 |
|
||||
| Upload-Metadata | filename dGV4dEZpbGUudHh0 |
|
||||
And user "Alice" requests the checksum of "/textFile.txt" via propfind
|
||||
Then the HTTP status code should be "207"
|
||||
And the webdav checksum should match "SHA1:aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d MD5:5d41402abc4b2a76b9719d911017c592 ADLER32:062c0215"
|
||||
And the content of file "/textFile.txt" for user "Alice" should be "hello"
|
||||
Examples:
|
||||
| dav_version | overwriteChecksum |
|
||||
| old | MD5 5d41402abc4b2a76b9719d911017c592 |
|
||||
| new | MD5 5d41402abc4b2a76b9719d911017c592 |
|
||||
| old | SHA1 aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d |
|
||||
| new | SHA1 aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d |
|
||||
|
||||
@personalSpace
|
||||
Examples:
|
||||
| dav_version | overwriteChecksum |
|
||||
| spaces | MD5 5d41402abc4b2a76b9719d911017c592 |
|
||||
| spaces | SHA1 aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d |
|
||||
|
||||
|
||||
Scenario Outline: Uploading a file with correct checksum and overwriting an existing file with invalid checksum should not work
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has created a new TUS resource on the WebDAV API with these headers:
|
||||
| Upload-Length | 10 |
|
||||
# dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt
|
||||
| Upload-Metadata | filename dGV4dEZpbGUudHh0 |
|
||||
And user "Alice" has uploaded a chunk to the last created TUS Location with offset "0" and data "01234" with checksum "MD5 4100c4d44da9177247e44a5fc1546778" using the TUS protocol on the WebDAV API
|
||||
And user "Alice" has uploaded a chunk to the last created TUS Location with offset "5" and data "56789" with checksum "MD5 099ebea48ea9666a7da2177267983138" using the TUS protocol on the WebDAV API
|
||||
When user "Alice" overwrites existing file with offset "0" and data "hello" with checksum "<overwriteInvalidChecksum>" using the TUS protocol on the WebDAV API with these headers:
|
||||
| Upload-Length | 5 |
|
||||
| Upload-Metadata | filename dGV4dEZpbGUudHh0 |
|
||||
Then the HTTP status code should be "406"
|
||||
And the content of file "/textFile.txt" for user "Alice" should be "0123456789"
|
||||
Examples:
|
||||
| dav_version | overwriteInvalidChecksum |
|
||||
| old | MD5 5d41402abc4b2a76b9719d911017c593 |
|
||||
| new | MD5 5d41402abc4b2a76b9719d911017c593 |
|
||||
| old | SHA1 aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434a |
|
||||
| new | SHA1 aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434a |
|
||||
|
||||
@personalSpace
|
||||
Examples:
|
||||
| dav_version | overwriteInvalidChecksum |
|
||||
| spaces | MD5 5d41402abc4b2a76b9719d911017c593 |
|
||||
| spaces | SHA1 aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434a |
|
||||
|
||||
|
||||
Scenario Outline: Overwriting an existing file with new data and checksum should return the checksum of new data in the propfind
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has created a new TUS resource on the WebDAV API with these headers:
|
||||
| Upload-Length | 5 |
|
||||
# dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt
|
||||
| Upload-Metadata | filename dGV4dEZpbGUudHh0 |
|
||||
And user "Alice" has uploaded file with checksum "MD5 827ccb0eea8a706c4c34a16891f84e7b" to the last created TUS Location with offset "0" and content "12345" using the TUS protocol on the WebDAV API
|
||||
When user "Alice" overwrites existing file with offset "0" and data "hello" with checksum "<overwriteChecksum>" using the TUS protocol on the WebDAV API with these headers:
|
||||
| Upload-Length | 5 |
|
||||
# dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt
|
||||
| Upload-Metadata | filename dGV4dEZpbGUudHh0 |
|
||||
And user "Alice" requests the checksum of "/textFile.txt" via propfind
|
||||
Then the HTTP status code should be "207"
|
||||
And the webdav checksum should match "SHA1:aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d MD5:5d41402abc4b2a76b9719d911017c592 ADLER32:062c0215"
|
||||
And the content of file "/textFile.txt" for user "Alice" should be "hello"
|
||||
Examples:
|
||||
| dav_version | overwriteChecksum |
|
||||
| old | MD5 5d41402abc4b2a76b9719d911017c592 |
|
||||
| new | MD5 5d41402abc4b2a76b9719d911017c592 |
|
||||
| old | SHA1 aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d |
|
||||
| new | SHA1 aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d |
|
||||
|
||||
@personalSpace
|
||||
Examples:
|
||||
| dav_version | overwriteChecksum |
|
||||
| spaces | MD5 5d41402abc4b2a76b9719d911017c592 |
|
||||
| spaces | SHA1 aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d |
|
||||
|
||||
|
||||
Scenario Outline: Overwriting an existing file with new data and invalid checksum should not work
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has created a new TUS resource on the WebDAV API with these headers:
|
||||
| Upload-Length | 5 |
|
||||
# dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt
|
||||
| Upload-Metadata | filename dGV4dEZpbGUudHh0 |
|
||||
And user "Alice" has uploaded file with checksum "MD5 827ccb0eea8a706c4c34a16891f84e7b" to the last created TUS Location with offset "0" and content "12345" using the TUS protocol on the WebDAV API
|
||||
When user "Alice" overwrites existing file with offset "0" and data "hello" with checksum "<overwriteChecksum>" using the TUS protocol on the WebDAV API with these headers:
|
||||
| Upload-Length | 5 |
|
||||
# dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt
|
||||
| Upload-Metadata | filename dGV4dEZpbGUudHh0 |
|
||||
Then the HTTP status code should be "406"
|
||||
And the content of file "/textFile.txt" for user "Alice" should be "12345"
|
||||
Examples:
|
||||
| dav_version | overwriteChecksum |
|
||||
| old | MD5 5d41402abc4b2a76b9719d911017c593 |
|
||||
| new | MD5 5d41402abc4b2a76b9719d911017c593 |
|
||||
| old | SHA1 aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434a |
|
||||
| new | SHA1 aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434a |
|
||||
|
||||
@personalSpace
|
||||
Examples:
|
||||
| dav_version | overwriteChecksum |
|
||||
| spaces | MD5 5d41402abc4b2a76b9719d911017c593 |
|
||||
| spaces | SHA1 aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434a |
|
||||
@@ -0,0 +1,46 @@
|
||||
@api @skipOnOcV10
|
||||
Feature: tests of the creation extension see https://tus.io/protocols/resumable-upload.html#creation-with-upload
|
||||
|
||||
Background:
|
||||
Given user "Alice" has been created with default attributes and without skeleton files
|
||||
|
||||
|
||||
Scenario Outline: creating a new upload resource using creation with upload extension
|
||||
Given using <dav_version> DAV path
|
||||
When user "Alice" creates a new TUS resource with content "uploaded content" on the WebDAV API with these headers:
|
||||
| Upload-Length | 16 |
|
||||
| Tus-Resumable | 1.0.0 |
|
||||
| Content-Type | application/offset+octet-stream |
|
||||
# dGVzdC50eHQ= is the base64 encode of test.txt
|
||||
| Upload-Metadata | filename dGVzdC50eHQ= |
|
||||
| Tus-Extension | creation-with-upload |
|
||||
Then the HTTP status code should be "201"
|
||||
And the following headers should match these regular expressions
|
||||
| Tus-Resumable | /1\.0\.0/ |
|
||||
| Location | /http[s]?:\/\/.*:\d+\/data\/.*/ |
|
||||
| Upload-Offset | /\d+/ |
|
||||
And the content of file "/test.txt" for user "Alice" should be "uploaded content"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
@personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
|
||||
|
||||
Scenario Outline: creating a new resource and upload data in multiple bytes using creation with upload extension
|
||||
Given using <dav_version> DAV path
|
||||
When user "Alice" creates file "textFile.txt" and uploads content "12345" in the same request using the TUS protocol on the WebDAV API
|
||||
Then the content of file "/textFile.txt" for user "Alice" should be "12345"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
@personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
@@ -0,0 +1,48 @@
|
||||
@api @skipOnOcV10
|
||||
Feature: low level tests of the creation extension see https://tus.io/protocols/resumable-upload.html#creation
|
||||
|
||||
Background:
|
||||
Given user "Alice" has been created with default attributes and without skeleton files
|
||||
|
||||
|
||||
Scenario Outline: creating a new upload resource
|
||||
Given using <dav_version> DAV path
|
||||
When user "Alice" creates a new TUS resource on the WebDAV API with these headers:
|
||||
| Upload-Length | 100 |
|
||||
# d29ybGRfZG9taW5hdGlvbl9wbGFuLnBkZg== is the base64 encode of world_domination_plan.pdf
|
||||
| Upload-Metadata | filename d29ybGRfZG9taW5hdGlvbl9wbGFuLnBkZg== |
|
||||
| Tus-Resumable | 1.0.0 |
|
||||
Then the HTTP status code should be "201"
|
||||
And the following headers should match these regular expressions
|
||||
| Tus-Resumable | /1\.0\.0/ |
|
||||
| Location | /http[s]?:\/\/.*:\d+\/data\/.*/ |
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
@personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
|
||||
|
||||
Scenario Outline: creating a new upload resource without upload length
|
||||
Given using <dav_version> DAV path
|
||||
When user "Alice" creates a new TUS resource on the WebDAV API with these headers:
|
||||
| Tus-Resumable | 1.0.0 |
|
||||
# d29ybGRfZG9taW5hdGlvbl9wbGFuLnBkZg== is the base64 encode of world_domination_plan.pdf
|
||||
| Upload-Metadata | filename d29ybGRfZG9taW5hdGlvbl9wbGFuLnBkZg== |
|
||||
Then the HTTP status code should be "412"
|
||||
And the following headers should not be set
|
||||
| header |
|
||||
| Location |
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
@personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
@@ -0,0 +1,90 @@
|
||||
@api @skipOnOcV10
|
||||
Feature: low level tests for upload of chunks
|
||||
|
||||
Background:
|
||||
Given user "Alice" has been created with default attributes and without skeleton files
|
||||
|
||||
|
||||
Scenario Outline: upload a chunk twice
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has created a new TUS resource on the WebDAV API with these headers:
|
||||
| Upload-Length | 10 |
|
||||
# ZmlsZS50eHQ= is the base64 encode of file.txt
|
||||
| Upload-Metadata | filename ZmlsZS50eHQ= |
|
||||
When user "Alice" sends a chunk to the last created TUS Location with offset "0" and data "123" using the WebDAV API
|
||||
And user "Alice" sends a chunk to the last created TUS Location with offset "0" and data "000" using the WebDAV API
|
||||
Then the HTTP status code should be "409"
|
||||
And as "Alice" file "file.txt" should not exist
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
@personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
|
||||
|
||||
Scenario Outline: finalize file upload after uploading a chunk twice
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has created a new TUS resource on the WebDAV API with these headers:
|
||||
| Upload-Length | 10 |
|
||||
# ZmlsZS50eHQ= is the base64 encode of file.txt
|
||||
| Upload-Metadata | filename ZmlsZS50eHQ= |
|
||||
When user "Alice" sends a chunk to the last created TUS Location with offset "0" and data "123" using the WebDAV API
|
||||
And user "Alice" sends a chunk to the last created TUS Location with offset "0" and data "000" using the WebDAV API
|
||||
And user "Alice" sends a chunk to the last created TUS Location with offset "3" and data "4567890" using the WebDAV API
|
||||
Then the HTTP status code should be "204"
|
||||
And the content of file "/file.txt" for user "Alice" should be "1234567890"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
@personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
|
||||
|
||||
Scenario Outline: send last chunk twice
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has created a new TUS resource on the WebDAV API with these headers:
|
||||
| Upload-Length | 10 |
|
||||
# ZmlsZS50eHQ= is the base64 encode of file.txt
|
||||
| Upload-Metadata | filename ZmlsZS50eHQ= |
|
||||
When user "Alice" sends a chunk to the last created TUS Location with offset "0" and data "123" using the WebDAV API
|
||||
And user "Alice" sends a chunk to the last created TUS Location with offset "3" and data "4567890" using the WebDAV API
|
||||
And user "Alice" sends a chunk to the last created TUS Location with offset "3" and data "0000000" using the WebDAV API
|
||||
Then the HTTP status code should be "404"
|
||||
And the content of file "/file.txt" for user "Alice" should be "1234567890"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
@personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
|
||||
|
||||
Scenario Outline: start with uploading not at the beginning of the file
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has created a new TUS resource on the WebDAV API with these headers:
|
||||
| Upload-Length | 10 |
|
||||
# ZmlsZS50eHQ= is the base64 encode of file.txt
|
||||
| Upload-Metadata | filename ZmlsZS50eHQ= |
|
||||
When user "Alice" sends a chunk to the last created TUS Location with offset "1" and data "123" using the WebDAV API
|
||||
Then the HTTP status code should be "409"
|
||||
And as "Alice" file "file.txt" should not exist
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
@personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
@@ -0,0 +1,115 @@
|
||||
@api @skipOnOcV10
|
||||
Feature: OPTIONS request
|
||||
|
||||
Background:
|
||||
Given user "Alice" has been created with default attributes and without skeleton files
|
||||
|
||||
|
||||
Scenario: send OPTIONS request to webDav endpoints using the TUS protocol with valid password and username
|
||||
When user "Alice" requests these endpoints with "OPTIONS" including body "doesnotmatter" using the password of user "Alice"
|
||||
| endpoint |
|
||||
| /remote.php/webdav/ |
|
||||
| /remote.php/dav/files/%username%/ |
|
||||
Then the HTTP status code should be "204"
|
||||
And the following headers should be set
|
||||
| header | value |
|
||||
| Tus-Resumable | 1.0.0 |
|
||||
| Tus-Version | 1.0.0 |
|
||||
| Tus-Extension | creation,creation-with-upload,checksum,expiration |
|
||||
| Tus-Checksum-Algorithm | md5,sha1,adler32 |
|
||||
|
||||
@personalSpace
|
||||
Scenario: send OPTIONS request to spaces webDav endpoint using the TUS protocol with valid password and username
|
||||
When user "Alice" requests these endpoints with "OPTIONS" including body "doesnotmatter" using the password of user "Alice"
|
||||
| endpoint |
|
||||
| /remote.php/dav/spaces/%spaceid%/ |
|
||||
Then the HTTP status code should be "204"
|
||||
And the following headers should be set
|
||||
| header | value |
|
||||
| Tus-Resumable | 1.0.0 |
|
||||
| Tus-Version | 1.0.0 |
|
||||
| Tus-Extension | creation,creation-with-upload,checksum,expiration |
|
||||
| Tus-Checksum-Algorithm | md5,sha1,adler32 |
|
||||
|
||||
|
||||
Scenario: send OPTIONS request to webDav endpoints using the TUS protocol without any authentication
|
||||
When a user requests these endpoints with "OPTIONS" with body "doesnotmatter" and no authentication about user "Alice"
|
||||
| endpoint |
|
||||
| /remote.php/webdav/ |
|
||||
| /remote.php/dav/files/%username%/ |
|
||||
Then the HTTP status code should be "204"
|
||||
And the following headers should be set
|
||||
| header | value |
|
||||
| Tus-Resumable | 1.0.0 |
|
||||
| Tus-Version | 1.0.0 |
|
||||
| Tus-Extension | creation,creation-with-upload,checksum,expiration |
|
||||
| Tus-Checksum-Algorithm | md5,sha1,adler32 |
|
||||
|
||||
@personalSpace
|
||||
Scenario: send OPTIONS request to spaces webDav endpoint using the TUS protocol without any authentication
|
||||
When a user requests these endpoints with "OPTIONS" with body "doesnotmatter" and no authentication about user "Alice"
|
||||
| endpoint |
|
||||
| /remote.php/dav/spaces/%spaceid%/ |
|
||||
Then the HTTP status code should be "204"
|
||||
And the following headers should be set
|
||||
| header | value |
|
||||
| Tus-Resumable | 1.0.0 |
|
||||
| Tus-Version | 1.0.0 |
|
||||
| Tus-Extension | creation,creation-with-upload,checksum,expiration |
|
||||
| Tus-Checksum-Algorithm | md5,sha1,adler32 |
|
||||
|
||||
|
||||
Scenario: send OPTIONS request to webDav endpoints using the TUS protocol with valid username and wrong password
|
||||
When user "Alice" requests these endpoints with "OPTIONS" including body "doesnotmatter" using password "invalid" about user "Alice"
|
||||
| endpoint |
|
||||
| /remote.php/webdav/ |
|
||||
| /remote.php/dav/files/%username%/ |
|
||||
Then the HTTP status code should be "401"
|
||||
And the following headers should be set
|
||||
| header | value |
|
||||
| Tus-Resumable | 1.0.0 |
|
||||
| Tus-Version | 1.0.0 |
|
||||
| Tus-Extension | creation,creation-with-upload,checksum,expiration |
|
||||
| Tus-Checksum-Algorithm | md5,sha1,adler32 |
|
||||
|
||||
@personalSpace
|
||||
Scenario: send OPTIONS request to spaces webDav endpoint using the TUS protocol with valid username and wrong password
|
||||
When user "Alice" requests these endpoints with "OPTIONS" including body "doesnotmatter" using password "invalid" about user "Alice"
|
||||
| endpoint |
|
||||
| /remote.php/dav/spaces/%spaceid%/ |
|
||||
Then the HTTP status code should be "401"
|
||||
And the following headers should be set
|
||||
| header | value |
|
||||
| Tus-Resumable | 1.0.0 |
|
||||
| Tus-Version | 1.0.0 |
|
||||
| Tus-Extension | creation,creation-with-upload,checksum,expiration |
|
||||
| Tus-Checksum-Algorithm | md5,sha1,adler32 |
|
||||
|
||||
|
||||
Scenario: send OPTIONS requests to webDav endpoints using valid password and username of different user
|
||||
Given user "Brian" has been created with default attributes and without skeleton files
|
||||
When user "Brian" requests these endpoints with "OPTIONS" including body "doesnotmatter" using the password of user "Alice"
|
||||
| endpoint |
|
||||
| /remote.php/webdav/ |
|
||||
| /remote.php/dav/files/%username%/ |
|
||||
Then the HTTP status code should be "401"
|
||||
And the following headers should be set
|
||||
| header | value |
|
||||
| Tus-Resumable | 1.0.0 |
|
||||
| Tus-Version | 1.0.0 |
|
||||
| Tus-Extension | creation,creation-with-upload,checksum,expiration |
|
||||
| Tus-Checksum-Algorithm | md5,sha1,adler32 |
|
||||
|
||||
@personalSpace
|
||||
Scenario: send OPTIONS requests to spaces webDav endpoints using valid password and username of different user
|
||||
Given user "Brian" has been created with default attributes and without skeleton files
|
||||
When user "Brian" requests these endpoints with "OPTIONS" including body "doesnotmatter" using the password of user "Alice"
|
||||
| endpoint |
|
||||
| /remote.php/dav/spaces/%spaceid%/ |
|
||||
Then the HTTP status code should be "401"
|
||||
And the following headers should be set
|
||||
| header | value |
|
||||
| Tus-Resumable | 1.0.0 |
|
||||
| Tus-Version | 1.0.0 |
|
||||
| Tus-Extension | creation,creation-with-upload,checksum,expiration |
|
||||
| Tus-Checksum-Algorithm | md5,sha1,adler32 |
|
||||
@@ -0,0 +1,211 @@
|
||||
@api @skipOnOcV10
|
||||
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 user "Alice" has been created with default attributes and without skeleton files
|
||||
|
||||
|
||||
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 TUS protocol on the WebDAV API
|
||||
Then 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 |
|
||||
| old | /C++ file.cpp |
|
||||
| old | /?fi=le&%#2 . txt |
|
||||
| old | /# %ab ab?=ed |
|
||||
| new | /upload.txt |
|
||||
| new | /strängé file.txt |
|
||||
| new | /नेपाली.txt |
|
||||
| new | /s,a,m,p,l,e.txt |
|
||||
| new | /C++ file.cpp |
|
||||
| new | /?fi=le&%#2 . txt |
|
||||
| new | /# %ab ab?=ed |
|
||||
|
||||
@personalSpace
|
||||
Examples:
|
||||
| dav_version | file_name |
|
||||
| spaces | /upload.txt |
|
||||
| spaces | /strängé file.txt |
|
||||
| spaces | /नेपाली.txt |
|
||||
| spaces | /s,a,m,p,l,e.txt |
|
||||
| spaces | /C++ file.cpp |
|
||||
| spaces | /?fi=le&%#2 . txt |
|
||||
| spaces | /# %ab ab?=ed |
|
||||
|
||||
|
||||
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 TUS protocol on the WebDAV API
|
||||
Then 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 |
|
||||
| old | /folder ?2.txt | file ?2.txt |
|
||||
| old | /?fi=le&%#2 . txt | # %ab ab?=ed |
|
||||
| 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 |
|
||||
| new | /folder ?2.txt | file ?2.txt |
|
||||
| new | /?fi=le&%#2 . txt | # %ab ab?=ed |
|
||||
|
||||
@personalSpace
|
||||
Examples:
|
||||
| dav_version | folder_name | file_name |
|
||||
| spaces | /upload | abc.txt |
|
||||
| spaces | /strängé folder (duplicate #2 &) | strängé file (duplicate #2 &) |
|
||||
| spaces | /C++ folder | C++ file.cpp |
|
||||
| spaces | /नेपाली | नेपाली |
|
||||
| spaces | /folder #2.txt | file #2.txt |
|
||||
| spaces | /folder ?2.txt | file ?2.txt |
|
||||
| spaces | /?fi=le&%#2 . txt | # %ab ab?=ed |
|
||||
|
||||
|
||||
Scenario Outline: Upload chunked file with TUS
|
||||
Given using <dav_version> DAV path
|
||||
When user "Alice" uploads file with content "uploaded content" in 3 chunks to "/myChunkedFile.txt" using the TUS protocol on the WebDAV API
|
||||
Then the content of file "/myChunkedFile.txt" for user "Alice" should be "uploaded content"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
@personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
|
||||
|
||||
Scenario Outline: Upload 1 byte chunks with TUS
|
||||
Given using <dav_version> DAV path
|
||||
When user "Alice" uploads file with content "0123456789" in 10 chunks to "/myChunkedFile.txt" using the TUS protocol on the WebDAV API
|
||||
Then the content of file "/myChunkedFile.txt" for user "Alice" should be "0123456789"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
@personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
|
||||
|
||||
Scenario Outline: Upload to overwriting a file
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has uploaded file with content "original content" to "textfile.txt"
|
||||
When user "Alice" uploads file with content "overwritten content" to "textfile.txt" using the TUS protocol on the WebDAV API
|
||||
Then the content of file "textfile.txt" for user "Alice" should be "overwritten content"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
@personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
|
||||
|
||||
Scenario Outline: upload a file and no version is available
|
||||
Given using <dav_version> DAV path
|
||||
When user "Alice" uploads file with content "uploaded content" to "/upload.txt" using the TUS protocol on the WebDAV API
|
||||
Then the version folder of file "/upload.txt" for user "Alice" should contain "0" elements
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
@personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
|
||||
|
||||
Scenario Outline: upload a file twice and versions are available
|
||||
Given using <dav_version> DAV path
|
||||
When user "Alice" uploads file with content "uploaded content" to "/upload.txt" using the TUS protocol on the WebDAV API
|
||||
And user "Alice" uploads file with content "re-uploaded content" to "/upload.txt" using the TUS protocol on the WebDAV API
|
||||
Then the version folder of file "/upload.txt" for user "Alice" should contain "1" element
|
||||
And the content of file "/upload.txt" for user "Alice" should be "re-uploaded content"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
@personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
|
||||
|
||||
Scenario Outline: upload a file in chunks with TUS and no version is available
|
||||
Given using <dav_version> DAV path
|
||||
When user "Alice" uploads file with content "0123456789" in 10 chunks to "/myChunkedFile.txt" using the TUS protocol on the WebDAV API
|
||||
Then the version folder of file "/myChunkedFile.txt" for user "Alice" should contain "0" elements
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
|
||||
Scenario Outline: upload a twice file in chunks with TUS and versions are available
|
||||
Given using <dav_version> DAV path
|
||||
When user "Alice" uploads file with content "0123456789" in 10 chunks to "/myChunkedFile.txt" using the TUS protocol on the WebDAV API
|
||||
And user "Alice" uploads file with content "01234" in 5 chunks to "/myChunkedFile.txt" using the TUS protocol on the WebDAV API
|
||||
Then the version folder of file "/myChunkedFile.txt" for user "Alice" should contain "1" elements
|
||||
And the content of file "/myChunkedFile.txt" for user "Alice" should be "01234"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
@personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
|
||||
|
||||
Scenario Outline: upload a file with invalid-name
|
||||
Given using <dav_version> DAV path
|
||||
When user "Alice" creates a new TUS resource on the WebDAV API with these headers:
|
||||
| Upload-Length | 100 |
|
||||
| Upload-Metadata | filename <metadata> |
|
||||
| Tus-Resumable | 1.0.0 |
|
||||
Then the HTTP status code should be "412"
|
||||
And the following headers should not be set
|
||||
| header |
|
||||
| Location |
|
||||
And as "Alice" file <file_name> should not exist
|
||||
Examples:
|
||||
| dav_version | file_name | metadata |
|
||||
| old | " " | IA== |
|
||||
| old | "filewithLF-and-CR\r\n" | ZmlsZXdpdGhMRi1hbmQtQ1INCgo= |
|
||||
| old | "folder/file" | Zm9sZGVyL2ZpbGU= |
|
||||
| old | "my\\file" | bXkMaWxl |
|
||||
| new | " " | IA== |
|
||||
| new | "filewithLF-and-CR\r\n" | ZmlsZXdpdGhMRi1hbmQtQ1INCgo= |
|
||||
| new | "folder/file" | Zm9sZGVyL2ZpbGU= |
|
||||
| new | "my\\file" | bXkMaWxl |
|
||||
|
||||
@personalSpace
|
||||
Examples:
|
||||
| dav_version | file_name | metadata |
|
||||
| spaces | " " | IA== |
|
||||
| spaces | "filewithLF-and-CR\r\n" | ZmlsZXdpdGhMRi1hbmQtQ1INCgo= |
|
||||
| spaces | "folder/file" | Zm9sZGVyL2ZpbGU= |
|
||||
| spaces | "my\\file" | bXkMaWxl |
|
||||
@@ -0,0 +1,70 @@
|
||||
@api @skipOnOcV10
|
||||
Feature: upload file
|
||||
As a user
|
||||
I want the mtime of an uploaded file to be the creation date on upload source not the upload date
|
||||
So that I can find files by their real creation date
|
||||
|
||||
Background:
|
||||
Given user "Alice" has been created with default attributes and without skeleton files
|
||||
|
||||
|
||||
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 TUS protocol on the WebDAV API
|
||||
Then as "Alice" the mtime of the file "file.txt" should be "Thu, 08 Aug 2019 04:18:13 GMT"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
@personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
|
||||
|
||||
Scenario Outline: upload file with future mtime
|
||||
Given using <dav_version> DAV path
|
||||
When user "Alice" uploads file "filesForUpload/textfile.txt" to "file.txt" with mtime "Thu, 08 Aug 2129 04:18:13 GMT" using the TUS protocol on the WebDAV API
|
||||
Then as "Alice" the mtime of the file "file.txt" should be "Thu, 08 Aug 2129 04:18:13 GMT"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
@personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
|
||||
|
||||
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 TUS protocol on the WebDAV API
|
||||
Then 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 |
|
||||
|
||||
@personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
|
||||
|
||||
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 file "filesForUpload/textfile.txt" to "file.txt" with mtime "Thu, 08 Aug 2019 04:18:13 GMT" using the TUS protocol on the WebDAV API
|
||||
Then as "Alice" the mtime of the file "file.txt" should be "Thu, 08 Aug 2019 04:18:13 GMT"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
@personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
@@ -0,0 +1,71 @@
|
||||
@api @files_sharing-app-required @skipOnOcV10
|
||||
Feature: upload file
|
||||
As a user
|
||||
I want the mtime of an uploaded file to be the creation date on upload source not the upload date
|
||||
So that I can find files by their real creation date
|
||||
|
||||
Background:
|
||||
Given the administrator has set the default folder for received shares to "Shares"
|
||||
And auto-accept shares has been disabled
|
||||
And these users have been created with default attributes and without skeleton files:
|
||||
| username |
|
||||
| Alice |
|
||||
| Brian |
|
||||
|
||||
|
||||
Scenario Outline: upload file with mtime to a received share
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has created folder "/toShare"
|
||||
And user "Alice" has shared folder "/toShare" with user "Brian"
|
||||
And user "Brian" has accepted share "/toShare" offered by user "Alice"
|
||||
When user "Brian" uploads file "filesForUpload/textfile.txt" to "/Shares/toShare/file.txt" with mtime "Thu, 08 Aug 2012 04:18:13 GMT" using the TUS protocol on the WebDAV API
|
||||
Then as "Alice" the mtime of the file "/toShare/file.txt" should be "Thu, 08 Aug 2012 04:18:13 GMT"
|
||||
And as "Brian" the mtime of the file "/Shares/toShare/file.txt" should be "Thu, 08 Aug 2012 04:18:13 GMT"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
|
||||
Scenario Outline: upload file with mtime to a send share
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has created folder "/toShare"
|
||||
And user "Alice" has shared folder "/toShare" with user "Brian"
|
||||
And user "Brian" has accepted share "/toShare" offered by user "Alice"
|
||||
When user "Alice" uploads file "filesForUpload/textfile.txt" to "/toShare/file.txt" with mtime "Thu, 08 Aug 2012 04:18:13 GMT" using the TUS protocol on the WebDAV API
|
||||
Then as "Alice" the mtime of the file "/toShare/file.txt" should be "Thu, 08 Aug 2012 04:18:13 GMT"
|
||||
And as "Brian" the mtime of the file "/Shares/toShare/file.txt" should be "Thu, 08 Aug 2012 04:18:13 GMT"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
|
||||
Scenario Outline: overwriting a file with mtime in a received share
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has created folder "/toShare"
|
||||
And user "Alice" has shared folder "/toShare" with user "Brian"
|
||||
And user "Brian" has accepted share "/toShare" offered by user "Alice"
|
||||
And user "Alice" has uploaded file with content "uploaded content" to "/toShare/file.txt"
|
||||
When user "Brian" uploads file "filesForUpload/textfile.txt" to "/Shares/toShare/file.txt" with mtime "Thu, 08 Aug 2012 04:18:13 GMT" using the TUS protocol on the WebDAV API
|
||||
Then as "Alice" the mtime of the file "/toShare/file.txt" should be "Thu, 08 Aug 2012 04:18:13 GMT"
|
||||
And as "Brian" the mtime of the file "/Shares/toShare/file.txt" should be "Thu, 08 Aug 2012 04:18:13 GMT"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
|
||||
Scenario Outline: overwriting a file with mtime in a send share
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has created folder "/toShare"
|
||||
And user "Alice" has shared folder "/toShare" with user "Brian"
|
||||
And user "Brian" has accepted share "/toShare" offered by user "Alice"
|
||||
And user "Brian" has uploaded file with content "uploaded content" to "/Shares/toShare/file.txt"
|
||||
When user "Alice" uploads file "filesForUpload/textfile.txt" to "/toShare/file.txt" with mtime "Thu, 08 Aug 2012 04:18:13 GMT" using the TUS protocol on the WebDAV API
|
||||
Then as "Alice" the mtime of the file "/toShare/file.txt" should be "Thu, 08 Aug 2012 04:18:13 GMT"
|
||||
And as "Brian" the mtime of the file "/Shares/toShare/file.txt" should be "Thu, 08 Aug 2012 04:18:13 GMT"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
@@ -0,0 +1,28 @@
|
||||
@api @skipOnOcV10
|
||||
Feature: move folders
|
||||
As a user
|
||||
I want to be able to move and upload files/folders
|
||||
So that I can organise my data structure
|
||||
|
||||
Background:
|
||||
Given user "Alice" has been created with default attributes and without skeleton files
|
||||
|
||||
|
||||
Scenario Outline: Uploading file into a moved folder
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has created folder "/test"
|
||||
And user "Alice" has created folder "/test-moved"
|
||||
And user "Alice" has moved folder "/test-moved" to "/test/test-moved"
|
||||
When user "Alice" uploads file with content "uploaded content" to "/test/test-moved/textfile.txt" using the TUS protocol on the WebDAV API
|
||||
Then as "Alice" file "/test/test-moved/textfile.txt" should exist
|
||||
And the content of file "/test/test-moved/textfile.txt" for user "Alice" should be "uploaded content"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
@personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
|
||||
@@ -0,0 +1,67 @@
|
||||
@api @skipOnOcV10
|
||||
Feature: upload file
|
||||
As a user
|
||||
I want to try uploading files to a nonexistent folder
|
||||
So that I can check if the uploading works in such case
|
||||
|
||||
Background:
|
||||
Given using OCS API version "1"
|
||||
And the administrator has set the default folder for received shares to "Shares"
|
||||
And user "Alice" has been created with default attributes and without skeleton files
|
||||
|
||||
|
||||
Scenario Outline: attempt to upload a file into a nonexistent folder inside shares
|
||||
Given using <dav_version> DAV path
|
||||
When user "Alice" uploads file with content "uploaded content" to "/Shares/FOLDER/textfile.txt" using the TUS protocol on the WebDAV API
|
||||
Then as "Alice" folder "/Shares/FOLDER/" should not exist
|
||||
And as "Alice" file "/Shares/FOLDER/textfile.txt" should not exist
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
|
||||
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 "/nonExistentFolder/textfile.txt" using the TUS protocol on the WebDAV API
|
||||
Then as "Alice" folder "/nonExistentFolder" should not exist
|
||||
And as "Alice" file "/nonExistentFolder/textfile.txt" should not exist
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
@personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
|
||||
|
||||
Scenario Outline: attempt to upload a file into a nonexistent folder within correctly received share
|
||||
Given using <dav_version> DAV path
|
||||
And user "Brian" has been created with default attributes and without skeleton files
|
||||
And user "Alice" has created folder "/FOLDER"
|
||||
And user "Alice" has shared folder "/FOLDER" with user "Brian"
|
||||
And user "Brian" has accepted share "/FOLDER" offered by user "Alice"
|
||||
When user "Brian" uploads file with content "uploaded content" to "/Shares/FOLDER/nonExistentFolder/textfile.txt" using the TUS protocol on the WebDAV API
|
||||
Then as "Brian" folder "/Shares/FOLDER/nonExistentFolder" should not exist
|
||||
And as "Brian" file "/Shares/FOLDER/nonExistentFolder/textfile.txt" should not exist
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
|
||||
Scenario Outline: attempt to upload a file into a nonexistent folder within correctly received read only share
|
||||
Given using <dav_version> DAV path
|
||||
And user "Brian" has been created with default attributes and without skeleton files
|
||||
And user "Alice" has created folder "/FOLDER"
|
||||
And user "Alice" has shared folder "/FOLDER" with user "Brian" with permissions "read"
|
||||
And user "Brian" has accepted share "/FOLDER" offered by user "Alice"
|
||||
When user "Brian" uploads file with content "uploaded content" to "/Shares/FOLDER/nonExistentFolder/textfile.txt" using the TUS protocol on the WebDAV API
|
||||
Then as "Brian" folder "/Shares/FOLDER/nonExistentFolder" should not exist
|
||||
And as "Brian" file "/Shares/FOLDER/nonExistentFolder/textfile.txt" should not exist
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
@@ -0,0 +1,296 @@
|
||||
@api @files_sharing-app-required @skipOnOcV10
|
||||
|
||||
Feature: upload file to shared folder
|
||||
|
||||
Background:
|
||||
Given the administrator has set the default folder for received shares to "Shares"
|
||||
And auto-accept shares has been disabled
|
||||
And these users have been created with default attributes and without skeleton files:
|
||||
| username |
|
||||
| Alice |
|
||||
| Brian |
|
||||
|
||||
|
||||
Scenario Outline: Uploading file to a received share folder
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has created folder "/FOLDER"
|
||||
And user "Alice" has shared folder "/FOLDER" with user "Brian"
|
||||
And user "Brian" has accepted share "/FOLDER" offered by user "Alice"
|
||||
When user "Brian" uploads file with content "uploaded content" to "/Shares/FOLDER/textfile.txt" using the TUS protocol on the WebDAV API
|
||||
Then as "Alice" file "/FOLDER/textfile.txt" should exist
|
||||
And the content of file "/FOLDER/textfile.txt" for user "Alice" should be "uploaded content"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
|
||||
Scenario Outline: Uploading file to a user read/write share folder works
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has created folder "/FOLDER"
|
||||
And user "Alice" has shared folder "/FOLDER" with user "Brian" with permissions "change"
|
||||
And user "Brian" has accepted share "/FOLDER" offered by user "Alice"
|
||||
When user "Brian" uploads file with content "uploaded content" to "/Shares/FOLDER/textfile.txt" using the TUS protocol on the WebDAV API
|
||||
Then as "Alice" file "/FOLDER/textfile.txt" should exist
|
||||
And the content of file "/FOLDER/textfile.txt" for user "Alice" should be "uploaded content"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
|
||||
Scenario Outline: Uploading a file into a group share as share receiver
|
||||
Given using <dav_version> DAV path
|
||||
And group "grp1" has been created
|
||||
And user "Brian" has been added to group "grp1"
|
||||
And user "Alice" has created folder "/FOLDER"
|
||||
And user "Alice" has shared folder "FOLDER" with group "grp1" with permissions "change"
|
||||
And user "Brian" has accepted share "/FOLDER" offered by user "Alice"
|
||||
When user "Brian" uploads file with content "uploaded content" to "/Shares/FOLDER/textfile.txt" using the TUS protocol on the WebDAV API
|
||||
Then as "Alice" file "/FOLDER/textfile.txt" should exist
|
||||
And the content of file "/FOLDER/textfile.txt" for user "Alice" should be "uploaded content"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
|
||||
Scenario Outline: Overwrite file to a received share folder
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has created folder "/FOLDER"
|
||||
And user "Alice" has uploaded file with content "original content" to "/FOLDER/textfile.txt"
|
||||
And user "Alice" has shared folder "/FOLDER" with user "Brian"
|
||||
And user "Brian" has accepted share "/FOLDER" offered by user "Alice"
|
||||
When user "Brian" uploads file with content "overwritten content" to "/Shares/FOLDER/textfile.txt" using the TUS protocol on the WebDAV API
|
||||
Then as "Alice" file "/FOLDER/textfile.txt" should exist
|
||||
And the content of file "/FOLDER/textfile.txt" for user "Alice" should be "overwritten content"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
|
||||
Scenario Outline: attempt to upload a file into a folder within correctly received read only share
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has created folder "/FOLDER"
|
||||
And user "Alice" has shared folder "/FOLDER" with user "Brian" with permissions "read"
|
||||
And user "Brian" has accepted share "/FOLDER" offered by user "Alice"
|
||||
When user "Brian" uploads file with content "uploaded content" to "/Shares/FOLDER/textfile.txt" using the TUS protocol on the WebDAV API
|
||||
Then as "Brian" file "/Shares/FOLDER/textfile.txt" should not exist
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
|
||||
Scenario Outline: Upload a file to shared folder with checksum should return the checksum in the propfind for sharee
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has created folder "/FOLDER"
|
||||
And user "Alice" has shared folder "/FOLDER" with user "Brian"
|
||||
And user "Brian" has accepted share "/FOLDER" offered by user "Alice"
|
||||
And user "Alice" has created a new TUS resource on the WebDAV API with these headers:
|
||||
| Upload-Length | 5 |
|
||||
# L0ZPTERFUi90ZXh0RmlsZS50eHQ= is the base64 encode of /FOLDER/textFile.txt
|
||||
| Upload-Metadata | filename L0ZPTERFUi90ZXh0RmlsZS50eHQ= |
|
||||
And user "Alice" has uploaded file with checksum "SHA1 8cb2237d0679ca88db6464eac60da96345513964" to the last created TUS Location with offset "0" and content "12345" using the TUS protocol on the WebDAV API
|
||||
When user "Brian" requests the checksum of "/Shares/FOLDER/textFile.txt" via propfind
|
||||
Then the HTTP status code should be "207"
|
||||
And the webdav checksum should match "SHA1:8cb2237d0679ca88db6464eac60da96345513964 MD5:827ccb0eea8a706c4c34a16891f84e7b ADLER32:02f80100"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
|
||||
Scenario Outline: Upload a file to shared folder with checksum should return the checksum in the download header for sharee
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has created folder "/FOLDER"
|
||||
And user "Alice" has shared folder "/FOLDER" with user "Brian"
|
||||
And user "Brian" has accepted share "/FOLDER" offered by user "Alice"
|
||||
And user "Alice" has created a new TUS resource on the WebDAV API with these headers:
|
||||
| Upload-Length | 5 |
|
||||
# L0ZPTERFUi90ZXh0RmlsZS50eHQ= is the base64 encode of /FOLDER/textFile.txt
|
||||
| Upload-Metadata | filename L0ZPTERFUi90ZXh0RmlsZS50eHQ= |
|
||||
And user "Alice" has uploaded file with checksum "SHA1 8cb2237d069ca88db6464eac60da96345513964" to the last created TUS Location with offset "0" and content "12345" using the TUS protocol on the WebDAV API
|
||||
When user "Brian" downloads file "/Shares/FOLDER/textFile.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "200"
|
||||
And the header checksum should match "SHA1:8cb2237d0679ca88db6464eac60da96345513964"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
|
||||
Scenario Outline: Sharer shares a file with correct checksum should return the checksum in the propfind for sharee
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has created a new TUS resource on the WebDAV API with these headers:
|
||||
| Upload-Length | 5 |
|
||||
# dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt
|
||||
| Upload-Metadata | filename dGV4dEZpbGUudHh0 |
|
||||
And user "Alice" has uploaded file with checksum "SHA1 8cb2237d0679ca88db6464eac60da96345513964" to the last created TUS Location with offset "0" and content "12345" using the TUS protocol on the WebDAV API
|
||||
And user "Alice" has shared file "/textFile.txt" with user "Brian"
|
||||
And user "Brian" has accepted share "/textFile.txt" offered by user "Alice"
|
||||
When user "Brian" requests the checksum of "/Shares/textFile.txt" via propfind
|
||||
Then the HTTP status code should be "207"
|
||||
And the webdav checksum should match "SHA1:8cb2237d0679ca88db6464eac60da96345513964 MD5:827ccb0eea8a706c4c34a16891f84e7b ADLER32:02f80100"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
|
||||
Scenario Outline: Sharer shares a file with correct checksum should return the checksum in the download header for sharee
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has created a new TUS resource on the WebDAV API with these headers:
|
||||
| Upload-Length | 5 |
|
||||
# dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt
|
||||
| Upload-Metadata | filename dGV4dEZpbGUudHh0 |
|
||||
And user "Alice" has uploaded file with checksum "SHA1 8cb2237d0679ca88db6464eac60da96345513964" to the last created TUS Location with offset "0" and content "12345" using the TUS protocol on the WebDAV API
|
||||
And user "Alice" has shared file "/textFile.txt" with user "Brian"
|
||||
And user "Brian" has accepted share "/textFile.txt" offered by user "Alice"
|
||||
When user "Brian" downloads file "/Shares/textFile.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "200"
|
||||
And the header checksum should match "SHA1:8cb2237d0679ca88db6464eac60da96345513964"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
|
||||
Scenario Outline: Sharee uploads a file to a received share folder with correct checksum
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has created folder "/FOLDER"
|
||||
And user "Alice" has shared folder "/FOLDER" with user "Brian"
|
||||
And user "Brian" has accepted share "/FOLDER" offered by user "Alice"
|
||||
When user "Brian" creates a new TUS resource on the WebDAV API with these headers:
|
||||
| Tus-Resumable | 1.0.0 |
|
||||
| Upload-Length | 16 |
|
||||
# L1NoYXJlcy9GT0xERVIvdGV4dGZpbGUudHh0 is the base64 encode of /Shares/FOLDER/textFile.txt
|
||||
| Upload-Metadata | filename L1NoYXJlcy9GT0xERVIvdGV4dGZpbGUudHh0 |
|
||||
And user "Brian" uploads file with checksum "MD5 827ccb0eea8a706c4c34a16891f84e7b" to the last created TUS Location with offset "0" and content "uploaded content" using the TUS protocol on the WebDAV API
|
||||
Then the HTTP status code should be "204"
|
||||
And as "Alice" file "/FOLDER/textFile.txt" should exist
|
||||
And the content of file "/FOLDER/textFile.txt" for user "Alice" should be "uploaded content"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
|
||||
Scenario Outline: Sharee uploads a file to a received share folder with wrong checksum should not work
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has created folder "/FOLDER"
|
||||
And user "Alice" has shared folder "/FOLDER" with user "Brian"
|
||||
And user "Brian" has accepted share "/FOLDER" offered by user "Alice"
|
||||
When user "Brian" creates a new TUS resource on the WebDAV API with these headers:
|
||||
| Tus-Resumable | 1.0.0 |
|
||||
| Upload-Length | 16 |
|
||||
# L1NoYXJlcy9GT0xERVIvdGV4dGZpbGUudHh0 is the base64 encode of /Shares/FOLDER/textFile.txt
|
||||
| Upload-Metadata | filename L1NoYXJlcy9GT0xERVIvdGV4dGZpbGUudHh0 |
|
||||
And user "Brian" uploads file with checksum "MD5 827ccb0eea8a706c4c34a16891f84e8c" to the last created TUS Location with offset "0" and content "uploaded content" using the TUS protocol on the WebDAV API
|
||||
Then the HTTP status code should be "406"
|
||||
And as "Alice" file "/FOLDER/textFile.txt" should not exist
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
|
||||
Scenario Outline: Sharer uploads a file to shared folder with wrong correct checksum should not work
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has created folder "/FOLDER"
|
||||
And user "Alice" has shared folder "/FOLDER" with user "Brian"
|
||||
And user "Brian" has accepted share "/FOLDER" offered by user "Alice"
|
||||
And user "Alice" has created a new TUS resource on the WebDAV API with these headers:
|
||||
| Upload-Length | 5 |
|
||||
# L0ZPTERFUi90ZXh0RmlsZS50eHQ= is the base64 encode of /FOLDER/textFile.txt
|
||||
| Upload-Metadata | filename L0ZPTERFUi90ZXh0RmlsZS50eHQ= |
|
||||
When user "Alice" uploads file with checksum "SHA1 8cb2237d0679ca88db6464eac60da96345513954" to the last created TUS Location with offset "0" and content "uploaded content" using the TUS protocol on the WebDAV API
|
||||
Then the HTTP status code should be "406"
|
||||
And as "Alice" file "/FOLDER/textFile.txt" should not exist
|
||||
And as "Brian" file "/Shares/FOLDER/textFile.txt" should not exist
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
|
||||
Scenario Outline: Sharer uploads a chunked file with correct checksum and share it with sharee should work
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has created a new TUS resource on the WebDAV API with these headers:
|
||||
| Upload-Length | 10 |
|
||||
# dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt
|
||||
| Upload-Metadata | filename dGV4dEZpbGUudHh0 |
|
||||
When user "Alice" sends a chunk to the last created TUS Location with offset "0" and data "01234" with checksum "MD5 4100c4d44da9177247e44a5fc1546778" using the TUS protocol on the WebDAV API
|
||||
And user "Alice" sends a chunk to the last created TUS Location with offset "5" and data "56789" with checksum "MD5 099ebea48ea9666a7da2177267983138" using the TUS protocol on the WebDAV API
|
||||
And user "Alice" shares file "textFile.txt" with user "Brian" using the sharing API
|
||||
And user "Brian" accepts share "/textFile.txt" offered by user "Alice" using the sharing API
|
||||
Then the HTTP status code should be "200"
|
||||
And the content of file "/Shares/textFile.txt" for user "Brian" should be "0123456789"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
|
||||
Scenario Outline: Sharee uploads a chunked file with correct checksum to a received share folder should work
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has created folder "/FOLDER"
|
||||
And user "Alice" has shared folder "/FOLDER" with user "Brian"
|
||||
And user "Brian" has accepted share "/FOLDER" offered by user "Alice"
|
||||
And user "Brian" creates a new TUS resource on the WebDAV API with these headers:
|
||||
| Tus-Resumable | 1.0.0 |
|
||||
| Upload-Length | 10 |
|
||||
# L1NoYXJlcy9GT0xERVIvdGV4dGZpbGUudHh0 is the base64 encode of /Shares/FOLDER/textFile.txt
|
||||
| Upload-Metadata | filename L1NoYXJlcy9GT0xERVIvdGV4dGZpbGUudHh0 |
|
||||
When user "Brian" sends a chunk to the last created TUS Location with offset "0" and data "01234" with checksum "MD5 4100c4d44da9177247e44a5fc1546778" using the TUS protocol on the WebDAV API
|
||||
And user "Brian" sends a chunk to the last created TUS Location with offset "5" and data "56789" with checksum "MD5 099ebea48ea9666a7da2177267983138" using the TUS protocol on the WebDAV API
|
||||
Then the HTTP status code should be "204"
|
||||
And as "Alice" file "/FOLDER/textFile.txt" should exist
|
||||
And the content of file "/FOLDER/textFile.txt" for user "Alice" should be "0123456789"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
|
||||
Scenario Outline: Sharer uploads a file with checksum and as a sharee overwrites the shared file with new data and correct checksum
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has created a new TUS resource on the WebDAV API with these headers:
|
||||
| Upload-Length | 16 |
|
||||
# dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt
|
||||
| Upload-Metadata | filename dGV4dEZpbGUudHh0 |
|
||||
And user "Alice" has uploaded file with checksum "SHA1 c1dab0c0864b6ac9bdd3743a1408d679f1acd823" to the last created TUS Location with offset "0" and content "original content" using the TUS protocol on the WebDAV API
|
||||
And user "Alice" has shared file "/textFile.txt" with user "Brian"
|
||||
And user "Brian" has accepted share "/textFile.txt" offered by user "Alice"
|
||||
When user "Brian" overwrites recently shared file with offset "0" and data "overwritten content" with checksum "SHA1 fe990d2686a0fc86004efc31f5bf2475a45d4905" using the TUS protocol on the WebDAV API with these headers:
|
||||
| Upload-Length | 19 |
|
||||
# dGV4dEZpbGUudHh0 is the base64 encode of /Shares/textFile.txt
|
||||
| Upload-Metadata | filename L1NoYXJlcy90ZXh0RmlsZS50eHQ= |
|
||||
Then the HTTP status code should be "204"
|
||||
And the content of file "/textFile.txt" for user "Alice" should be "overwritten content"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
|
||||
Scenario Outline: Sharer uploads a file with checksum and as a sharee overwrites the shared file with new data and invalid checksum
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has created a new TUS resource on the WebDAV API with these headers:
|
||||
| Upload-Length | 16 |
|
||||
# dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt
|
||||
| Upload-Metadata | filename dGV4dEZpbGUudHh0 |
|
||||
And user "Alice" has uploaded file with checksum "SHA1 c1dab0c0864b6ac9bdd3743a1408d679f1acd823" to the last created TUS Location with offset "0" and content "original content" using the TUS protocol on the WebDAV API
|
||||
And user "Alice" has shared file "/textFile.txt" with user "Brian"
|
||||
And user "Brian" has accepted share "/textFile.txt" offered by user "Alice"
|
||||
When user "Brian" overwrites recently shared file with offset "0" and data "overwritten content" with checksum "SHA1 fe990d2686a0fc86004efc31f5bf2475a45d4906" using the TUS protocol on the WebDAV API with these headers:
|
||||
| Upload-Length | 19 |
|
||||
# dGV4dEZpbGUudHh0 is the base64 encode of /Shares/textFile.txt
|
||||
| Upload-Metadata | filename L1NoYXJlcy90ZXh0RmlsZS50eHQ= |
|
||||
Then the HTTP status code should be "406"
|
||||
And the content of file "/textFile.txt" for user "Alice" should be "original content"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
Reference in New Issue
Block a user