diff --git a/tests/acceptance/features/apiAuth/tokenAuth.feature b/tests/acceptance/features/apiAuth/tokenAuth.feature index ce6a10edf0a3..cef3c2bbee46 100644 --- a/tests/acceptance/features/apiAuth/tokenAuth.feature +++ b/tests/acceptance/features/apiAuth/tokenAuth.feature @@ -6,12 +6,14 @@ Feature: tokenAuth And user "Alice" has been created with default attributes and without skeleton files And token auth has been enforced + Scenario: creating a user with basic auth should be blocked when token auth is enforced Given user "brand-new-user" has been deleted When the administrator sends a user creation request for user "brand-new-user" password "%alt1%" using the provisioning API Then the OCS status code should be "997" And the HTTP status code should be "401" + Scenario: moving a file should be blocked when token auth is enforced Given using new DAV path When user "Alice" moves file "/textfile0.txt" to "/renamed_textfile0.txt" using the WebDAV API @@ -24,6 +26,7 @@ Feature: tokenAuth When the user requests "/index.php/apps/files" with "GET" using the generated app password Then the HTTP status code should be "200" + Scenario: cannot access files app with an app password that is deleted when token auth is enforced Given a new browser session for "Alice" has been started And the user has generated a new app password named "my-client" @@ -31,6 +34,7 @@ Feature: tokenAuth When the user requests "/index.php/apps/files" with "GET" using the generated app password Then the HTTP status code should be "401" + Scenario: Access files app with when there are multiple tokens generated Given a new browser session for "Alice" has been started And the user has generated a new app password named "my-client" @@ -45,6 +49,7 @@ Feature: tokenAuth When user "Alice" requests "/index.php/apps/files" with "GET" using basic auth Then the HTTP status code should be "401" + Scenario: using WebDAV with basic auth should be blocked when token auth is enforced When user "Alice" requests "/remote.php/webdav" with "PROPFIND" using basic auth Then the HTTP status code should be "401" diff --git a/tests/acceptance/features/apiAuth/webDavAuth.feature b/tests/acceptance/features/apiAuth/webDavAuth.feature index 0a8106b8b430..fadc2cbeee9e 100644 --- a/tests/acceptance/features/apiAuth/webDavAuth.feature +++ b/tests/acceptance/features/apiAuth/webDavAuth.feature @@ -33,11 +33,6 @@ Feature: auth When user "Alice" requests "/remote.php/webdav" with "PROPFIND" using basic token auth Then the HTTP status code should be "207" - # DAV token auth is not possible yet - #Scenario: using WebDAV with a client token - # When requesting "/remote.php/webdav" with "PROPFIND" using a client token - # Then the HTTP status code should be "207" - @smokeTest @notToImplementOnOCIS Scenario: using WebDAV with browser session Given a new browser session for "Alice" has been started diff --git a/tests/acceptance/features/apiAuthOcs/ocsDELETEAuth.feature b/tests/acceptance/features/apiAuthOcs/ocsDELETEAuth.feature index 02b1ee73357f..676cf84b26c1 100644 --- a/tests/acceptance/features/apiAuthOcs/ocsDELETEAuth.feature +++ b/tests/acceptance/features/apiAuthOcs/ocsDELETEAuth.feature @@ -4,9 +4,7 @@ Feature: auth Background: Given user "another-admin" has been created with default attributes and without skeleton files - @smokeTest @issue-ocis-reva-30 @issue-ocis-reva-65 - @skipOnBruteForceProtection @issue-brute_force_protection-112 - @skipOnOcV10 @issue-32068 + @smokeTest @issue-ocis-reva-30 @issue-ocis-reva-65 @skipOnBruteForceProtection @issue-brute_force_protection-112 @skipOnOcV10 @issue-32068 Scenario: send DELETE requests to OCS endpoints as admin with wrong password Given user "another-admin" has been added to group "admin" When user "another-admin" requests these endpoints with "DELETE" using password "invalid" about user "Alice" diff --git a/tests/acceptance/features/apiAuthOcs/ocsDELETEAuthOc10Issue32068.feature b/tests/acceptance/features/apiAuthOcs/ocsDELETEAuthOc10Issue32068.feature index f22e99608490..e185ae46972a 100644 --- a/tests/acceptance/features/apiAuthOcs/ocsDELETEAuthOc10Issue32068.feature +++ b/tests/acceptance/features/apiAuthOcs/ocsDELETEAuthOc10Issue32068.feature @@ -1,8 +1,7 @@ @api @files_sharing-app-required @notToImplementOnOCIS Feature: current oC10 behavior for issue-32068 - @smokeTest @issue-32068 @issue-ocis-reva-30 @issue-ocis-reva-65 - @skipOnBruteForceProtection @issue-brute_force_protection-112 + @smokeTest @issue-32068 @issue-ocis-reva-30 @issue-ocis-reva-65 @skipOnBruteForceProtection @issue-brute_force_protection-112 Scenario: send DELETE requests to OCS endpoints as admin with wrong password Given user "another-admin" has been created with default attributes and without skeleton files And user "another-admin" has been added to group "admin" diff --git a/tests/acceptance/features/apiAuthOcs/ocsGETAuth.feature b/tests/acceptance/features/apiAuthOcs/ocsGETAuth.feature index 7a5f72397ce3..9bdba239a162 100644 --- a/tests/acceptance/features/apiAuthOcs/ocsGETAuth.feature +++ b/tests/acceptance/features/apiAuthOcs/ocsGETAuth.feature @@ -4,9 +4,7 @@ Feature: auth Background: Given user "Alice" has been created with default attributes and without skeleton files - @issue-32068 @skipOnOcV10 - @issue-ocis-reva-30 - @smokeTest + @issue-32068 @skipOnOcV10 @issue-ocis-reva-30 @smokeTest Scenario: using OCS anonymously When a user requests these endpoints with "GET" and no authentication | endpoint | @@ -40,14 +38,7 @@ Feature: auth Then the HTTP status code of responses on all endpoints should be "200" And the OCS status code of responses on all endpoints should be "200" - @issue-32068 @skipOnOcV10 - @issue-ocis-reva-11 - @issue-ocis-reva-30 - @issue-ocis-reva-31 - @issue-ocis-reva-32 - @issue-ocis-reva-33 - @issue-ocis-reva-34 - @issue-ocis-reva-35 + @issue-32068 @skipOnOcV10 @issue-ocis-reva-11 @issue-ocis-reva-30 @issue-ocis-reva-31 @issue-ocis-reva-32 @issue-ocis-reva-33 @issue-ocis-reva-34 @issue-ocis-reva-35 Scenario: using OCS with non-admin basic auth When the user "Alice" requests these endpoints with "GET" with basic auth | endpoint | @@ -78,9 +69,7 @@ Feature: auth Then the HTTP status code of responses on all endpoints should be "401" And the OCS status code of responses on all endpoints should be "401" - @issue-32068 @skipOnOcV10 @issue-ocis-reva-29 @issue-ocis-reva-30 - @smokeTest - @skipOnBruteForceProtection @issue-brute_force_protection-112 + @issue-32068 @skipOnOcV10 @issue-ocis-reva-29 @issue-ocis-reva-30 @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 Scenario: using OCS as normal user with wrong password When user "Alice" requests these endpoints with "GET" using password "invalid" | endpoint | @@ -128,8 +117,7 @@ Feature: auth Then the HTTP status code of responses on all endpoints should be "200" And the OCS status code of responses on all endpoints should be "200" - @issue-ocis-reva-30 @issue-ocis-reva-65 - @skipOnBruteForceProtection @issue-brute_force_protection-112 + @issue-ocis-reva-30 @issue-ocis-reva-65 @skipOnBruteForceProtection @issue-brute_force_protection-112 Scenario: using OCS as admin user with wrong password Given user "another-admin" has been created with default attributes and without skeleton files And user "another-admin" has been added to group "admin" @@ -162,7 +150,6 @@ Feature: auth Then the HTTP status code of responses on all endpoints should be "200" And the OCS status code of responses on all endpoints should be "200" - @notToImplementOnOCIS @issue-ocis-reva-30 @issue-ocis-reva-28 Scenario: using OCS with token auth of a normal user Given a new client token for "Alice" has been generated diff --git a/tests/acceptance/features/apiAuthOcs/ocsGETAuthFilesExternal.feature b/tests/acceptance/features/apiAuthOcs/ocsGETAuthFilesExternal.feature index 98c4871f80bb..df7fb37012b9 100644 --- a/tests/acceptance/features/apiAuthOcs/ocsGETAuthFilesExternal.feature +++ b/tests/acceptance/features/apiAuthOcs/ocsGETAuthFilesExternal.feature @@ -4,8 +4,7 @@ Feature: auth Background: Given user "Alice" has been created with default attributes and without skeleton files - @issue-32068 @skipOnOcV10 - @smokeTest + @issue-32068 @skipOnOcV10 @smokeTest Scenario: using OCS anonymously When a user requests these endpoints with "GET" and no authentication | endpoint | @@ -27,9 +26,7 @@ Feature: auth Then the HTTP status code of responses on all endpoints should be "200" And the OCS status code of responses on all endpoints should be "200" - @issue-32068 @skipOnOcV10 - @smokeTest - @skipOnBruteForceProtection @issue-brute_force_protection-112 + @issue-32068 @skipOnOcV10 @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 Scenario: using OCS as normal user with wrong password When user "Alice" requests these endpoints with "GET" using password "invalid" | endpoint | diff --git a/tests/acceptance/features/apiAuthOcs/ocsGETAuthFilesExternalOc10Issue32068.feature b/tests/acceptance/features/apiAuthOcs/ocsGETAuthFilesExternalOc10Issue32068.feature index eb6ffff1e28a..6d1b225a0cb7 100644 --- a/tests/acceptance/features/apiAuthOcs/ocsGETAuthFilesExternalOc10Issue32068.feature +++ b/tests/acceptance/features/apiAuthOcs/ocsGETAuthFilesExternalOc10Issue32068.feature @@ -27,8 +27,7 @@ Feature: current oC10 behavior for issue-32068 Then the HTTP status code of responses on all endpoints should be "200" And the OCS status code of responses on all endpoints should be "200" - @smokeTest - @skipOnBruteForceProtection @issue-brute_force_protection-112 + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 Scenario: using OCS as normal user with wrong password When user "Alice" requests these endpoints with "GET" using password "invalid" | endpoint | diff --git a/tests/acceptance/features/apiAuthOcs/ocsGETAuthOc10Issue32068.feature b/tests/acceptance/features/apiAuthOcs/ocsGETAuthOc10Issue32068.feature index b303afe9d981..3f1f08b82c20 100644 --- a/tests/acceptance/features/apiAuthOcs/ocsGETAuthOc10Issue32068.feature +++ b/tests/acceptance/features/apiAuthOcs/ocsGETAuthOc10Issue32068.feature @@ -4,9 +4,7 @@ Feature: current oC10 behavior for issue-32068 Background: Given user "Alice" has been created with default attributes and without skeleton files - @issue-32068 - @issue-ocis-reva-30 - @smokeTest + @issue-32068 @issue-ocis-reva-30 @smokeTest Scenario: using OCS anonymously When a user requests these endpoints with "GET" and no authentication | endpoint | @@ -28,14 +26,7 @@ Feature: current oC10 behavior for issue-32068 And the OCS status code of responses on all endpoints should be "997" #And the OCS status code of responses on all endpoints should be "401" - @issue-32068 - @issue-ocis-reva-11 - @issue-ocis-reva-30 - @issue-ocis-reva-31 - @issue-ocis-reva-32 - @issue-ocis-reva-33 - @issue-ocis-reva-34 - @issue-ocis-reva-35 + @issue-32068 @issue-ocis-reva-11 @issue-ocis-reva-30 @issue-ocis-reva-31 @issue-ocis-reva-32 @issue-ocis-reva-33 @issue-ocis-reva-34 @issue-ocis-reva-35 Scenario: using OCS with non-admin basic auth When the user "Alice" requests these endpoints with "GET" with basic auth | endpoint | @@ -67,9 +58,7 @@ Feature: current oC10 behavior for issue-32068 And the OCS status code of responses on all endpoints should be "997" #And the OCS status code of responses on all endpoints should be "401" - @issue-32068 @issue-ocis-reva-29 @issue-ocis-reva-30 - @smokeTest - @skipOnBruteForceProtection @issue-brute_force_protection-112 + @issue-32068 @issue-ocis-reva-29 @issue-ocis-reva-30 @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 Scenario: using OCS as normal user with wrong password When user "Alice" requests these endpoints with "GET" using password "invalid" | endpoint | diff --git a/tests/acceptance/features/apiAuthOcs/ocsPOSTAuth.feature b/tests/acceptance/features/apiAuthOcs/ocsPOSTAuth.feature index 443733bdb379..9b10a64ee6ff 100644 --- a/tests/acceptance/features/apiAuthOcs/ocsPOSTAuth.feature +++ b/tests/acceptance/features/apiAuthOcs/ocsPOSTAuth.feature @@ -4,9 +4,7 @@ Feature: auth Background: Given user "Alice" has been created with default attributes and without skeleton files - @issue-ocis-reva-30 - @smokeTest - @skipOnBruteForceProtection @issue-brute_force_protection-112 + @issue-ocis-reva-30 @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 Scenario: send POST requests to OCS endpoints as normal user with wrong password When user "Alice" requests these endpoints with "POST" including body "doesnotmatter" using password "invalid" about user "Alice" | endpoint | diff --git a/tests/acceptance/features/apiAuthOcs/ocsPUTAuth.feature b/tests/acceptance/features/apiAuthOcs/ocsPUTAuth.feature index 75a4aa219af0..c6101795534b 100644 --- a/tests/acceptance/features/apiAuthOcs/ocsPUTAuth.feature +++ b/tests/acceptance/features/apiAuthOcs/ocsPUTAuth.feature @@ -4,9 +4,7 @@ Feature: auth Background: Given user "another-admin" has been created with default attributes and without skeleton files - @issue-ocis-reva-30 - @smokeTest - @skipOnBruteForceProtection @issue-brute_force_protection-112 + @issue-ocis-reva-30 @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 Scenario: send PUT request to OCS endpoints as admin with wrong password Given user "another-admin" has been added to group "admin" When user "another-admin" requests these endpoints with "PUT" including body "doesnotmatter" using password "invalid" about user "Alice" diff --git a/tests/acceptance/features/apiAuthWebDav/webDavDELETEAuth.feature b/tests/acceptance/features/apiAuthWebDav/webDavDELETEAuth.feature index daf4cd286445..c905a7180b8e 100644 --- a/tests/acceptance/features/apiAuthWebDav/webDavDELETEAuth.feature +++ b/tests/acceptance/features/apiAuthWebDav/webDavDELETEAuth.feature @@ -12,8 +12,7 @@ Feature: delete file/folder And user "Alice" has created folder "/FOLDER" And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt" - @smokeTest - @skipOnBruteForceProtection @issue-brute_force_protection-112 + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 Scenario: send DELETE requests to webDav endpoints as normal user with wrong password When user "Alice" requests these endpoints with "DELETE" using password "invalid" about user "Alice" | endpoint | @@ -92,6 +91,7 @@ Feature: delete file/folder | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | Then the HTTP status code of responses on all endpoints should be "401" + Scenario: send DELETE requests to webDav endpoints using valid password and username of different user When user "Brian" requests these endpoints with "DELETE" using the password of user "Alice" | endpoint | @@ -111,8 +111,7 @@ Feature: delete file/folder | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | Then the HTTP status code of responses on all endpoints should be "401" - @smokeTest - @skipOnBruteForceProtection @issue-brute_force_protection-112 + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 Scenario: send DELETE requests to webDav endpoints without any authentication When a user requests these endpoints with "DELETE" with no authentication about user "Alice" | endpoint | diff --git a/tests/acceptance/features/apiAuthWebDav/webDavLOCKAuth.feature b/tests/acceptance/features/apiAuthWebDav/webDavLOCKAuth.feature index c37d6f710c77..9588a9582681 100644 --- a/tests/acceptance/features/apiAuthWebDav/webDavLOCKAuth.feature +++ b/tests/acceptance/features/apiAuthWebDav/webDavLOCKAuth.feature @@ -12,8 +12,7 @@ Feature: LOCK file/folder And user "Alice" has created folder "/FOLDER" And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt" - @smokeTest - @skipOnBruteForceProtection @issue-brute_force_protection-112 + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 Scenario: send LOCK requests to webDav endpoints as normal user with wrong password When user "Alice" requests these endpoints with "LOCK" including body "doesnotmatter" using password "invalid" about user "Alice" | endpoint | @@ -33,8 +32,7 @@ Feature: LOCK file/folder | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | Then the HTTP status code of responses on all endpoints should be "401" - @smokeTest - @skipOnBruteForceProtection @issue-brute_force_protection-112 + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 Scenario: send LOCK requests to webDav endpoints as normal user with no password When user "Alice" requests these endpoints with "LOCK" including body "doesnotmatter" using password "" about user "Alice" | endpoint | @@ -78,6 +76,7 @@ Feature: LOCK file/folder | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | Then the HTTP status code of responses on all endpoints should be "409" + Scenario: send LOCK requests to webDav endpoints using invalid username but correct password When user "usero" requests these endpoints with "LOCK" including body "doesnotmatter" using the password of user "Alice" | endpoint | @@ -97,6 +96,7 @@ Feature: LOCK file/folder | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | Then the HTTP status code of responses on all endpoints should be "401" + Scenario: send LOCK requests to webDav endpoints using valid password and username of different user When user "Brian" requests these endpoints with "LOCK" including body "doesnotmatter" using the password of user "Alice" | endpoint | @@ -116,8 +116,7 @@ Feature: LOCK file/folder | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | Then the HTTP status code of responses on all endpoints should be "401" - @smokeTest - @skipOnBruteForceProtection @issue-brute_force_protection-112 + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 Scenario: send LOCK requests to webDav endpoints without any authentication When a user requests these endpoints with "LOCK" with body "doesnotmatter" and no authentication about user "Alice" | endpoint | diff --git a/tests/acceptance/features/apiAuthWebDav/webDavMKCOLAuth.feature b/tests/acceptance/features/apiAuthWebDav/webDavMKCOLAuth.feature index b61d602c496a..464235e3ffb3 100644 --- a/tests/acceptance/features/apiAuthWebDav/webDavMKCOLAuth.feature +++ b/tests/acceptance/features/apiAuthWebDav/webDavMKCOLAuth.feature @@ -8,8 +8,7 @@ Feature: create folder using MKCOL And user "Alice" has created folder "/FOLDER" And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt" - @smokeTest - @skipOnBruteForceProtection @issue-brute_force_protection-112 + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 Scenario: send MKCOL requests to webDav endpoints as normal user with wrong password When user "Alice" requests these endpoints with "MKCOL" including body "doesnotmatter" using password "invalid" about user "Alice" | endpoint | @@ -29,8 +28,7 @@ Feature: create folder using MKCOL | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | Then the HTTP status code of responses on all endpoints should be "401" - @smokeTest - @skipOnBruteForceProtection @issue-brute_force_protection-112 + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 Scenario: send MKCOL requests to webDav endpoints as normal user with no password When user "Alice" requests these endpoints with "MKCOL" including body "doesnotmatter" using password "" about user "Alice" | endpoint | @@ -78,6 +76,7 @@ Feature: create folder using MKCOL | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | Then the HTTP status code of responses on all endpoints should be "409" + Scenario: send MKCOL requests to webDav endpoints using invalid username but correct password When user "usero" requests these endpoints with "MKCOL" including body "doesnotmatter" using the password of user "Alice" | endpoint | @@ -97,6 +96,7 @@ Feature: create folder using MKCOL | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | Then the HTTP status code of responses on all endpoints should be "401" + Scenario: send MKCOL 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 "MKCOL" including body "doesnotmatter" using the password of user "Alice" @@ -118,8 +118,7 @@ Feature: create folder using MKCOL | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | Then the HTTP status code of responses on all endpoints should be "401" - @smokeTest - @skipOnBruteForceProtection @issue-brute_force_protection-112 + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 Scenario: send MKCOL requests to webDav endpoints without any authentication When a user requests these endpoints with "MKCOL" with body "doesnotmatter" and no authentication about user "Alice" | endpoint | diff --git a/tests/acceptance/features/apiAuthWebDav/webDavMOVEAuth.feature b/tests/acceptance/features/apiAuthWebDav/webDavMOVEAuth.feature index 06c2712e97c8..b2e2723b5b79 100644 --- a/tests/acceptance/features/apiAuthWebDav/webDavMOVEAuth.feature +++ b/tests/acceptance/features/apiAuthWebDav/webDavMOVEAuth.feature @@ -11,8 +11,7 @@ Feature: MOVE file/folder And user "Alice" has created folder "/FOLDER" And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt" - @smokeTest - @skipOnBruteForceProtection @issue-brute_force_protection-112 + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 Scenario: send MOVE requests to webDav endpoints as normal user with wrong password When user "Alice" requests these endpoints with "MOVE" using password "invalid" about user "Alice" | endpoint | @@ -32,8 +31,7 @@ Feature: MOVE file/folder | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | Then the HTTP status code of responses on all endpoints should be "401" - @smokeTest - @skipOnBruteForceProtection @issue-brute_force_protection-112 + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 Scenario: send MOVE requests to webDav endpoints as normal user with no password When user "Alice" requests these endpoints with "MOVE" using password "" about user "Alice" | endpoint | @@ -71,6 +69,7 @@ Feature: MOVE file/folder | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | Then the HTTP status code of responses on all endpoints should be "403" + Scenario: send MOVE requests to webDav endpoints using invalid username but correct password When user "usero" requests these endpoints with "MOVE" using the password of user "Alice" | endpoint | @@ -90,6 +89,7 @@ Feature: MOVE file/folder | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | Then the HTTP status code of responses on all endpoints should be "401" + Scenario: send MOVE requests to webDav endpoints using valid password and username of different user When user "Brian" requests these endpoints with "MOVE" using the password of user "Alice" | endpoint | @@ -109,8 +109,7 @@ Feature: MOVE file/folder | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | Then the HTTP status code of responses on all endpoints should be "401" - @smokeTest - @skipOnBruteForceProtection @issue-brute_force_protection-112 + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 Scenario: send MOVE requests to webDav endpoints without any authentication When a user requests these endpoints with "MOVE" with no authentication about user "Alice" | endpoint | diff --git a/tests/acceptance/features/apiAuthWebDav/webDavPOSTAuth.feature b/tests/acceptance/features/apiAuthWebDav/webDavPOSTAuth.feature index 8cc9493a9a11..1e90596219f9 100644 --- a/tests/acceptance/features/apiAuthWebDav/webDavPOSTAuth.feature +++ b/tests/acceptance/features/apiAuthWebDav/webDavPOSTAuth.feature @@ -12,8 +12,7 @@ Feature: get file info using POST And user "Alice" has created folder "/FOLDER" And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt" - @smokeTest - @skipOnBruteForceProtection @issue-brute_force_protection-112 + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 Scenario: send POST requests to webDav endpoints as normal user with wrong password When user "Alice" requests these endpoints with "POST" including body "doesnotmatter" using password "invalid" about user "Alice" | endpoint | @@ -33,8 +32,7 @@ Feature: get file info using POST | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | Then the HTTP status code of responses on all endpoints should be "401" - @smokeTest - @skipOnBruteForceProtection @issue-brute_force_protection-112 + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 Scenario: send POST requests to webDav endpoints as normal user with no password When user "Alice" requests these endpoints with "POST" including body "doesnotmatter" using password "" about user "Alice" | endpoint | @@ -72,6 +70,7 @@ Feature: get file info using POST | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | Then the HTTP status code of responses on all endpoints should be "404" + Scenario: send POST requests to webDav endpoints using invalid username but correct password When user "usero" requests these endpoints with "POST" including body "doesnotmatter" using the password of user "Alice" | endpoint | @@ -91,6 +90,7 @@ Feature: get file info using POST | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | Then the HTTP status code of responses on all endpoints should be "401" + Scenario: send POST requests to webDav endpoints using valid password and username of different user When user "Brian" requests these endpoints with "POST" including body "doesnotmatter" using the password of user "Alice" | endpoint | @@ -110,8 +110,7 @@ Feature: get file info using POST | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | Then the HTTP status code of responses on all endpoints should be "401" - @smokeTest - @skipOnBruteForceProtection @issue-brute_force_protection-112 + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 Scenario: send POST requests to webDav endpoints without any authentication When a user requests these endpoints with "POST" with body "doesnotmatter" and no authentication about user "Alice" | endpoint | diff --git a/tests/acceptance/features/apiAuthWebDav/webDavPROPFINDAuth.feature b/tests/acceptance/features/apiAuthWebDav/webDavPROPFINDAuth.feature index c619aae69ea1..d1bfee252d5b 100644 --- a/tests/acceptance/features/apiAuthWebDav/webDavPROPFINDAuth.feature +++ b/tests/acceptance/features/apiAuthWebDav/webDavPROPFINDAuth.feature @@ -11,8 +11,7 @@ Feature: get file info using PROPFIND And user "Alice" has created folder "/FOLDER" And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt" - @smokeTest - @skipOnBruteForceProtection @issue-brute_force_protection-112 + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 Scenario: send PROPFIND requests to webDav endpoints as normal user with wrong password When user "Alice" requests these endpoints with "PROPFIND" including body "doesnotmatter" using password "invalid" about user "Alice" | endpoint | @@ -32,8 +31,7 @@ Feature: get file info using PROPFIND | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | Then the HTTP status code of responses on all endpoints should be "401" - @smokeTest - @skipOnBruteForceProtection @issue-brute_force_protection-112 + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 Scenario: send PROPFIND requests to webDav endpoints as normal user with no password When user "Alice" requests these endpoints with "PROPFIND" including body "doesnotmatter" using password "" about user "Alice" | endpoint | @@ -71,6 +69,7 @@ Feature: get file info using PROPFIND | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | Then the HTTP status code of responses on all endpoints should be "404" + Scenario: send PROPFIND requests to webDav endpoints using invalid username but correct password When user "usero" requests these endpoints with "PROPFIND" including body "doesnotmatter" using the password of user "Alice" | endpoint | @@ -90,6 +89,7 @@ Feature: get file info using PROPFIND | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | Then the HTTP status code of responses on all endpoints should be "401" + Scenario: send PROPFIND requests to webDav endpoints using valid password and username of different user When user "Brian" requests these endpoints with "PROPFIND" including body "doesnotmatter" using the password of user "Alice" | endpoint | @@ -109,8 +109,7 @@ Feature: get file info using PROPFIND | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | Then the HTTP status code of responses on all endpoints should be "401" - @smokeTest - @skipOnBruteForceProtection @issue-brute_force_protection-112 + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 Scenario: send PROPFIND requests to webDav endpoints without any authentication When a user requests these endpoints with "PROPFIND" with body "doesnotmatter" and no authentication about user "Alice" | endpoint | diff --git a/tests/acceptance/features/apiAuthWebDav/webDavPROPPATCHAuth.feature b/tests/acceptance/features/apiAuthWebDav/webDavPROPPATCHAuth.feature index 5e5b829c10c5..3c1b893b9ccd 100644 --- a/tests/acceptance/features/apiAuthWebDav/webDavPROPPATCHAuth.feature +++ b/tests/acceptance/features/apiAuthWebDav/webDavPROPPATCHAuth.feature @@ -12,8 +12,7 @@ Feature: PROPPATCH file/folder And user "Alice" has created folder "/FOLDER" And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt" - @smokeTest - @skipOnBruteForceProtection @issue-brute_force_protection-112 + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 Scenario: send PROPPATCH requests to webDav endpoints as normal user with wrong password When user "Alice" requests these endpoints with "PROPPATCH" including body "doesnotmatter" using password "invalid" about user "Alice" | endpoint | @@ -33,8 +32,7 @@ Feature: PROPPATCH file/folder | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | Then the HTTP status code of responses on all endpoints should be "401" - @smokeTest - @skipOnBruteForceProtection @issue-brute_force_protection-112 + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 Scenario: send PROPPATCH requests to webDav endpoints as normal user with no password When user "Alice" requests these endpoints with "PROPPATCH" including body "doesnotmatter" using password "" about user "Alice" | endpoint | @@ -72,6 +70,7 @@ Feature: PROPPATCH file/folder | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | Then the HTTP status code of responses on all endpoints should be "404" + Scenario: send PROPPATCH requests to webDav endpoints using invalid username but correct password When user "usero" requests these endpoints with "PROPPATCH" including body "doesnotmatter" using the password of user "Alice" | endpoint | @@ -91,6 +90,7 @@ Feature: PROPPATCH file/folder | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | Then the HTTP status code of responses on all endpoints should be "401" + Scenario: send PROPPATCH requests to webDav endpoints using valid password and username of different user When user "Brian" requests these endpoints with "PROPPATCH" including body "doesnotmatter" using the password of user "Alice" | endpoint | @@ -110,8 +110,7 @@ Feature: PROPPATCH file/folder | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | Then the HTTP status code of responses on all endpoints should be "401" - @smokeTest - @skipOnBruteForceProtection @issue-brute_force_protection-112 + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 Scenario: send PROPPATCH requests to webDav endpoints without any authentication When a user requests these endpoints with "PROPPATCH" with body "doesnotmatter" and no authentication about user "Alice" | endpoint | diff --git a/tests/acceptance/features/apiAuthWebDav/webDavPUTAuth.feature b/tests/acceptance/features/apiAuthWebDav/webDavPUTAuth.feature index 3dbc0558a530..b12dba719e08 100644 --- a/tests/acceptance/features/apiAuthWebDav/webDavPUTAuth.feature +++ b/tests/acceptance/features/apiAuthWebDav/webDavPUTAuth.feature @@ -12,8 +12,7 @@ Feature: get file info using PUT And user "Alice" has created folder "/FOLDER" And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt" - @smokeTest - @skipOnBruteForceProtection @issue-brute_force_protection-112 + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 Scenario: send PUT requests to webDav endpoints as normal user with wrong password When user "Alice" requests these endpoints with "PUT" including body "doesnotmatter" using password "invalid" about user "Alice" | endpoint | @@ -33,8 +32,7 @@ Feature: get file info using PUT | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | Then the HTTP status code of responses on all endpoints should be "401" - @smokeTest - @skipOnBruteForceProtection @issue-brute_force_protection-112 + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 Scenario: send PUT requests to webDav endpoints as normal user with no password When user "Alice" requests these endpoints with "PUT" including body "doesnotmatter" using password "" about user "Alice" | endpoint | @@ -118,8 +116,7 @@ Feature: get file info using PUT | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | Then the HTTP status code of responses on all endpoints should be "401" - @smokeTest - @skipOnBruteForceProtection @issue-brute_force_protection-112 + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 Scenario: send PUT requests to webDav endpoints without any authentication When a user requests these endpoints with "PUT" with body "doesnotmatter" and no authentication about user "Alice" | endpoint | diff --git a/tests/acceptance/features/apiCapabilities/capabilities.feature b/tests/acceptance/features/apiCapabilities/capabilities.feature index 8374a4de6d87..59e1777ed5ae 100644 --- a/tests/acceptance/features/apiCapabilities/capabilities.feature +++ b/tests/acceptance/features/apiCapabilities/capabilities.feature @@ -948,8 +948,7 @@ Feature: capabilities | capability | path_to_element | value | | files | blacklisted_files_regex | \.(part\|filepart)$ | - @smokeTest - @skipOnOcV10.7 @skipOnOcV10.8 @skipOnOcV10.9.0 @skipOnOcV10.9.1 + @smokeTest @skipOnOcV10.7 @skipOnOcV10.8 @skipOnOcV10.9.0 @skipOnOcV10.9.1 # This is a new capability after 10.9.1 Scenario: getting default capabilities with admin user When the administrator retrieves the capabilities using the capabilities API diff --git a/tests/acceptance/features/apiComments/comments.feature b/tests/acceptance/features/apiComments/comments.feature index 9a8169b30179..20641d996a31 100644 --- a/tests/acceptance/features/apiComments/comments.feature +++ b/tests/acceptance/features/apiComments/comments.feature @@ -22,6 +22,7 @@ Feature: Comments And the single response should contain a property "oc:comments-unread" with value "0" And the single response should contain a property "oc:comments-href" with value "%a_comment_url%" + Scenario: Getting info on comments for a folder using the endpoint Given user "Alice" has created folder "/PARENT" And user "Alice" has commented with content "My first comment" on folder "/PARENT" @@ -38,6 +39,7 @@ Feature: Comments And the single response should contain a property "oc:comments-unread" with value "0" And the single response should contain a property "oc:comments-href" with value "%a_comment_url%" + Scenario: Getting more info about comments using REPORT method Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToComment.txt" And user "Alice" has commented with content "My first comment" on file "/myFileToComment.txt" @@ -53,6 +55,7 @@ Feature: Comments | actorDisplayName | %displayname% | | message | My first comment | + Scenario: Getting more info about comments using PROPFIND method Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToComment.txt" And user "Alice" has commented with content "My first comment" on file "myFileToComment.txt" diff --git a/tests/acceptance/features/apiComments/createComments.feature b/tests/acceptance/features/apiComments/createComments.feature index 9970af6b5d11..c22b7a108df6 100644 --- a/tests/acceptance/features/apiComments/createComments.feature +++ b/tests/acceptance/features/apiComments/createComments.feature @@ -22,6 +22,7 @@ Feature: Comments | 😀 🤖 | | नेपालि | + Scenario: Creating a comment on a shared file belonging to another user Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToComment.txt" And user "Alice" has shared file "/myFileToComment.txt" with user "Brian" @@ -33,6 +34,7 @@ Feature: Comments | Brian | A comment from sharee | | Alice | A comment from sharer | + Scenario: sharee comments on a group shared file Given group "grp1" has been created And user "Brian" has been added to group "grp1" @@ -44,6 +46,7 @@ Feature: Comments | user | comment | | Brian | Comment from sharee | + Scenario: sharee comments on read-only shared file Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToComment.txt" And user "Alice" has created a share with settings @@ -57,6 +60,7 @@ Feature: Comments | user | comment | | Brian | Comment from sharee | + Scenario: sharee comments on upload-only shared folder Given user "Alice" has created folder "/FOLDER_TO_SHARE" And user "Alice" has created a share with settings @@ -68,6 +72,7 @@ Feature: Comments Then the HTTP status code should be "501" And user "Alice" should have 0 comments on file "/FOLDER_TO_SHARE" + Scenario: Creating a comment on a folder belonging to myself Given user "Alice" has created folder "/FOLDER" When user "Alice" comments with content "My first comment" on folder "/FOLDER" using the WebDAV API @@ -76,6 +81,7 @@ Feature: Comments | user | comment | | Alice | My first comment | + Scenario: Creating a comment on a shared folder belonging to another user Given user "Alice" has created folder "/FOLDER_TO_SHARE" And user "Alice" has shared folder "/FOLDER_TO_SHARE" with user "Brian" @@ -87,6 +93,7 @@ Feature: Comments | Brian | A comment from sharee | | Alice | A comment from sharer | + Scenario: sharee comments on a group shared folder Given group "grp1" has been created And user "Brian" has been added to group "grp1" diff --git a/tests/acceptance/features/apiComments/deleteComments.feature b/tests/acceptance/features/apiComments/deleteComments.feature index 3911d61af7b9..70094c7299f4 100644 --- a/tests/acceptance/features/apiComments/deleteComments.feature +++ b/tests/acceptance/features/apiComments/deleteComments.feature @@ -20,6 +20,7 @@ Feature: Comments | 😀 🤖 | | नेपालि | + Scenario: Deleting a comment on a file belonging to myself having several comments Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToComment.txt" And user "Alice" has commented with content "My first comment" on file "/myFileToComment.txt" @@ -45,6 +46,7 @@ Feature: Comments Then the HTTP status code should be "204" And user "Brian" should have 1 comments on file "/myFileToComment.txt" + Scenario: Deleting my own comments on a folder belonging to myself Given user "Alice" has created folder "/FOLDER_TO_COMMENT_AND_DELETE" And user "Alice" has commented with content "My first comment" on folder "/FOLDER_TO_COMMENT_AND_DELETE" @@ -52,6 +54,7 @@ Feature: Comments Then the HTTP status code should be "204" And user "Alice" should have 0 comments on folder "/FOLDER_TO_COMMENT_AND_DELETE" + Scenario: Deleting a comment on a folder belonging to myself having several comments Given user "Alice" has created folder "/FOLDER_TO_COMMENT" And user "Alice" has commented with content "My first comment" on folder "/FOLDER_TO_COMMENT" @@ -73,6 +76,7 @@ Feature: Comments Then the HTTP status code should be "204" And user "Brian" should have 1 comments on folder "/FOLDER_TO_COMMENT" + Scenario: deleting a folder removes existing comments on the folder Given user "Alice" has created folder "/FOLDER_TO_DELETE" When user "Alice" comments with content "This should be deleted" on folder "/FOLDER_TO_DELETE" using the WebDAV API @@ -95,6 +99,7 @@ Feature: Comments | user | comment | | deleted_users | Comment from sharee | + Scenario: deleting a content owner deletes the comment Given user "Alice" has created folder "/FOLDER_TO_COMMENT" And user "Alice" has commented with content "Comment from owner" on folder "/FOLDER_TO_COMMENT" diff --git a/tests/acceptance/features/apiComments/editComments.feature b/tests/acceptance/features/apiComments/editComments.feature index 0cb61c87fc51..49eed785a182 100644 --- a/tests/acceptance/features/apiComments/editComments.feature +++ b/tests/acceptance/features/apiComments/editComments.feature @@ -49,6 +49,7 @@ Feature: Comments | user | comment | | Brian | Sharee comment | + Scenario: Edit my own comments on a folder belonging to myself Given user "Alice" has created folder "FOLDER" And user "Alice" has commented with content "Folder owner comment" on folder "/FOLDER" diff --git a/tests/acceptance/features/apiFavorites/favorites.feature b/tests/acceptance/features/apiFavorites/favorites.feature index ac87d10215b2..553c4c1af856 100644 --- a/tests/acceptance/features/apiFavorites/favorites.feature +++ b/tests/acceptance/features/apiFavorites/favorites.feature @@ -120,6 +120,7 @@ Feature: favorite | dav_version | | spaces | + Scenario Outline: Get favorited elements of a subfolder Given using DAV path And user "Alice" has created folder "/subfolder" @@ -249,6 +250,7 @@ Feature: favorite | old | | new | + Scenario Outline: favoriting a folder does not change the favorite state of elements inside the folder Given using DAV path When user "Alice" favorites element "/PARENT/parent.txt" using the WebDAV API @@ -302,4 +304,4 @@ Feature: favorite Examples: | dav_version | | old | - | new | \ No newline at end of file + | new | diff --git a/tests/acceptance/features/apiFederationToRoot1/etagPropagation.feature b/tests/acceptance/features/apiFederationToRoot1/etagPropagation.feature index 461a45f46db9..58792f5173f3 100644 --- a/tests/acceptance/features/apiFederationToRoot1/etagPropagation.feature +++ b/tests/acceptance/features/apiFederationToRoot1/etagPropagation.feature @@ -10,6 +10,7 @@ Feature: propagation of etags between federated and local server And user "Brian" has been created with default attributes and without skeleton files And user "Brian" has created folder "PARENT" + Scenario: Overwrite a federated shared folder as sharer propagates etag for recipient Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE" And user "Alice" from server "REMOTE" has accepted the last pending share @@ -46,6 +47,7 @@ Feature: propagation of etags between federated and local server And the etag of element "/" of user "Alice" on server "REMOTE" should not have changed #And the etag of element "/" of user "Alice" on server "REMOTE" should have changed + Scenario: Overwrite a federated shared folder as recipient propagates etag for recipient Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE" And user "Alice" from server "REMOTE" has accepted the last pending share @@ -55,6 +57,7 @@ Feature: propagation of etags between federated and local server Then the HTTP status code should be "201" And the etag of element "/PARENT (2)" of user "Alice" on server "REMOTE" should have changed + Scenario: Overwrite a federated shared folder as recipient propagates etag to root folder for recipient Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE" And user "Alice" from server "REMOTE" has accepted the last pending share @@ -64,6 +67,7 @@ Feature: propagation of etags between federated and local server Then the HTTP status code should be "201" And the etag of element "/" of user "Alice" on server "REMOTE" should have changed + Scenario: Overwrite a federated shared folder as recipient propagates etag for sharer Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE" And user "Brian" has stored etag of element "/PARENT" @@ -73,6 +77,7 @@ Feature: propagation of etags between federated and local server Then the HTTP status code should be "201" And the etag of element "/PARENT" of user "Brian" on server "LOCAL" should have changed + Scenario: Overwrite a federated shared folder as recipient propagates etag to root folder for sharer Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE" And user "Brian" has stored etag of element "/" @@ -82,6 +87,7 @@ Feature: propagation of etags between federated and local server Then the HTTP status code should be "201" And the etag of element "/" of user "Brian" on server "LOCAL" should have changed + Scenario: Adding a file to a federated shared folder as recipient propagates etag to root folder for sharer Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE" And user "Brian" has stored etag of element "/" diff --git a/tests/acceptance/features/apiFederationToRoot1/federated.feature b/tests/acceptance/features/apiFederationToRoot1/federated.feature index ec7840d2c30e..583cd566b71d 100644 --- a/tests/acceptance/features/apiFederationToRoot1/federated.feature +++ b/tests/acceptance/features/apiFederationToRoot1/federated.feature @@ -63,6 +63,7 @@ Feature: federated | 1 | 100 | | 2 | 200 | + Scenario Outline: Federated sharee can see the pending share Given using OCS API version "" And using server "REMOTE" @@ -87,6 +88,7 @@ Feature: federated | 1 | 100 | | 2 | 200 | + Scenario Outline: Federated sharee requests information of only one share Given using OCS API version "" And using server "REMOTE" @@ -139,6 +141,7 @@ Feature: federated | 1 | 100 | | 2 | 200 | + Scenario Outline: sending a GET request to a pending federated share is not valid Given using OCS API version "" When user "Brian" sends HTTP method "GET" to OCS API endpoint "/apps/files_sharing/api/v1/remote_shares/pending/12" @@ -149,6 +152,7 @@ Feature: federated | 1 | | 2 | + Scenario Outline: sending a GET request to a nonexistent federated share Given using OCS API version "" When user "Brian" sends HTTP method "GET" to OCS API endpoint "/apps/files_sharing/api/v1/remote_shares/9999999999" @@ -159,6 +163,7 @@ Feature: federated | 1 | 404 | 200 | | 2 | 404 | 404 | + Scenario Outline: accept a pending federated share Given using OCS API version "" And using server "REMOTE" @@ -172,6 +177,7 @@ Feature: federated | 1 | 100 | | 2 | 200 | + Scenario Outline: Reshare a federated shared file Given using OCS API version "" And using server "REMOTE" @@ -207,6 +213,7 @@ Feature: federated | 1 | 100 | | 2 | 200 | + Scenario Outline: Overwrite a federated shared file as recipient - local server shares - remote server receives Given using OCS API version "" And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" @@ -221,6 +228,7 @@ Feature: federated | 1 | | 2 | + Scenario Outline: Overwrite a federated shared file as recipient - remote server shares - local server receives Given using OCS API version "" And using server "REMOTE" @@ -236,6 +244,7 @@ Feature: federated | 1 | | 2 | + Scenario Outline: Overwrite a file in a federated shared folder as recipient - local server shares - remote server receives Given using OCS API version "" And user "Brian" has created folder "PARENT" @@ -250,6 +259,7 @@ Feature: federated | 1 | | 2 | + Scenario Outline: Overwrite a file in a federated shared folder as recipient - remote server shares - local server receives Given using OCS API version "" And using server "REMOTE" @@ -265,6 +275,7 @@ Feature: federated | 1 | | 2 | + Scenario Outline: Overwrite a federated shared file as recipient using old chunking Given using OCS API version "" And using server "REMOTE" @@ -285,6 +296,7 @@ Feature: federated | 1 | | 2 | + Scenario Outline: Overwrite a file in a federated shared folder as recipient using old chunking Given using OCS API version "" And using server "REMOTE" @@ -305,6 +317,7 @@ Feature: federated | 1 | | 2 | + Scenario Outline: Federated sharee deletes an accepted federated share Given using OCS API version "" And using server "REMOTE" @@ -363,6 +376,7 @@ Feature: federated | 1 | | 2 | + Scenario Outline: Federated sharee deletes a pending federated share Given using server "REMOTE" And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" @@ -417,6 +431,7 @@ Feature: federated | 1 | | 2 | + Scenario Outline: Trusted server handshake does not require authenticated requests - we force 403 by sending an empty body Given using OCS API version "" When user "UNAUTHORIZED_USER" requests shared secret using the federation API @@ -459,6 +474,7 @@ Feature: federated When user "Brian" uploads file "filesForUpload/textfile.txt" to filenames based on "/PARENT/testquota.txt" with all mechanisms using the WebDAV API Then the HTTP status code of all upload responses should be "507" + Scenario Outline: share of a folder to a federated user who already has a folder with the same name Given using server "REMOTE" And user "Alice" has created folder "/zzzfolder" @@ -488,6 +504,7 @@ Feature: federated | 1 | 100 | | 2 | 200 | + Scenario Outline: share of a file to the federated user who already has a file with the same name Given using server "REMOTE" And user "Alice" has uploaded file with content "remote content" to "/randomfile.txt" @@ -543,6 +560,7 @@ Feature: federated And the content of file "/randomfile (2).txt" for user "Carol" on server "LOCAL" should be "remote content" And the content of file "/randomfile.txt" for user "Carol" on server "LOCAL" should be "local content" + Scenario: receive a federated share that has the same name as a previously received local share Given using server "REMOTE" And user "Alice" has created folder "/zzzfolder" diff --git a/tests/acceptance/features/apiFederationToRoot2/federated.feature b/tests/acceptance/features/apiFederationToRoot2/federated.feature index eadc7a29b5f7..44da0a4108fd 100644 --- a/tests/acceptance/features/apiFederationToRoot2/federated.feature +++ b/tests/acceptance/features/apiFederationToRoot2/federated.feature @@ -37,6 +37,7 @@ Feature: federated And as "Brian" file "textfile1.txt" should not exist And url "%remote_server%" should be a trusted server + Scenario: Federated share with "Auto add server" enabled Given using server "REMOTE" And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile1.txt" @@ -51,6 +52,7 @@ Feature: federated And as "Brian" file "textfile1.txt" should exist And url "%remote_server%" should be a trusted server + Scenario: Federated share with "Auto add server" disabled Given using server "REMOTE" And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile1.txt" @@ -104,6 +106,7 @@ Feature: federated And the HTTP status code should be "200" And as "Brian" file "textfile1.txt" should not exist + Scenario Outline: federated share receiver sees the original content of a received file Given using server "REMOTE" And user "Alice" has uploaded file with content "thisContentIsVisible" to "/file-to-share" @@ -117,6 +120,7 @@ Feature: federated | 1 | | 2 | + Scenario Outline: federated share receiver sees the original content of a received file in multiple levels of folders Given using server "REMOTE" And user "Alice" has created folder "/PARENT" @@ -132,6 +136,7 @@ Feature: federated | 1 | | 2 | + Scenario Outline: remote federated share receiver adds files/folders in the federated share Given user "Brian" has created folder "/PARENT" And user "Brian" has created folder "/PARENT/RandomFolder" @@ -153,6 +158,7 @@ Feature: federated | 1 | | 2 | + Scenario Outline: local federated share receiver adds files/folders in the federated share Given using server "REMOTE" And user "Alice" has created folder "/PARENT" @@ -175,6 +181,7 @@ Feature: federated | 1 | | 2 | + Scenario Outline: local federated share receiver deletes files/folders of the received share Given using server "REMOTE" And user "Alice" has created folder "/PARENT" @@ -197,6 +204,7 @@ Feature: federated | 1 | | 2 | + Scenario Outline: remote federated share receiver deletes files/folders of the received share Given user "Brian" has created folder "/PARENT" And user "Brian" has created folder "/PARENT/RandomFolder" @@ -218,6 +226,7 @@ Feature: federated | 1 | | 2 | + Scenario Outline: local federated share receiver renames files/folders of the received share Given using server "REMOTE" And user "Alice" has created folder "/PARENT" @@ -242,6 +251,7 @@ Feature: federated | 1 | | 2 | + Scenario Outline: remote federated share receiver renames files/folders of the received share Given user "Brian" has created folder "/PARENT" And user "Brian" has created folder "/PARENT/RandomFolder" @@ -265,6 +275,7 @@ Feature: federated | 1 | | 2 | + Scenario Outline: sharer modifies the share which was shared to the federated share receiver Given using server "REMOTE" And user "Alice" has created folder "/PARENT" @@ -282,6 +293,7 @@ Feature: federated | 1 | | 2 | + Scenario Outline: sharer adds files/folders in the share which was shared to the federated share receiver Given using server "REMOTE" And user "Alice" has created folder "/PARENT" @@ -303,6 +315,7 @@ Feature: federated | 1 | | 2 | + Scenario Outline: sharer deletes files/folders of the share which was shared to the federated share receiver Given using server "REMOTE" And user "Alice" has created folder "/PARENT" @@ -324,6 +337,7 @@ Feature: federated | 1 | | 2 | + Scenario Outline: sharer renames files/folders of the share which was shared to the federated share receiver Given using server "REMOTE" And user "Alice" has created folder "/PARENT" @@ -347,6 +361,7 @@ Feature: federated | 1 | | 2 | + Scenario Outline: sharer unshares the federated share and the receiver no longer sees the files/folders Given user "Brian" has created folder "/PARENT" And user "Brian" has created folder "/PARENT/RandomFolder" @@ -365,6 +380,7 @@ Feature: federated | 1 | 100 | | 2 | 200 | + Scenario Outline: federated share receiver can move the location of the received share and changes are correctly seen at both ends Given user "Brian" has created folder "/PARENT" And user "Brian" has created folder "/PARENT/RandomFolder" @@ -391,6 +407,7 @@ Feature: federated | 1 | | 2 | + Scenario Outline: federated sharer can move the location of the received share and changes are correctly seen at both ends Given user "Brian" has created folder "/PARENT" And user "Brian" has created folder "/PARENT/RandomFolder" @@ -416,6 +433,7 @@ Feature: federated | 1 | | 2 | + Scenario Outline: Both Incoming and Outgoing federation shares are allowed Given parameter "incoming_server2server_share_enabled" of app "files_sharing" has been set to "yes" And parameter "outgoing_server2server_share_enabled" of app "files_sharing" has been set to "yes" @@ -441,6 +459,7 @@ Feature: federated | 1 | 100 | | 2 | 200 | + Scenario Outline: Incoming federation shares are allowed but outgoing federation shares are restricted Given parameter "incoming_server2server_share_enabled" of app "files_sharing" has been set to "yes" And parameter "outgoing_server2server_share_enabled" of app "files_sharing" has been set to "no" @@ -464,6 +483,7 @@ Feature: federated | 1 | 100 | 200 | | 2 | 200 | 403 | + Scenario Outline: Incoming federation shares are restricted but outgoing federation shares are allowed Given parameter "incoming_server2server_share_enabled" of app "files_sharing" has been set to "no" And parameter "outgoing_server2server_share_enabled" of app "files_sharing" has been set to "yes" @@ -484,6 +504,7 @@ Feature: federated | 1 | 201, 200 | | 2 | 201, 403 | + Scenario Outline: Both Incoming and outgoing federation shares are restricted Given parameter "incoming_server2server_share_enabled" of app "files_sharing" has been set to "no" And parameter "outgoing_server2server_share_enabled" of app "files_sharing" has been set to "no" @@ -507,6 +528,7 @@ Feature: federated | 1 | 201, 200 | | 2 | 201, 403 | + Scenario Outline: Incoming and outgoing federation shares are enabled for local server but incoming federation shares are restricted for remote server Given using server "REMOTE" And parameter "incoming_server2server_share_enabled" of app "files_sharing" has been set to "no" @@ -534,6 +556,7 @@ Feature: federated | 1 | 100 | 201, 200 | | 2 | 200 | 201, 403 | + Scenario Outline: Incoming and outgoing federation shares are enabled for local server but outgoing federation shares are restricted for remote server Given using server "REMOTE" And parameter "incoming_server2server_share_enabled" of app "files_sharing" has been set to "yes" diff --git a/tests/acceptance/features/apiFederationToShares1/etagPropagation.feature b/tests/acceptance/features/apiFederationToShares1/etagPropagation.feature index e6ccb3287683..84f56851c329 100644 --- a/tests/acceptance/features/apiFederationToShares1/etagPropagation.feature +++ b/tests/acceptance/features/apiFederationToShares1/etagPropagation.feature @@ -49,6 +49,7 @@ Feature: propagation of etags between federated and local server And the etag of element "/" of user "Alice" on server "REMOTE" should not have changed #And the etag of element "/" of user "Alice" on server "REMOTE" should have changed + Scenario: Overwrite a federated shared folder as recipient propagates etag for recipient Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE" And user "Alice" from server "REMOTE" has accepted the last pending share @@ -58,6 +59,7 @@ Feature: propagation of etags between federated and local server Then the HTTP status code should be "201" And the etag of element "/Shares/PARENT" of user "Alice" on server "REMOTE" should have changed + Scenario: Overwrite a federated shared folder as recipient propagates etag to root folder for recipient Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE" And user "Alice" from server "REMOTE" has accepted the last pending share @@ -67,6 +69,7 @@ Feature: propagation of etags between federated and local server Then the HTTP status code should be "201" And the etag of element "/" of user "Alice" on server "REMOTE" should have changed + Scenario: Overwrite a federated shared folder as recipient propagates etag for sharer Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE" And user "Brian" has stored etag of element "/PARENT" @@ -76,6 +79,7 @@ Feature: propagation of etags between federated and local server Then the HTTP status code should be "201" And the etag of element "/PARENT" of user "Brian" on server "LOCAL" should have changed + Scenario: Overwrite a federated shared folder as recipient propagates etag to root folder for sharer Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE" And user "Brian" has stored etag of element "/" @@ -85,6 +89,7 @@ Feature: propagation of etags between federated and local server Then the HTTP status code should be "201" And the etag of element "/" of user "Brian" on server "LOCAL" should have changed + Scenario: Adding a file to a federated shared folder as recipient propagates etag to root folder for sharer Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE" And user "Brian" has stored etag of element "/" diff --git a/tests/acceptance/features/apiFederationToShares2/federated.feature b/tests/acceptance/features/apiFederationToShares2/federated.feature index 4ce131b81f5e..2d834af0fa48 100644 --- a/tests/acceptance/features/apiFederationToShares2/federated.feature +++ b/tests/acceptance/features/apiFederationToShares2/federated.feature @@ -71,7 +71,6 @@ Feature: federated Then as "Brian" file "Shares/textfile1.txt" should exist And url "%remote_server%" should not be a trusted server - @issue-35839 @skipOnOcV10 Scenario: enable "Add server automatically" once a federated share was created successfully Given using server "REMOTE" @@ -600,7 +599,6 @@ Feature: federated | 1 | 100 | 201,200 | | 2 | 200 | 201,403 | - @skipOnOcV10.3 @skipOnOcV10.4 @skipOnOcV10.5.0 Scenario Outline: Federated share a file with another server with expiration date Given using OCS API version "" @@ -633,7 +631,6 @@ Feature: federated | 1 | 100 | | 2 | 200 | - @skipOnOcV10.3 @skipOnOcV10.4 @skipOnOcV10.5.0 Scenario Outline: Federated sharing with default expiration date enabled but not enforced, user shares without specifying expireDate Given using OCS API version "" @@ -649,7 +646,6 @@ Feature: federated | 1 | 100 | # | 2 | 200 | - @skipOnOcV10.3 @skipOnOcV10.4 @skipOnOcV10.5.0 Scenario Outline: Federated sharing with default expiration date enabled and enforced, user shares without specifying expireDate Given using OCS API version "" @@ -666,7 +662,6 @@ Feature: federated | 1 | 100 | | 2 | 200 | - @skipOnOcV10.3 @skipOnOcV10.4 @skipOnOcV10.5.0 Scenario Outline: Federated sharing with default expiration date disabled Given using OCS API version "" @@ -682,7 +677,6 @@ Feature: federated | 1 | 100 | | 2 | 200 | - @skipOnOcV10.3 @skipOnOcV10.4 @skipOnOcV10.5.0 Scenario Outline: Expiration date is enforced for federated share, user modifies expiration date Given using OCS API version "" @@ -702,7 +696,6 @@ Feature: federated | 1 | 100 | | 2 | 200 | - @skipOnOcV10.3 @skipOnOcV10.4 @skipOnOcV10.5.0 Scenario Outline: Federated sharing with default expiration date enabled and enforced, user updates the share with expiration date more than the default Given using OCS API version "" @@ -721,7 +714,6 @@ Feature: federated | 1 | 200 | | 2 | 404 | - @skipOnOcV10.6 @skipOnOcV10.7 @skipOnOcV10.8.0 Scenario Outline: User modifies expiration date for federated reshare of a file with another server with default expiration date Given using OCS API version "" @@ -745,7 +737,6 @@ Feature: federated | 1 | 100 | | 2 | 200 | - @skipOnOcV10.6 @skipOnOcV10.7 @skipOnOcV10.8.0 Scenario Outline: User modifies expiration date more than the default for federated reshare of a file Given using OCS API version "" diff --git a/tests/acceptance/features/apiMain/appManagement.feature b/tests/acceptance/features/apiMain/appManagement.feature index 4cc9fbabfb65..72bc31d8e191 100644 --- a/tests/acceptance/features/apiMain/appManagement.feature +++ b/tests/acceptance/features/apiMain/appManagement.feature @@ -12,6 +12,7 @@ Feature: AppManagement And the administrator enables app "updatetest" Then the installed version of "updatetest" should be "2.0.1" + Scenario: Update of patch version of an app in apps-external, previous version in apps folder Given these apps' path has been configured additionally with following attributes: | dir | is_writable | @@ -23,6 +24,7 @@ Feature: AppManagement And the administrator enables app "updatetest" Then the installed version of "updatetest" should be "2.0.1" + Scenario: Update of patch version of an app in apps-external Given these apps' path has been configured additionally with following attributes: | dir | is_writable | @@ -34,6 +36,7 @@ Feature: AppManagement And the administrator enables app "updatetest" Then the installed version of "updatetest" should be "2.0.1" + Scenario: Update of patch version of an app but update is put in alternative folder Given these apps' path has been configured additionally with following attributes: | dir | is_writable | @@ -45,6 +48,7 @@ Feature: AppManagement And the administrator enables app "updatetest" Then the installed version of "updatetest" should be "2.0.1" + Scenario: Update of patch version of an app previously in apps-external but update is put in alternative folder Given these apps' path has been configured additionally with following attributes: | dir | is_writable | diff --git a/tests/acceptance/features/apiMain/caldav.feature b/tests/acceptance/features/apiMain/caldav.feature index 15e00d5f6008..aabfd038b993 100644 --- a/tests/acceptance/features/apiMain/caldav.feature +++ b/tests/acceptance/features/apiMain/caldav.feature @@ -26,8 +26,7 @@ Feature: caldav And the CalDAV exception should be "Sabre\DAV\Exception\NotFound" And the CalDAV message should be "Node with name 'MyCalendar' could not be found" - @caldav - @smokeTest + @caldav @smokeTest Scenario: Creating a new calendar Given user "Alice" has successfully created a calendar named "MyCalendar" When user "Alice" requests calendar "%username%/MyCalendar" of user "Alice" using the new WebDAV API diff --git a/tests/acceptance/features/apiMain/carddav.feature b/tests/acceptance/features/apiMain/carddav.feature index 6b3053293c2f..8765e3a10e14 100644 --- a/tests/acceptance/features/apiMain/carddav.feature +++ b/tests/acceptance/features/apiMain/carddav.feature @@ -26,8 +26,7 @@ Feature: carddav And the CardDAV exception should be "Sabre\DAV\Exception\NotFound" And the CardDAV message should be "Addressbook with name 'MyAddressbook' could not be found" - @carddav - @smokeTest + @carddav @smokeTest Scenario: Creating a new addressbook Given user "Alice" has successfully created an address book named "MyAddressbook" When user "Alice" requests address book "%username%/MyAddressbook" of user "Alice" using the new WebDAV API diff --git a/tests/acceptance/features/apiMain/checksums.feature b/tests/acceptance/features/apiMain/checksums.feature index 056b75ca7273..766f55cac816 100644 --- a/tests/acceptance/features/apiMain/checksums.feature +++ b/tests/acceptance/features/apiMain/checksums.feature @@ -188,8 +188,7 @@ Feature: checksums | dav_version | | spaces | - @files_sharing-app-required - @issue-ocis-reva-196 @skipOnOcV10.6 @skipOnOcV10.7 @skipOnOcV10.8.0 + @files_sharing-app-required @issue-ocis-reva-196 @skipOnOcV10.6 @skipOnOcV10.7 @skipOnOcV10.8.0 Scenario Outline: Sharing a file with checksum should return the checksum in the propfind using new DAV path Given the administrator has set the default folder for received shares to "Shares" And auto-accept shares has been disabled @@ -205,8 +204,7 @@ Feature: checksums | dav_version | | new | - @files_sharing-app-required - @issue-ocis-reva-196 @skipOnOcV10 + @files_sharing-app-required @issue-ocis-reva-196 @skipOnOcV10 Scenario Outline: Modifying a shared file should return correct checksum in the propfind using new DAV path Given the administrator has set the default folder for received shares to "Shares" And auto-accept shares has been disabled @@ -231,7 +229,6 @@ Feature: checksums And user "Alice" moves new chunk file with id "chunking-42" to "/myChunkedFile.txt" with checksum "SHA1:5d84d61b03fdacf813640f5242d309721e0629b1" using the WebDAV API Then the HTTP status code of responses on all endpoints should be "201" - @issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321 Scenario: Upload new DAV chunked file where checksum does not match Given using new DAV path @@ -311,6 +308,7 @@ Feature: checksums | dav_version | | spaces | + Scenario Outline: Upload a file where checksum does match Given using DAV path When user "Alice" uploads file with checksum "SHA1:ce5582148c6f0c1282335b87df5ed4be4b781399" and content "Some Text" to "/chksumtst.txt" using the WebDAV API @@ -422,8 +420,7 @@ Feature: checksums | dav_version | | spaces | - @skipOnStorage:ceph @skipOnStorage:scality @files_primary_s3-issue-224 - @issue-ocis-reva-196 + @skipOnStorage:ceph @skipOnStorage:scality @files_primary_s3-issue-224 @issue-ocis-reva-196 Scenario Outline: Uploading a file with invalid SHA1 checksum overwriting an existing file Given using DAV path And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" @@ -452,8 +449,7 @@ Feature: checksums Then the HTTP status code of responses on each endpoint should be "201, 201, 204" respectively And the content of file "/textfile0.txt" for user "Alice" should be "BBBBBCCCCC" - @skipOnStorage:ceph @skipOnStorage:scality @files_primary_s3-issue-224 - @issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321 + @skipOnStorage:ceph @skipOnStorage:scality @files_primary_s3-issue-224 @issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321 Scenario: Upload overwriting a file with new chunking and invalid checksum Given using new DAV path And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" diff --git a/tests/acceptance/features/apiMain/external-storage.feature b/tests/acceptance/features/apiMain/external-storage.feature index 5e3d5589c0e2..4b1a7e057640 100644 --- a/tests/acceptance/features/apiMain/external-storage.feature +++ b/tests/acceptance/features/apiMain/external-storage.feature @@ -24,6 +24,7 @@ Feature: external-storage | token | A_TOKEN | | mimetype | httpd/unix-directory | + Scenario: Move a file into storage Given these users have been created with default attributes and small skeleton files: | username | @@ -35,6 +36,7 @@ Feature: external-storage And as "Brian" file "/local_storage/foo1/textfile0.txt" should exist And as "Alice" file "/local_storage/foo1/textfile0.txt" should exist + Scenario: Move a file out of storage Given these users have been created with default attributes and small skeleton files: | username | @@ -71,6 +73,7 @@ Feature: external-storage And as "Alice" file "/fileInsideLocalStorage.txt" should exist And as "Alice" file "/local_storage/foo1/fileInsideLocalStorage.txt" should exist + Scenario: Download a file that exists in filecache but not storage fails with 404 Given user "Alice" has been created with default attributes and small skeleton files And user "Alice" has created folder "/local_storage/foo3" @@ -82,6 +85,7 @@ Feature: external-storage # in the folder. The file cache will be cleared after the local storage is scanned. And as "Alice" file "local_storage/foo3/textfile0.txt" should exist + Scenario: Upload a file to external storage while quota is set on home storage Given user "Alice" has been created with default attributes and small skeleton files And the quota of user "Alice" has been set to "1 B" @@ -89,6 +93,7 @@ Feature: external-storage Then the HTTP status code of all upload responses should be "201" And as "Alice" the files uploaded to "/local_storage/testquota.txt" with all mechanisms should exist + Scenario Outline: query OCS endpoint for information about the mount Given using OCS API version "" And user "Alice" has been created with default attributes and small skeleton files diff --git a/tests/acceptance/features/apiMain/quota.feature b/tests/acceptance/features/apiMain/quota.feature index 537ba1af01fe..87b415f881b4 100644 --- a/tests/acceptance/features/apiMain/quota.feature +++ b/tests/acceptance/features/apiMain/quota.feature @@ -309,6 +309,7 @@ Feature: quota Then the HTTP status code should be "201" And as "Brian" file "testquota.txt" should exist + Scenario: User with zero quota can upload an empty file Given the quota of user "Alice" has been set to "0 B" When user "Alice" uploads file with content "" to "testquota.txt" using the WebDAV API