Skip to content

Commit

Permalink
Merge pull request #37377 from owncloud/adjust-user-roles-in-acceptan…
Browse files Browse the repository at this point in the history
…ce-tests

[Tests-Only] Adjust user roles in API acceptance tests
  • Loading branch information
phil-davis authored May 14, 2020
2 parents 5301af6 + f1816bd commit 1e348ec
Show file tree
Hide file tree
Showing 65 changed files with 873 additions and 887 deletions.
16 changes: 8 additions & 8 deletions tests/acceptance/features/apiAuth/tokenAuth.feature
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@ Feature: tokenAuth

Background:
Given using OCS API version "1"
And user "user1" has been created with default attributes and skeleton files
And user "user0" has been created with default attributes and skeleton files
And token auth has been enforced

Scenario: creating a user with basic auth should be blocked when token auth is enforced
Expand All @@ -14,25 +14,25 @@ Feature: tokenAuth

Scenario: moving a file should be blocked when token auth is enforced
Given using new DAV path
When user "user1" moves file "/textfile0.txt" to "/renamed_textfile0.txt" using the WebDAV API
When user "user0" moves file "/textfile0.txt" to "/renamed_textfile0.txt" using the WebDAV API
Then the HTTP status code should be "401"

@smokeTest
Scenario: can access files app with an app password when token auth is enforced
Given a new browser session for "user1" has been started
Given a new browser session for "user0" has been started
And the user has generated a new app password named "my-client"
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 "user1" has been started
Given a new browser session for "user0" has been started
And the user has generated a new app password named "my-client"
And the user has deleted the app password named "my-client"
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 "user1" has been started
Given a new browser session for "user0" has been started
And the user has generated a new app password named "my-client"
And the user has generated a new app password named "my-new-client"
When the user requests "/index.php/apps/files" with "GET" using app password named "my-client"
Expand All @@ -42,15 +42,15 @@ Feature: tokenAuth

@smokeTest
Scenario: cannot access files app with basic auth when token auth is enforced
When user "user1" requests "/index.php/apps/files" with "GET" using basic auth
When user "user0" 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 "user1" requests "/remote.php/webdav" with "PROPFIND" using basic auth
When user "user0" requests "/remote.php/webdav" with "PROPFIND" using basic auth
Then the HTTP status code should be "401"

@files_sharing-app-required
Scenario: using OCS with basic auth should be blocked when token auth is enforced
When user "user1" requests "/ocs/v1.php/apps/files_sharing/api/v1/remote_shares" with "GET" using basic auth
When user "user0" requests "/ocs/v1.php/apps/files_sharing/api/v1/remote_shares" with "GET" using basic auth
Then the OCS status code should be "997"
And the HTTP status code should be "401"
14 changes: 7 additions & 7 deletions tests/acceptance/features/apiCapabilities/capabilities.feature
Original file line number Diff line number Diff line change
Expand Up @@ -727,14 +727,14 @@ Feature: capabilities

Scenario: When not in any group that is excluded from sharing, can_share is on
Given parameter "shareapi_exclude_groups" of app "core" has been set to "yes"
And user "user1" has been created with default attributes and skeleton files
And user "user0" has been created with default attributes and skeleton files
And group "group1" has been created
And group "hash#group" has been created
And group "group-3" has been created
And group "ordinary-group" has been created
And user "user1" has been added to group "ordinary-group"
And user "user0" has been added to group "ordinary-group"
And parameter "shareapi_exclude_groups_list" of app "core" has been set to '["group1","hash#group","group-3"]'
When user "user1" retrieves the capabilities using the capabilities API
When user "user0" retrieves the capabilities using the capabilities API
Then the capabilities should contain
| capability | path_to_element | value |
| core | pollinterval | 60 |
Expand All @@ -756,15 +756,15 @@ Feature: capabilities

