diff --git a/tests/acceptance/features/bootstrap/OccContext.php b/tests/acceptance/features/bootstrap/OccContext.php index 0e5bf659c7..07a4cf74e3 100644 --- a/tests/acceptance/features/bootstrap/OccContext.php +++ b/tests/acceptance/features/bootstrap/OccContext.php @@ -2504,65 +2504,6 @@ class OccContext implements Context { $this->deleteConfigKeyOfAppUsingTheOccCommand($key, $app); } - /** - * @When the administrator adds/updates system config key :key with value :value using the occ command - * @When the administrator adds/updates system config key :key with value :value and type :type using the occ command - * - * @param string $key - * @param string $value - * @param string $type - * - * @return void - * @throws Exception - */ - public function theAdministratorAddsSystemConfigKeyWithValueUsingTheOccCommand( - string $key, - string $value, - string $type = "string" - ):void { - $this->addSystemConfigKeyUsingTheOccCommand( - $key, - $value, - $type - ); - } - - /** - * @Given the administrator has added/updated system config key :key with value :value - * @Given the administrator has added/updated system config key :key with value :value and type :type - * - * @param string $key - * @param string $value - * @param string $type - * - * @return void - * @throws Exception - */ - public function theAdministratorHasAddedSystemConfigKeyWithValueUsingTheOccCommand( - string $key, - string $value, - string $type = "string" - ):void { - $this->addSystemConfigKeyUsingTheOccCommand( - $key, - $value, - $type - ); - $this->theCommandShouldHaveBeenSuccessful(); - } - - /** - * @When the administrator deletes system config key :key using the occ command - * - * @param string $key - * - * @return void - * @throws Exception - */ - public function theAdministratorDeletesSystemConfigKeyUsingTheOccCommand(string $key):void { - $this->deleteSystemConfigKeyUsingTheOccCommand($key); - } - /** * @When the administrator empties the trashbin of user :user using the occ command * @@ -2752,29 +2693,6 @@ class OccContext implements Context { } } - /** - * @Then system config key :key should have value :value - * - * @param string $key - * @param string $value - * - * @return void - * @throws Exception - */ - public function systemConfigKeyShouldHaveValue(string $key, string $value):void { - $config = \trim( - SetupHelper::getSystemConfigValue( - $key, - $this->featureContext->getStepLineRef() - ) - ); - Assert::assertSame( - $value, - $config, - "The system config key '$key' was expected to have value '$value', but got '$config'" - ); - } - /** * @Then the command output table should contain the following text: * @@ -2798,24 +2716,6 @@ class OccContext implements Context { } } - /** - * @Then system config key :key should not exist - * - * @param string $key - * - * @return void - * @throws Exception - */ - public function systemConfigKeyShouldNotExist(string $key):void { - Assert::assertEmpty( - SetupHelper::getSystemConfig( - $key, - $this->featureContext->getStepLineRef() - )['stdOut'], - "The system config key '$key' was not expected to exist" - ); - } - /** * @When the administrator lists the config keys * @@ -2923,59 +2823,6 @@ class OccContext implements Context { return false; } - /** - * @Then the system config key :key from the last command output should match value :value of type :type - * - * @param string $key - * @param string $value - * @param string $type - * - * @return void - */ - public function theSystemConfigKeyFromLastCommandOutputShouldContainValue( - string $key, - string $value, - string $type - ):void { - $configList = \json_decode( - $this->featureContext->getStdOutOfOccCommand(), - true - ); - $systemConfig = $configList['system']; - - // convert the value to it's respective type based on type given in the type column - if ($type === 'boolean') { - $value = $value === 'true' ? true : false; - } elseif ($type === 'integer') { - $value = (int) $value; - } elseif ($type === 'json') { - // if the expected value of the key is a json - // match the value with the regular expression - $actualKeyValuePair = \json_encode( - $systemConfig[$key], - JSON_UNESCAPED_SLASHES - ); - - Assert::assertThat( - $actualKeyValuePair, - Assert::matchesRegularExpression($value) - ); - return; - } - - if (!\array_key_exists($key, $systemConfig)) { - Assert::fail( - "system config doesn't contain key: " . $key - ); - } - - Assert::assertEquals( - $value, - $systemConfig[$key], - "config: $key doesn't contain value: $value" - ); - } - /** * @Given the administrator has enabled the external storage * diff --git a/tests/acceptance/features/coreApiSharees/sharees.feature b/tests/acceptance/features/coreApiSharees/sharees.feature index 9972b75e67..438ae812d2 100644 --- a/tests/acceptance/features/coreApiSharees/sharees.feature +++ b/tests/acceptance/features/coreApiSharees/sharees.feature @@ -248,8 +248,7 @@ Feature: sharees Scenario Outline: search for sharees when search min length is set to 2 - Given the administrator has updated system config key "user.search_min_length" with value "2" - And user "sharee2" has been created with default attributes and without skeleton files + Given user "sharee2" has been created with default attributes and without skeleton files And using OCS API version "" When user "sharee1" gets the sharees using the sharing API with parameters | search | sh | @@ -273,8 +272,7 @@ Feature: sharees Scenario Outline: search for sharees with long name when search min length is set to 2 - Given the administrator has updated system config key "user.search_min_length" with value "2" - And user "sharee2" has been created with default attributes and without skeleton files + Given user "sharee2" has been created with default attributes and without skeleton files And using OCS API version "" When user "sharee1" gets the sharees using the sharing API with parameters | search | sharee | diff --git a/tests/acceptance/features/coreApiWebdavMove1/moveFolderToBlacklistedName.feature b/tests/acceptance/features/coreApiWebdavMove1/moveFolderToBlacklistedName.feature index e412b6444d..01bcb2d6d8 100644 --- a/tests/acceptance/features/coreApiWebdavMove1/moveFolderToBlacklistedName.feature +++ b/tests/acceptance/features/coreApiWebdavMove1/moveFolderToBlacklistedName.feature @@ -30,7 +30,6 @@ Feature: users cannot move (rename) a folder to a blacklisted name Scenario Outline: Rename a folder to a banned name Given using DAV path And user "Alice" has created folder "/testshare" - And the administrator has updated system config key "blacklisted_files" with value '["blacklisted-file.txt",".htaccess"]' and type "json" When user "Alice" moves folder "/testshare" to "/blacklisted-file.txt" using the WebDAV API Then the HTTP status code should be "403" And user "Alice" should see the following elements @@ -51,9 +50,6 @@ Feature: users cannot move (rename) a folder to a blacklisted name And user "Brian" has been created with default attributes and without skeleton files And user "Brian" has created folder "/testshare" And user "Brian" has created folder "/FOLDER" - # Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it - # The actual regular expressions end up being .*\.ext$ and ^bannedfilename\..+ - And the administrator has updated system config key "blacklisted_files_regex" with value '[".*\\.ext$","^bannedfilename\\..+","containsbannedstring"]' and type "json" When user "Brian" moves folder "/testshare" to these foldernames using the webDAV API then the results should be as listed | foldername | http-code | exists | | .ext | 403 | no | diff --git a/tests/acceptance/features/coreApiWebdavMove1/moveFolderToExcludedDirectory.feature b/tests/acceptance/features/coreApiWebdavMove1/moveFolderToExcludedDirectory.feature index 84c846a16a..18bb9059cc 100644 --- a/tests/acceptance/features/coreApiWebdavMove1/moveFolderToExcludedDirectory.feature +++ b/tests/acceptance/features/coreApiWebdavMove1/moveFolderToExcludedDirectory.feature @@ -12,7 +12,6 @@ Feature: users cannot move (rename) a folder to or into an excluded directory Scenario Outline: Rename a folder to an excluded directory name Given using DAV path And user "Alice" has created folder "/testshare" - And the administrator has updated system config key "excluded_directories" with value '[".github"]' and type "json" When user "Alice" moves folder "/testshare" to "/.github" using the WebDAV API Then the HTTP status code should be "403" And user "Alice" should see the following elements @@ -32,7 +31,6 @@ Feature: users cannot move (rename) a folder to or into an excluded directory Given using DAV path And user "Alice" has created folder "/testshare" And user "Alice" has created folder "/FOLDER" - And the administrator has updated system config key "excluded_directories" with value '[".github"]' and type "json" When user "Alice" moves folder "/testshare" to "/FOLDER/.github" using the WebDAV API Then the HTTP status code should be "403" And user "Alice" should see the following elements @@ -52,9 +50,6 @@ Feature: users cannot move (rename) a folder to or into an excluded directory Given using DAV path And user "Alice" has created folder "/testshare" And user "Alice" has created folder "/FOLDER" - # Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it - # The actual regular expressions end up being endswith\.bad$ and ^\.git - And the administrator has updated system config key "excluded_directories_regex" with value '["endswith\\.bad$","^\\.git","containsvirusinthename"]' and type "json" When user "Alice" moves folder "/testshare" to these foldernames using the webDAV API then the results should be as listed | foldername | http-code | exists | | endswith.bad | 403 | no | diff --git a/tests/acceptance/features/coreApiWebdavMove2/moveFileToBlacklistedName.feature b/tests/acceptance/features/coreApiWebdavMove2/moveFileToBlacklistedName.feature index 6aaea8d757..8e84073993 100644 --- a/tests/acceptance/features/coreApiWebdavMove2/moveFileToBlacklistedName.feature +++ b/tests/acceptance/features/coreApiWebdavMove2/moveFileToBlacklistedName.feature @@ -27,7 +27,6 @@ Feature: users cannot move (rename) a file to a blacklisted name Scenario Outline: rename a file to a banned filename Given using DAV path - And the administrator has updated system config key "blacklisted_files" with value '["blacklisted-file.txt",".htaccess"]' and type "json" When user "Alice" moves file "/textfile0.txt" to "/blacklisted-file.txt" using the WebDAV API Then the HTTP status code should be "403" Examples: @@ -44,9 +43,6 @@ Feature: users cannot move (rename) a file to a blacklisted name Scenario Outline: rename a file to a filename that matches (or not) blacklisted_files_regex Given using DAV path And user "Alice" has created folder "FOLDER" - # Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it - # The actual regular expressions end up being .*\.ext$ and ^bannedfilename\..+ - And the administrator has updated system config key "blacklisted_files_regex" with value '[".*\\.ext$","^bannedfilename\\..+","containsbannedstring"]' and type "json" When user "Alice" moves file "/textfile0.txt" to these filenames using the webDAV API then the results should be as listed | filename | http-code | exists | | .ext | 403 | no | @@ -77,4 +73,4 @@ Feature: users cannot move (rename) a file to a blacklisted name @skipOnOcV10 @personalSpace Examples: | dav_version | - | spaces | \ No newline at end of file + | spaces | diff --git a/tests/acceptance/features/coreApiWebdavMove2/moveFileToExcludedDirectory.feature b/tests/acceptance/features/coreApiWebdavMove2/moveFileToExcludedDirectory.feature index 05e848f39e..cfc42b6e23 100644 --- a/tests/acceptance/features/coreApiWebdavMove2/moveFileToExcludedDirectory.feature +++ b/tests/acceptance/features/coreApiWebdavMove2/moveFileToExcludedDirectory.feature @@ -12,7 +12,6 @@ Feature: users cannot move (rename) a file to or into an excluded directory Scenario Outline: rename a file to an excluded directory name Given using DAV path - And the administrator has updated system config key "excluded_directories" with value '[".github"]' and type "json" When user "Alice" moves file "/textfile0.txt" to "/.github" using the WebDAV API Then the HTTP status code should be "403" Examples: @@ -24,12 +23,11 @@ Feature: users cannot move (rename) a file to or into an excluded directory Examples: | dav_version | | spaces | - + Scenario Outline: rename a file to an excluded directory name inside a parent directory Given using DAV path And user "Alice" has created folder "FOLDER" - And the administrator has updated system config key "excluded_directories" with value '[".github"]' and type "json" When user "Alice" moves file "/textfile0.txt" to "/FOLDER/.github" using the WebDAV API Then the HTTP status code should be "403" Examples: @@ -46,9 +44,6 @@ Feature: users cannot move (rename) a file to or into an excluded directory Scenario Outline: rename a file to a filename that matches (or not) excluded_directories_regex Given using DAV path And user "Alice" has created folder "FOLDER" - # Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it - # The actual regular expressions end up being endswith\.bad$ and ^\.git - And the administrator has updated system config key "excluded_directories_regex" with value '["endswith\\.bad$","^\\.git","containsvirusinthename"]' and type "json" When user "Alice" moves file "/textfile0.txt" to these filenames using the webDAV API then the results should be as listed | filename | http-code | exists | | endswith.bad | 403 | no | @@ -81,4 +76,4 @@ Feature: users cannot move (rename) a file to or into an excluded directory @skipOnOcV10 @personalSpace Examples: | dav_version | - | spaces | \ No newline at end of file + | spaces | diff --git a/tests/acceptance/features/coreApiWebdavPreviews/previews.feature b/tests/acceptance/features/coreApiWebdavPreviews/previews.feature index 6f35732685..da3fcb2e4b 100644 --- a/tests/acceptance/features/coreApiWebdavPreviews/previews.feature +++ b/tests/acceptance/features/coreApiWebdavPreviews/previews.feature @@ -114,8 +114,7 @@ Feature: previews of files downloaded through the webdav API Scenario: Download file previews when it is disabled by the administrator - Given the administrator has updated system config key "enable_previews" with value "false" and type "boolean" - And user "Alice" has uploaded file "filesForUpload/lorem.txt" to "/parent.txt" + Given user "Alice" has uploaded file "filesForUpload/lorem.txt" to "/parent.txt" When user "Alice" downloads the preview of "/parent.txt" with width "32" and height "32" using the WebDAV API Then the HTTP status code should be "404" And the value of the item "/d:error/s:exception" in the response about user "Alice" should be "Sabre\DAV\Exception\NotFound" @@ -123,8 +122,6 @@ Feature: previews of files downloaded through the webdav API Scenario: unset maximum size of previews Given user "Alice" has uploaded file "filesForUpload/lorem.txt" to "/parent.txt" - And the administrator has updated system config key "preview_max_x" with value "null" - And the administrator has updated system config key "preview_max_y" with value "null" When user "Alice" downloads the preview of "/parent.txt" with width "32" and height "32" using the WebDAV API Then the HTTP status code should be "404" And the value of the item "/d:error/s:exception" in the response about user "Alice" should be "Sabre\DAV\Exception\NotFound" @@ -132,8 +129,6 @@ Feature: previews of files downloaded through the webdav API Scenario: download preview of size "null" Given user "Alice" has uploaded file "filesForUpload/lorem.txt" to "/parent.txt" - And the administrator has updated system config key "preview_max_x" with value "null" - And the administrator has updated system config key "preview_max_y" with value "null" When user "Alice" downloads the preview of "/parent.txt" with width "null" and height "null" using the WebDAV API Then the HTTP status code should be "400" And the value of the item "/d:error/s:exception" in the response about user "Alice" should be "Sabre\DAV\Exception\BadRequest" @@ -141,8 +136,6 @@ Feature: previews of files downloaded through the webdav API Scenario Outline: download previews of different size smaller than the maximum size set Given user "Alice" has uploaded file "filesForUpload/lorem.txt" to "/parent.txt" - And the administrator has updated system config key "preview_max_x" with value "32" - And the administrator has updated system config key "preview_max_y" with value "32" When user "Alice" downloads the preview of "/parent.txt" with width "" and height "" using the WebDAV API Then the HTTP status code should be "200" And the downloaded image should be "" pixels wide and "" pixels high @@ -156,8 +149,6 @@ Feature: previews of files downloaded through the webdav API Scenario Outline: download previews of different size larger than the maximum size set Given user "Alice" has uploaded file "filesForUpload/lorem.txt" to "/parent.txt" - And the administrator has updated system config key "preview_max_x" with value "32" - And the administrator has updated system config key "preview_max_y" with value "32" When user "Alice" downloads the preview of "/parent.txt" with width "" and height "" using the WebDAV API Then the HTTP status code should be "200" And the downloaded image should be "32" pixels wide and "32" pixels high diff --git a/tests/acceptance/features/coreApiWebdavUpload1/uploadFileToBlacklistedName.feature b/tests/acceptance/features/coreApiWebdavUpload1/uploadFileToBlacklistedName.feature index a870a64786..1cda64290b 100644 --- a/tests/acceptance/features/coreApiWebdavUpload1/uploadFileToBlacklistedName.feature +++ b/tests/acceptance/features/coreApiWebdavUpload1/uploadFileToBlacklistedName.feature @@ -11,7 +11,6 @@ Feature: users cannot upload a file to a blacklisted name @issue-ocis-reva-54 Scenario Outline: upload a file to a banned filename Given using DAV path - And the administrator has updated system config key "blacklisted_files" with value '["blacklisted-file.txt",".htaccess"]' and type "json" When user "Alice" uploads file with content "uploaded content" to "blacklisted-file.txt" using the WebDAV API Then the HTTP status code should be "403" And as "Alice" file "blacklisted-file.txt" should not exist @@ -29,9 +28,6 @@ Feature: users cannot upload a file to a blacklisted name Scenario Outline: upload a file to a filename that matches (or not) blacklisted_files_regex Given using DAV path And user "Alice" has created folder "FOLDER" - # Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it - # The actual regular expressions end up being .*\.ext$ and ^bannedfilename\..+ - And the administrator has updated system config key "blacklisted_files_regex" with value '[".*\\.ext$","^bannedfilename\\..+","containsbannedstring"]' and type "json" When user "Alice" uploads to these filenames with content "uploaded content" using the webDAV API then the results should be as listed | filename | http-code | exists | | .ext | 403 | no | diff --git a/tests/acceptance/features/coreApiWebdavUpload1/uploadFileToExcludedDirectory.feature b/tests/acceptance/features/coreApiWebdavUpload1/uploadFileToExcludedDirectory.feature index 08ff53f123..497310728e 100644 --- a/tests/acceptance/features/coreApiWebdavUpload1/uploadFileToExcludedDirectory.feature +++ b/tests/acceptance/features/coreApiWebdavUpload1/uploadFileToExcludedDirectory.feature @@ -11,7 +11,6 @@ Feature: users cannot upload a file to or into an excluded directory @issue-ocis-reva-54 Scenario Outline: upload a file to an excluded directory name Given using DAV path - And the administrator has updated system config key "excluded_directories" with value '[".github"]' and type "json" When user "Alice" uploads file with content "uploaded content" to ".github" using the WebDAV API Then the HTTP status code should be "403" And as "Alice" file ".github" should not exist @@ -29,7 +28,6 @@ Feature: users cannot upload a file to or into an excluded directory Scenario Outline: upload a file to an excluded directory name inside a parent directory Given using DAV path And user "Alice" has created folder "FOLDER" - And the administrator has updated system config key "excluded_directories" with value '[".github"]' and type "json" When user "Alice" uploads file with content "uploaded content" to "/FOLDER/.github" using the WebDAV API Then the HTTP status code should be "403" And as "Alice" folder "/FOLDER" should exist @@ -48,9 +46,6 @@ Feature: users cannot upload a file to or into an excluded directory Scenario Outline: upload a file to a filename that matches (or not) excluded_directories_regex Given using DAV path And user "Alice" has created folder "FOLDER" - # Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it - # The actual regular expressions end up being endswith\.bad$ and ^\.git - And the administrator has updated system config key "excluded_directories_regex" with value '["endswith\\.bad$","^\\.git","containsvirusinthename"]' and type "json" When user "Alice" uploads to these filenames with content "uploaded content" using the webDAV API then the results should be as listed | filename | http-code | exists | | endswith.bad | 403 | no | diff --git a/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToBlacklistedNameUsingOldChunking.feature b/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToBlacklistedNameUsingOldChunking.feature index 107290f4c7..ba1601832f 100644 --- a/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToBlacklistedNameUsingOldChunking.feature +++ b/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToBlacklistedNameUsingOldChunking.feature @@ -11,16 +11,12 @@ Feature: users cannot upload a file to a blacklisted name using old chunking Scenario: Upload a file to a banned filename using old chunking - Given the administrator has updated system config key "blacklisted_files" with value '["blacklisted-file.txt",".htaccess"]' and type "json" When user "Alice" uploads file "filesForUpload/textfile.txt" to "blacklisted-file.txt" in 3 chunks using the WebDAV API Then the HTTP status code should be "403" And as "Alice" file "blacklisted-file.txt" should not exist Scenario Outline: upload a file to a filename that matches blacklisted_files_regex using old chunking - # Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it - # The actual regular expressions end up being .*\.ext$ and ^bannedfilename\..+ - Given the administrator has updated system config key "blacklisted_files_regex" with value '[".*\\.ext$","^bannedfilename\\..+","containsbannedstring"]' and type "json" When user "Alice" uploads file "filesForUpload/textfile.txt" to "" in 3 chunks using the WebDAV API Then the HTTP status code should be "" And as "Alice" file "" should not exist @@ -32,9 +28,6 @@ Feature: users cannot upload a file to a blacklisted name using old chunking Scenario: upload a file to a filename that does not match blacklisted_files_regex using old chunking - # Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it - # The actual regular expressions end up being .*\.ext$ and ^bannedfilename\..+ - Given the administrator has updated system config key "blacklisted_files_regex" with value '[".*\\.ext$","^bannedfilename\\..+","containsbannedstring"]' and type "json" When user "Alice" uploads file "filesForUpload/textfile.txt" to "not-contains-banned-string.txt" in 3 chunks using the WebDAV API Then the HTTP status code should be "201" And as "Alice" file "not-contains-banned-string.txt" should exist diff --git a/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToExcludedDirectoryUsingOldChunking.feature b/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToExcludedDirectoryUsingOldChunking.feature index e4e6e558c0..50cd45cf9c 100644 --- a/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToExcludedDirectoryUsingOldChunking.feature +++ b/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToExcludedDirectoryUsingOldChunking.feature @@ -11,7 +11,6 @@ Feature: users cannot upload a file to or into an excluded directory using old c Scenario: Upload a file to an excluded directory name using old chunking - Given the administrator has updated system config key "excluded_directories" with value '[".github"]' and type "json" When user "Alice" uploads file "filesForUpload/textfile.txt" to "/.github" in 3 chunks using the WebDAV API Then the HTTP status code should be "403" And as "Alice" file ".github" should not exist @@ -19,7 +18,6 @@ Feature: users cannot upload a file to or into an excluded directory using old c Scenario: Upload a file to an excluded directory name inside a parent directory using old chunking Given user "Alice" has created folder "FOLDER" - And the administrator has updated system config key "excluded_directories" with value '[".github"]' and type "json" When user "Alice" uploads file "filesForUpload/textfile.txt" to "/FOLDER/.github" in 3 chunks using the WebDAV API Then the HTTP status code should be "403" And as "Alice" folder "/FOLDER" should exist @@ -27,9 +25,6 @@ Feature: users cannot upload a file to or into an excluded directory using old c Scenario Outline: upload a file to a filename that matches excluded_directories_regex using old chunking - # Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it - # The actual regular expressions end up being endswith\.bad$ and ^\.git - Given the administrator has updated system config key "excluded_directories_regex" with value '["endswith\\.bad$","^\\.git","containsvirusinthename"]' and type "json" When user "Alice" uploads file "filesForUpload/textfile.txt" to "" in 3 chunks using the WebDAV API Then the HTTP status code should be "" And as "Alice" file "" should not exist @@ -41,9 +36,6 @@ Feature: users cannot upload a file to or into an excluded directory using old c Scenario: upload a file to a filename that does not match excluded_directories_regex using old chunking - # Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it - # The actual regular expressions end up being endswith\.bad$ and ^\.git - Given the administrator has updated system config key "excluded_directories_regex" with value '["endswith\\.bad$","^\\.git","containsvirusinthename"]' and type "json" When user "Alice" uploads file "filesForUpload/textfile.txt" to "not-contains-virus-in-the-name.txt" in 3 chunks using the WebDAV API Then the HTTP status code should be "201" And as "Alice" file "not-contains-virus-in-the-name.txt" should exist