diff --git a/tests/acceptance/expected-failures-API-on-OCIS-storage.md b/tests/acceptance/expected-failures-API-on-OCIS-storage.md index 0d133ea7a7b..a9e687d7915 100644 --- a/tests/acceptance/expected-failures-API-on-OCIS-storage.md +++ b/tests/acceptance/expected-failures-API-on-OCIS-storage.md @@ -124,32 +124,21 @@ _ocdav: api compatibility, return correct status code_ - [coreApiWebdavUploadTUS/checksums.feature:193](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/checksums.feature#L193) - [coreApiWebdavUploadTUS/checksums.feature:194](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/checksums.feature#L194) - [coreApiWebdavUploadTUS/checksums.feature:195](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/checksums.feature#L195) -- [coreApiWebdavUploadTUS/checksums.feature:197](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/checksums.feature#L197) - [coreApiWebdavUploadTUS/checksums.feature:196](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/checksums.feature#L196) +- [coreApiWebdavUploadTUS/checksums.feature:197](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/checksums.feature#L197) - [coreApiWebdavUploadTUS/checksums.feature:240](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/checksums.feature#L240) - [coreApiWebdavUploadTUS/checksums.feature:241](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/checksums.feature#L241) - [coreApiWebdavUploadTUS/checksums.feature:242](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/checksums.feature#L242) - [coreApiWebdavUploadTUS/checksums.feature:243](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/checksums.feature#L243) -- [coreApiWebdavUploadTUS/checksums.feature:245](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/checksums.feature#L245) - [coreApiWebdavUploadTUS/checksums.feature:244](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/checksums.feature#L244) -- [coreApiWebdavUploadTUS/optionsRequest.feature:10](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/optionsRequest.feature#L10) -- [coreApiWebdavUploadTUS/optionsRequest.feature:25](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/optionsRequest.feature#L25) -- [coreApiWebdavUploadTUS/uploadToShare.feature:226](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature#L226) -- [coreApiWebdavUploadTUS/uploadToShare.feature:227](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature#L227) +- [coreApiWebdavUploadTUS/checksums.feature:245](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/checksums.feature#L245) - [coreApiWebdavUploadTUS/uploadToShare.feature:250](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature#L250) - [coreApiWebdavUploadTUS/uploadToShare.feature:251](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature#L251) - [coreApiWebdavUploadTUS/uploadToShare.feature:274](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature#L274) - [coreApiWebdavUploadTUS/uploadToShare.feature:275](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature#L275) -- [coreApiWebdavUploadTUS/uploadToShare.feature:317](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature#L317) -- [coreApiWebdavUploadTUS/uploadToShare.feature:318](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature#L318) - [coreApiWebdavUploadTUS/uploadToShare.feature:369](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature#L369) - [coreApiWebdavUploadTUS/uploadToShare.feature:370](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature#L370) -#### [TUS OPTIONS requests do not reply with TUS headers when invalid password](https://github.com/owncloud/ocis/issues/1012) - -- [coreApiWebdavUploadTUS/optionsRequest.feature:40](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/optionsRequest.feature#L40) -- [coreApiWebdavUploadTUS/optionsRequest.feature:55](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/optionsRequest.feature#L55) - #### [Renaming resource to banned name is allowed in spaces webdav](https://github.com/owncloud/ocis/issues/3099) - [coreApiWebdavMove2/moveFile.feature:143](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavMove2/moveFile.feature#L143) diff --git a/tests/acceptance/expected-failures-localAPI-on-OCIS-storage.md b/tests/acceptance/expected-failures-localAPI-on-OCIS-storage.md index 53b15568a51..71d9e378441 100644 --- a/tests/acceptance/expected-failures-localAPI-on-OCIS-storage.md +++ b/tests/acceptance/expected-failures-localAPI-on-OCIS-storage.md @@ -124,7 +124,7 @@ The expected failures in this file are from features in the owncloud/ocis repo. - [apiLocks/unlockFiles.feature:231](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiLocks/unlockFiles.feature#L231) - [apiLocks/unlockFiles.feature:232](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiLocks/unlockFiles.feature#L232) -#### [Trying to upload to a locked file gives 500](https://github.com/owncloud/ocis/issues/7638) +#### [Folders can be locked and locking works partially](https://github.com/owncloud/ocis/issues/7641) - [apiLocks/lockFiles.feature:445](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiLocks/lockFiles.feature#L445) - [apiLocks/lockFiles.feature:446](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiLocks/lockFiles.feature#L446) @@ -132,9 +132,6 @@ The expected failures in this file are from features in the owncloud/ocis repo. - [apiLocks/lockFiles.feature:448](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiLocks/lockFiles.feature#L448) - [apiLocks/lockFiles.feature:449](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiLocks/lockFiles.feature#L449) - [apiLocks/lockFiles.feature:450](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiLocks/lockFiles.feature#L450) - -#### [Folders can be locked and locking works partially](https://github.com/owncloud/ocis/issues/7641) - - [apiLocks/lockFiles.feature:419](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiLocks/lockFiles.feature#L419) - [apiLocks/lockFiles.feature:420](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiLocks/lockFiles.feature#L420) - [apiLocks/lockFiles.feature:421](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiLocks/lockFiles.feature#L421) @@ -248,12 +245,12 @@ The expected failures in this file are from features in the owncloud/ocis repo. - [apiSpacesShares/moveSpaces.feature:416](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesShares/moveSpaces.feature#L416) - [apiSpacesDavOperation/moveByFileId.feature:86](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesDavOperation/moveByFileId.feature#L86) - [apiSpacesDavOperation/moveByFileId.feature:87](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesDavOperation/moveByFileId.feature#L87) -- [apiSpacesDavOperation/moveByFileId.feature:210](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesDavOperation/moveByFileId.feature#L210) - [apiSpacesDavOperation/moveByFileId.feature:205](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesDavOperation/moveByFileId.feature#L205) - [apiSpacesDavOperation/moveByFileId.feature:206](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesDavOperation/moveByFileId.feature#L206) - [apiSpacesDavOperation/moveByFileId.feature:207](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesDavOperation/moveByFileId.feature#L207) - [apiSpacesDavOperation/moveByFileId.feature:208](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesDavOperation/moveByFileId.feature#L208) - [apiSpacesDavOperation/moveByFileId.feature:209](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesDavOperation/moveByFileId.feature#L209) +- [apiSpacesDavOperation/moveByFileId.feature:210](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesDavOperation/moveByFileId.feature#L210) - [apiSpacesDavOperation/moveByFileId.feature:492](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesDavOperation/moveByFileId.feature#L492) - [apiSpacesDavOperation/moveByFileId.feature:493](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesDavOperation/moveByFileId.feature#L493) diff --git a/tests/acceptance/features/apiLocks/lockFiles.feature b/tests/acceptance/features/apiLocks/lockFiles.feature index 23ef1167dc6..dcb1bab4e93 100644 --- a/tests/acceptance/features/apiLocks/lockFiles.feature +++ b/tests/acceptance/features/apiLocks/lockFiles.feature @@ -163,7 +163,7 @@ Feature: lock files | lockscope | exclusive | Then the HTTP status code should be "403" - + @issue-7599 Scenario Outline: lock a file in the shares Given using DAV path And user "Alice" has uploaded a file inside space "Alice Hansen" with content "some content" to "textfile.txt" @@ -518,7 +518,7 @@ Feature: lock files | spaces | shared | | spaces | exclusive | - + @issue-7790 Scenario Outline: lock a file shared by a link as anonymous user with edit permission Given using DAV path And using SharingNG @@ -542,7 +542,7 @@ Feature: lock files | spaces | shared | | spaces | exclusive | - + @issue-7790 Scenario Outline: try to lock a file shared by a link as anonymous user with read permission Given using DAV path And using SharingNG diff --git a/tests/acceptance/features/apiLocks/unlockFiles.feature b/tests/acceptance/features/apiLocks/unlockFiles.feature index 92c00f1a727..df4c9df624f 100644 --- a/tests/acceptance/features/apiLocks/unlockFiles.feature +++ b/tests/acceptance/features/apiLocks/unlockFiles.feature @@ -119,7 +119,7 @@ Feature: unlock locked items | spaces | shared | | spaces | exclusive | - + @issue-7767 Scenario Outline: trying to unlock a file inside the shared folder that has been locked by the file owner Given user "Brian" has been created with default attributes and without skeleton files And using DAV path diff --git a/tests/acceptance/features/apiSpacesShares/shareUploadTUS.feature b/tests/acceptance/features/apiSpacesShares/shareUploadTUS.feature index d14504f14a2..fa8628ba3ec 100644 --- a/tests/acceptance/features/apiSpacesShares/shareUploadTUS.feature +++ b/tests/acceptance/features/apiSpacesShares/shareUploadTUS.feature @@ -218,7 +218,7 @@ Feature: upload resources on share using TUS protocol # L0ZPTERFUi90ZXh0RmlsZS50eHQ= is the base64 encode of /FOLDER/textFile.txt | Upload-Metadata | filename L0ZPTERFUi90ZXh0RmlsZS50eHQ= | | Tus-Resumable | 1.0.0 | - And user "Alice" has uploaded file with checksum "SHA1 8cb2237d069ca88db6464eac60da96345513964" to the last created TUS Location with offset "0" and content "12345" via TUS inside of the space "Personal" using the WebDAV API + And user "Alice" has uploaded file with checksum "SHA1 8cb2237d0679ca88db6464eac60da96345513964" to the last created TUS Location with offset "0" and content "12345" via TUS inside of the space "Personal" using the WebDAV API When user "Brian" downloads the file "/FOLDER/textFile.txt" of the space "Shares" using the WebDAV API Then the header checksum should match "SHA1:8cb2237d0679ca88db6464eac60da96345513964" @@ -270,14 +270,14 @@ Feature: upload resources on share using TUS protocol | permissionsRole | Editor | And user "Brian" has a share "FOLDER" synced When user "Brian" creates a new TUS resource for the space "Shares" with content "" using the WebDAV API with these headers: - | Upload-Length | 16 | + | Upload-Length | 5 | # L0ZPTERFUi90ZXh0RmlsZS50eHQ= is the base64 encode of /FOLDER/textFile.txt | Upload-Metadata | filename L0ZPTERFUi90ZXh0RmlsZS50eHQ= | | Tus-Resumable | 1.0.0 | - And user "Brian" uploads file with checksum "MD5 827ccb0eea8a706c4c34a16891f84e7b" to the last created TUS Location with offset "0" and content "uploaded content" via TUS inside of the space "Shares" using the WebDAV API + And user "Brian" uploads file with checksum "MD5 827ccb0eea8a706c4c34a16891f84e7b" to the last created TUS Location with offset "0" and content "12345" via TUS inside of the space "Shares" using the WebDAV API Then for user "Alice" folder "FOLDER" of the space "Personal" should contain these entries: | textFile.txt | - And for user "Alice" the content of the file "FOLDER/textFile.txt" of the space "Personal" should be "uploaded content" + And for user "Alice" the content of the file "FOLDER/textFile.txt" of the space "Personal" should be "12345" @issue-1755 Scenario: sharee uploads a file to a received share folder with wrong checksum should not work @@ -290,11 +290,11 @@ Feature: upload resources on share using TUS protocol | permissionsRole | Editor | And user "Brian" has a share "FOLDER" synced When user "Brian" creates a new TUS resource for the space "Shares" with content "" using the WebDAV API with these headers: - | Upload-Length | 16 | + | Upload-Length | 5 | # L0ZPTERFUi90ZXh0RmlsZS50eHQ= is the base64 encode of /FOLDER/textFile.txt | Upload-Metadata | filename L0ZPTERFUi90ZXh0RmlsZS50eHQ= | | Tus-Resumable | 1.0.0 | - And user "Brian" uploads file with checksum "MD5 827ccb0eea8a706c4c34a16891f84e8c" to the last created TUS Location with offset "0" and content "uploaded content" via TUS inside of the space "Shares" using the WebDAV API + And user "Brian" uploads file with checksum "MD5 827ccb0eea8a706c4c34a16891f84e7b" to the last created TUS Location with offset "0" and content "12346" via TUS inside of the space "Shares" using the WebDAV API Then the HTTP status code should be "460" And for user "Alice" folder "FOLDER" of the space "Personal" should not contain these entries: | textFile.txt | @@ -314,7 +314,7 @@ Feature: upload resources on share using TUS protocol # L0ZPTERFUi90ZXh0RmlsZS50eHQ= is the base64 encode of /FOLDER/textFile.txt | Upload-Metadata | filename L0ZPTERFUi90ZXh0RmlsZS50eHQ= | | Tus-Resumable | 1.0.0 | - When user "Alice" uploads file with checksum "SHA1 8cb2237d0679ca88db6464eac60da96345513954" to the last created TUS Location with offset "0" and content "uploaded content" via TUS inside of the space "Personal" using the WebDAV API + When user "Alice" uploads file with checksum "SHA1 8cb2237d0679ca88db6464eac60da96345513964" to the last created TUS Location with offset "0" and content "12346" via TUS inside of the space "Personal" using the WebDAV API Then the HTTP status code should be "460" And for user "Alice" folder "FOLDER" of the space "Personal" should not contain these entries: | textFile.txt | diff --git a/tests/acceptance/features/coreApiWebdavUploadTUS/checksums.feature b/tests/acceptance/features/coreApiWebdavUploadTUS/checksums.feature index 3119ec42183..0d9f19fb407 100644 --- a/tests/acceptance/features/coreApiWebdavUploadTUS/checksums.feature +++ b/tests/acceptance/features/coreApiWebdavUploadTUS/checksums.feature @@ -59,7 +59,7 @@ Feature: checksums | new | | spaces | - + @issue-1755 Scenario Outline: uploading a file with incorrect checksum should not work Given using DAV path And user "Alice" has created a new TUS resource on the WebDAV API with these headers: @@ -67,7 +67,7 @@ Feature: checksums # dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt | Upload-Metadata | filename dGV4dEZpbGUudHh0 | When user "Alice" uploads file with 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" + Then the HTTP status code should be "460" And as "Alice" file "textFile.txt" should not exist Examples: | dav-path-version | checksum | @@ -131,16 +131,16 @@ Feature: checksums | new | | spaces | - + @issue-1755 Scenario Outline: uploading second chunk of file with incorrect checksum should not work Given using 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 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 + When 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 "460" And as "Alice" file "textFile.txt" should not exist Examples: | dav-path-version | @@ -173,7 +173,7 @@ Feature: checksums | spaces | MD5 5d41402abc4b2a76b9719d911017c592 | | spaces | SHA1 aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d | - + @issue-1755 Scenario Outline: uploading a file with correct checksum and overwriting an existing file with invalid checksum should not work Given using DAV path And user "Alice" has created a new TUS resource on the WebDAV API with these headers: @@ -185,7 +185,7 @@ Feature: checksums When user "Alice" overwrites existing file with offset "0" and data "hello" with checksum "" 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" + Then the HTTP status code should be "460" And the content of file "/textFile.txt" for user "Alice" should be "0123456789" Examples: | dav-path-version | checksum | @@ -221,7 +221,7 @@ Feature: checksums | spaces | MD5 5d41402abc4b2a76b9719d911017c592 | | spaces | SHA1 aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d | - + @issue-1755 Scenario Outline: overwriting an existing file with new data and invalid checksum should not work Given using DAV path And user "Alice" has created a new TUS resource on the WebDAV API with these headers: diff --git a/tests/acceptance/features/coreApiWebdavUploadTUS/optionsRequest.feature b/tests/acceptance/features/coreApiWebdavUploadTUS/optionsRequest.feature index 1c70a36b082..6b0069433ee 100644 --- a/tests/acceptance/features/coreApiWebdavUploadTUS/optionsRequest.feature +++ b/tests/acceptance/features/coreApiWebdavUploadTUS/optionsRequest.feature @@ -19,7 +19,7 @@ Feature: OPTIONS request | Tus-Resumable | 1.0.0 | | Tus-Version | 1.0.0 | | Tus-Extension | creation,creation-with-upload,checksum,expiration | - | Tus-Checksum-Algorithm | md5,sha1,adler32 | + | Tus-Checksum-Algorithm | md5,sha1,crc32 | Scenario: send OPTIONS request to webDav endpoints using the TUS protocol without any authentication @@ -34,24 +34,24 @@ Feature: OPTIONS request | Tus-Resumable | 1.0.0 | | Tus-Version | 1.0.0 | | Tus-Extension | creation,creation-with-upload,checksum,expiration | - | Tus-Checksum-Algorithm | md5,sha1,adler32 | - + | Tus-Checksum-Algorithm | md5,sha1,crc32 | + @issue-1012 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%/ | | /remote.php/dav/spaces/%spaceid%/ | - Then the HTTP status code should be "401" + 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 | - + | Tus-Checksum-Algorithm | md5,sha1,crc32 | + @issue-1012 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" @@ -59,10 +59,10 @@ Feature: OPTIONS request | /remote.php/webdav/ | | /remote.php/dav/files/%username%/ | | /remote.php/dav/spaces/%spaceid%/ | - Then the HTTP status code should be "401" + 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 | + | Tus-Checksum-Algorithm | md5,sha1,crc32 | diff --git a/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature b/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature index 51eba812f04..d31a5d5335e 100644 --- a/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature +++ b/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature @@ -212,21 +212,21 @@ Feature: upload file to shared folder | shareType | user | | permissionsRole | Editor | And user "Brian" has a share "FOLDER" synced - When user "Brian" creates a new TUS resource on the WebDAV API with these headers: + And user "Brian" has created 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 + # L1NoYXJlcy9GT0xERVIvdGV4dEZpbGUudHh0 is the base64 encode of /Shares/FOLDER/textFile.txt + | Upload-Metadata | filename L1NoYXJlcy9GT0xERVIvdGV4dEZpbGUudHh0 | + When user "Brian" uploads file with checksum "MD5 8a4e0407dcda7872d44dada38887b8ae" 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" + And the content of file "FOLDER/textFile.txt" for user "Alice" should be "uploaded content" + And the content of file "Shares/FOLDER/textFile.txt" for user "Brian" should be "uploaded content" Examples: | dav-path-version | | old | | new | - + @issue-1755 Scenario Outline: sharee uploads a file to a received share folder with wrong checksum should not work Given using DAV path And user "Alice" has created folder "/FOLDER" @@ -237,21 +237,21 @@ Feature: upload file to shared folder | shareType | user | | permissionsRole | Editor | And user "Brian" has a share "FOLDER" synced - When user "Brian" creates a new TUS resource on the WebDAV API with these headers: + And user "Brian" has created 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 | + # L1NoYXJlcy9GT0xERVIvdGV4dEZpbGUudHh0 is the base64 encode of /Shares/FOLDER/textFile.txt + | Upload-Metadata | filename L1NoYXJlcy9GT0xERVIvdGV4dEZpbGUudHh0 | 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" + Then the HTTP status code should be "460" And as "Alice" file "/FOLDER/textFile.txt" should not exist Examples: | dav-path-version | | old | | new | - - Scenario Outline: sharer uploads a file to shared folder with wrong correct checksum should not work + @issue-1755 + Scenario Outline: sharer uploads a file to shared folder with wrong checksum should not work Given using DAV path And user "Alice" has created folder "/FOLDER" And user "Alice" has sent the following resource share invitation: @@ -262,11 +262,11 @@ Feature: upload file to shared folder | permissionsRole | Editor | And user "Brian" has a share "FOLDER" synced And user "Alice" has created a new TUS resource on the WebDAV API with these headers: - | Upload-Length | 5 | + | Upload-Length | 16 | # 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" + Then the HTTP status code should be "460" And as "Alice" file "/FOLDER/textFile.txt" should not exist And as "Brian" file "/Shares/FOLDER/textFile.txt" should not exist Examples: @@ -302,16 +302,16 @@ Feature: upload file to shared folder | shareType | user | | permissionsRole | Editor | And user "Brian" has a share "FOLDER" synced - And user "Brian" creates a new TUS resource on the WebDAV API with these headers: + And user "Brian" has created 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 | + # L1NoYXJlcy9GT0xERVIvdGV4dEZpbGUudHh0 is the base64 encode of /Shares/FOLDER/textFile.txt + | Upload-Metadata | filename L1NoYXJlcy9GT0xERVIvdGV4dEZpbGUudHh0 | 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" + And the content of file "Shares/FOLDER/textFile.txt" for user "Brian" should be "0123456789" Examples: | dav-path-version | | old | @@ -343,7 +343,7 @@ Feature: upload file to shared folder | old | | new | - + @issue-1755 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 path And user "Alice" has created a new TUS resource on the WebDAV API with these headers: @@ -362,7 +362,7 @@ Feature: upload file to shared folder | Upload-Length | 19 | # dGV4dEZpbGUudHh0 is the base64 encode of /Shares/textFile.txt | Upload-Metadata | filename L1NoYXJlcy90ZXh0RmlsZS50eHQ= | - Then the HTTP status code should be "406" + Then the HTTP status code should be "460" And the content of file "/textFile.txt" for user "Alice" should be "original content" Examples: | dav-path-version |