Scenario: When in a group that is excluded from sharing and in another group, can_share is off
Given parameter "shareapi_exclude_groups" of app "core" has been set to "yes"
And user "user2" has been created with default attributes and skeleton files
And user "user0" has been created with default attributes and skeleton files
And group "group1" has been created
And group "hash#group" has been created
And group "group-3" has been created
And group "ordinary-group" has been created
And user "user2" has been added to group "hash#group"
And user "user2" has been added to group "ordinary-group"
And user "user0" has been added to group "hash#group"
And user "user0" has been added to group "ordinary-group"
And parameter "shareapi_exclude_groups_list" of app "core" has been set to '["group1","hash#group","group-3"]'
When user "user2" retrieves the capabilities using the capabilities API
When user "user0" retrieves the capabilities using the capabilities API
Then the capabilities should contain
| capability | path_to_element | value |
| core | pollinterval | 60 |
Expand Down
66 changes: 33 additions & 33 deletions tests/acceptance/features/apiMain/quota.feature
Original file line number Diff line number Diff line change
Expand Up @@ -43,11 +43,11 @@ Feature: quota
| username |
| user0 |
| user1 |
And user "user1" has created folder "/testquota"
And user "user1" has shared folder "/testquota" with user "user0" with permissions "all"
And the quota of user "user0" has been set to "20 B"
And the quota of user "user1" has been set to "10 MB"
When user "user0" uploads file "filesForUpload/textfile.txt" to filenames based on "/testquota/testquota.txt" with all mechanisms using the WebDAV API
And user "user0" has created folder "/testquota"
And user "user0" has shared folder "/testquota" with user "user1" with permissions "all"
And the quota of user "user1" has been set to "20 B"
And the quota of user "user0" has been set to "10 MB"
When user "user1" uploads file "filesForUpload/textfile.txt" to filenames based on "/testquota/testquota.txt" with all mechanisms using the WebDAV API
Then the HTTP status code of all upload responses should be "201"

@files_sharing-app-required
Expand All @@ -56,26 +56,26 @@ Feature: quota
| username |
| user0 |
| user1 |
And user "user1" has created folder "/testquota"
And user "user1" has shared folder "/testquota" with user "user0" with permissions "all"
And the quota of user "user0" has been set to "10 MB"
And the quota of user "user1" has been set to "20 B"
When user "user0" uploads file "filesForUpload/textfile.txt" to filenames based on "/testquota/testquota.txt" with all mechanisms using the WebDAV API
And user "user0" has created folder "/testquota"
And user "user0" has shared folder "/testquota" with user "user1" with permissions "all"
And the quota of user "user1" has been set to "10 MB"
And the quota of user "user0" has been set to "20 B"
When user "user1" uploads file "filesForUpload/textfile.txt" to filenames based on "/testquota/testquota.txt" with all mechanisms using the WebDAV API
Then the HTTP status code of all upload responses should be "507"
Then as "user0" the files uploaded to "/testquota.txt" with all mechanisms should not exist
Then as "user1" the files uploaded to "/testquota.txt" with all mechanisms should not exist

@files_sharing-app-required
Scenario: Overwriting a file in received folder having enough quota
Given these users have been created with default attributes and skeleton files:
| username |
| user0 |
| user1 |
And user "user1" has created folder "/testquota"
And user "user1" has uploaded file with content "test" to "/testquota/testquota.txt"
And user "user1" has shared folder "/testquota" with user "user0" with permissions "all"
And the quota of user "user0" has been set to "20 B"
And the quota of user "user1" has been set to "10 MB"
When user "user0" overwrites from file "filesForUpload/textfile.txt" to file "/testquota/testquota.txt" with all mechanisms using the WebDAV API
And user "user0" has created folder "/testquota"
And user "user0" has uploaded file with content "test" to "/testquota/testquota.txt"
And user "user0" has shared folder "/testquota" with user "user1" with permissions "all"
And the quota of user "user1" has been set to "20 B"
And the quota of user "user0" has been set to "10 MB"
When user "user1" overwrites from file "filesForUpload/textfile.txt" to file "/testquota/testquota.txt" with all mechanisms using the WebDAV API
Then the HTTP status code of all upload responses should be between "201" and "204"

@files_sharing-app-required
Expand All @@ -84,12 +84,12 @@ Feature: quota
| username |
| user0 |
| user1 |
And user "user1" has created folder "/testquota"
And user "user1" has uploaded file with content "test" to "/testquota/testquota.txt"
And user "user1" has shared folder "/testquota" with user "user0" with permissions "all"
And the quota of user "user0" has been set to "10 MB"
And the quota of user "user1" has been set to "20 B"
When user "user0" overwrites from file "filesForUpload/textfile.txt" to file "/testquota/testquota.txt" with all mechanisms using the WebDAV API
And user "user0" has created folder "/testquota"
And user "user0" has uploaded file with content "test" to "/testquota/testquota.txt"
And user "user0" has shared folder "/testquota" with user "user1" with permissions "all"
And the quota of user "user1" has been set to "10 MB"
And the quota of user "user0" has been set to "20 B"
When user "user1" overwrites from file "filesForUpload/textfile.txt" to file "/testquota/testquota.txt" with all mechanisms using the WebDAV API
Then the HTTP status code of all upload responses should be "507"
And the content of file "/testquota/testquota.txt" for user "user0" should be "test"

Expand All @@ -101,11 +101,11 @@ Feature: quota
| username |
| user0 |
| user1 |
And user "user1" has uploaded file with content "test" to "/testquota.txt"
And user "user1" has shared file "/testquota.txt" with user "user0" with permissions "share,update,read"
And the quota of user "user0" has been set to "20 B"
And the quota of user "user1" has been set to "10 MB"
When user "user0" overwrites from file "filesForUpload/textfile.txt" to file "/testquota.txt" with all mechanisms using the WebDAV API
And user "user0" has uploaded file with content "test" to "/testquota.txt"
And user "user0" has shared file "/testquota.txt" with user "user1" with permissions "share,update,read"
And the quota of user "user1" has been set to "20 B"
And the quota of user "user0" has been set to "10 MB"
When user "user1" overwrites from file "filesForUpload/textfile.txt" to file "/testquota.txt" with all mechanisms using the WebDAV API
Then the HTTP status code of all upload responses should be between "201" and "204"

@files_sharing-app-required
Expand All @@ -114,10 +114,10 @@ Feature: quota
| username |
| user0 |
| user1 |
And user "user1" has uploaded file with content "test" to "/testquota.txt"
And user "user1" has shared file "/testquota.txt" with user "user0" with permissions "share,update,read"
And the quota of user "user0" has been set to "10 MB"
And the quota of user "user1" has been set to "20 B"
When user "user0" overwrites from file "filesForUpload/textfile.txt" to file "/testquota.txt" with all mechanisms using the WebDAV API
And user "user0" has uploaded file with content "test" to "/testquota.txt"
And user "user0" has shared file "/testquota.txt" with user "user1" with permissions "share,update,read"
And the quota of user "user1" has been set to "10 MB"
And the quota of user "user0" has been set to "20 B"
When user "user1" overwrites from file "filesForUpload/textfile.txt" to file "/testquota.txt" with all mechanisms using the WebDAV API
Then the HTTP status code of all upload responses should be "507"
And the content of file "/testquota.txt" for user "user0" should be "test"
18 changes: 9 additions & 9 deletions tests/acceptance/features/apiMain/userSync.feature
Original file line number Diff line number Diff line change
Expand Up @@ -3,9 +3,9 @@ Feature: Users sync

Background:
Given these users have been created with default attributes and without skeleton files:
| username |
| user0 |
| user1 |
| username |
| user0 |
| user1 |

Scenario Outline: Trying to sync a user when there is no external user backend
Given using OCS API version "<ocs-api-version>"
Expand All @@ -14,17 +14,17 @@ Feature: Users sync
And the OCS status code should be "<ocs-status-code>"
And the OCS status message should be ""
Examples:
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |

@TestAlsoOnExternalUserBackend
Scenario Outline: Trying to sync a user which does not exist
Given using OCS API version "<ocs-api-version>"
When the administrator tries to sync user "user10" using the OCS API
When the administrator tries to sync user "nonexistentuser" using the OCS API
Then the HTTP status code should be "<http-status-code>"
And the OCS status code should be "404"
And the OCS status message should be "User is not known in any user backend: user10"
And the OCS status message should be "User is not known in any user backend: nonexistentuser"
Examples:
| ocs-api-version | http-status-code |
| 1 | 200 |
Expand All @@ -33,7 +33,7 @@ Feature: Users sync
@TestAlsoOnExternalUserBackend
Scenario Outline: Trying to sync a user as another user which does not exist
Given using OCS API version "<ocs-api-version>"
When user "user20" tries to sync user "user1" using the OCS API
When user "nonexistentuser" tries to sync user "user1" using the OCS API
Then the HTTP status code should be "401"
And the OCS status code should be "997"
And the OCS status message should be "Unauthorised"
Expand Down
22 changes: 11 additions & 11 deletions tests/acceptance/features/apiProvisioning-v1/addUser.feature
Original file line number Diff line number Diff line change
Expand Up @@ -45,12 +45,12 @@ Feature: add user
And the API should not return any data

Scenario: Admin creates a new user and adds him directly to a group
Given group "newgroup" has been created
When the administrator sends a user creation request for user "newuser" password "%alt1%" group "newgroup" using the provisioning API
Given group "brand-new-group" has been created
When the administrator sends a user creation request for user "brand-new-user" password "%alt1%" group "brand-new-group" using the provisioning API
Then the OCS status code should be "100"
And the HTTP status code should be "200"
And user "newuser" should belong to group "newgroup"
And user "newuser" should be able to access a skeleton file
And user "brand-new-user" should belong to group "brand-new-group"
And user "brand-new-user" should be able to access a skeleton file

Scenario Outline: admin creates a user and specifies a password with special characters
Given user "brand-new-user" has been deleted
Expand Down Expand Up @@ -113,10 +113,10 @@ Feature: add user
And user "<username>" should exist
And user "<username>" should be able to access a skeleton file
Examples:
| username |
| user-1 |
| null |
| nil |
| 123 |
| -123 |
| 0.0 |
| username |
| user-1 |
| null |
| nil |
| 123 |
| -123 |
| 0.0 |
Loading

0 comments on commit 1e348ec

Please sign in to comment.