-
Notifications
You must be signed in to change notification settings - Fork 17
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add API provisioning tests for users and groups in ldap
- Loading branch information
Showing
5 changed files
with
372 additions
and
1 deletion.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
136 changes: 136 additions & 0 deletions
136
tests/acceptance/features/apiProvisioningLDAP/groups.feature
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,136 @@ | ||
| @api | ||
| Feature: manage groups | ||
| As an administrator | ||
| I want to be able to add, delete and modify groups via the Provisioning API | ||
| So that I can easily manage groups when user LDAP is enabled | ||
|
|
||
| Background: | ||
| Given user "brand-new-user" has been created with default attributes in the database user backend | ||
|
|
||
| Scenario Outline: admin creates a database group when ldap is enabled | ||
| Given using OCS API version "<ocs-api-version>" | ||
| When the administrator sends a group creation request for group "simplegroup" using the provisioning API | ||
| Then the OCS status code should be "<ocs-status-code>" | ||
| And the HTTP status code should be "<http-status-code>" | ||
| And group "simplegroup" should exist | ||
| Examples: | ||
| | ocs-api-version | ocs-status-code | http-status-code | | ||
| | 1 | 100 | 200 | | ||
| | 2 | 200 | 200 | | ||
|
|
||
| Scenario Outline: adding a non ldap user to a database group when ldap is enabled | ||
| Given using OCS API version "<ocs-api-version>" | ||
| And group "simplegroup" has been created in the database user backend | ||
| When the administrator adds user "brand-new-user" to group "simplegroup" using the provisioning API | ||
| Then the OCS status code should be "<ocs-status-code>" | ||
| And the HTTP status code should be "<http-status-code>" | ||
| And user "brand-new-user" should belong to group "simplegroup" | ||
| Examples: | ||
| | ocs-api-version | ocs-status-code | http-status-code | | ||
| | 1 | 100 | 200 | | ||
| | 2 | 200 | 200 | | ||
|
|
||
| Scenario Outline: admin deletes a database group when ldap is enabled | ||
| Given using OCS API version "<ocs-api-version>" | ||
| And group "simplegroup" has been created in the database user backend | ||
| When the administrator deletes group "simplegroup" using the provisioning API | ||
| Then the OCS status code should be "<ocs-status-code>" | ||
| And the HTTP status code should be "<http-status-code>" | ||
| And group "simplegroup" should not exist | ||
| Examples: | ||
| | ocs-api-version | ocs-status-code | http-status-code | | ||
| | 1 | 100 | 200 | | ||
| | 2 | 200 | 200 | | ||
|
|
||
| Scenario Outline: admin gets users in the database group when ldap is enabled | ||
| Given using OCS API version "<ocs-api-version>" | ||
| And user "123" has been created with default attributes in the database user backend | ||
| And group "new-group" has been created in the database user backend | ||
| And user "brand-new-user" has been added to database backend group "new-group" | ||
| And user "123" has been added to database backend group "new-group" | ||
| When the administrator gets all the members of group "new-group" using the provisioning API | ||
| Then the OCS status code should be "<ocs-status-code>" | ||
| And the HTTP status code should be "<http-status-code>" | ||
| And the users returned by the API should be | ||
| | brand-new-user | | ||
| | 123 | | ||
| Examples: | ||
| | ocs-api-version | ocs-status-code | http-status-code | | ||
| | 1 | 100 | 200 | | ||
| | 2 | 200 | 200 | | ||
|
|
||
| Scenario Outline: Administrator tries to delete a ldap group | ||
| Given using OCS API version "<ocs-api-version>" | ||
| When the LDAP users are resynced | ||
| And the administrator deletes group "grp1" using the provisioning API | ||
| Then the OCS status code should be "<ocs-status-code>" | ||
| And the HTTP status code should be "<http-status-code>" | ||
| And group "grp1" should exist | ||
| Examples: | ||
| | ocs-api-version | ocs-status-code | http-status-code | | ||
| | 1 | 102 | 200 | | ||
| | 2 | 400 | 400 | | ||
|
|
||
| @issue-core-25224 | ||
| Scenario Outline: Add database user to ldap group | ||
| Given using OCS API version "<ocs-api-version>" | ||
| And user "db-user" has been created with default attributes in the database user backend | ||
| When the administrator adds user "db-user" to group "grp1" using the provisioning API | ||
| Then the OCS status code should be "<ocs-status-code>" | ||
| And the HTTP status code should be "<http-status-code>" | ||
| And user "brand-new-user" should not belong to group "grp1" | ||
| Examples: | ||
| | ocs-api-version | ocs-status-code | http-status-code | | ||
| | 1 | 100 | 200 | | ||
| | 2 | 200 | 200 | | ||
| # | 1 | 102 | 200 | | ||
| # | 2 | 400 | 400 | | ||
|
|
||
| Scenario Outline: Add ldap user to database group | ||
| Given using OCS API version "<ocs-api-version>" | ||
| And group "db-group" has been created in the database user backend | ||
| When the administrator adds user "user1" to group "db-group" using the provisioning API | ||
| Then the OCS status code should be "<ocs-status-code>" | ||
| And the HTTP status code should be "<http-status-code>" | ||
| And user "user1" should belong to group "db-group" | ||
| Examples: | ||
| | ocs-api-version | ocs-status-code | http-status-code | | ||
| | 1 | 100 | 200 | | ||
| | 2 | 200 | 200 | | ||
|
|
||
| @issue-core-25224 | ||
| Scenario Outline: Add ldap user to ldap group | ||
| Given using OCS API version "<ocs-api-version>" | ||
| When the administrator adds user "user1" to group "grp2" using the provisioning API | ||
| Then the OCS status code should be "<ocs-status-code>" | ||
| And the HTTP status code should be "<http-status-code>" | ||
| And user "user1" should not belong to group "grp2" | ||
| Examples: | ||
| | ocs-api-version | ocs-status-code | http-status-code | | ||
| | 1 | 100 | 200 | | ||
| | 2 | 200 | 200 | | ||
| # | 1 | 102 | 200 | | ||
| # | 2 | 400 | 400 | | ||
|
|
||
| Scenario: Add ldap group with same name as existing database group | ||
| Given group "db-group" has been created in the database user backend | ||
| When the administrator imports this ldif data: | ||
| """ | ||
| dn: cn=db-group,ou=TestGroups,dc=owncloud,dc=com | ||
| cn: db-group | ||
| gidnumber: 4700 | ||
| objectclass: top | ||
| objectclass: posixGroup | ||
| """ | ||
| And group "db-group_2" should exist | ||
|
|
||
| Scenario Outline: Add database group with same name as existing ldap group | ||
| Given using OCS API version "<ocs-api-version>" | ||
| When the administrator sends a group creation request for group "grp1" using the provisioning API | ||
| Then the OCS status code should be "<ocs-status-code>" | ||
| And the HTTP status code should be "<http-status-code>" | ||
| And group "grp1" should exist | ||
| Examples: | ||
| | ocs-api-version | ocs-status-code | http-status-code | | ||
| | 1 | 102 | 200 | | ||
| | 2 | 400 | 400 | |
156 changes: 156 additions & 0 deletions
156
tests/acceptance/features/apiProvisioningLDAP/users.feature
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,156 @@ | ||
| @api @provisioning_api-app-required | ||
| Feature: Manage users using the Provisioning API | ||
| As an administrator | ||
| I want to be able to add, delete and modify users via the Provisioning API | ||
| So that I can easily manage users when user LDAP is enabled | ||
|
|
||
| Scenario Outline: Admin creates a regular user | ||
| Given using OCS API version "<ocs-api-version>" | ||
| And 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 "<ocs-status-code>" | ||
| And the HTTP status code should be "<http-status-code>" | ||
| And user "brand-new-user" should exist | ||
| And user "brand-new-user" should be able to access a skeleton file | ||
| Examples: | ||
| | ocs-api-version | ocs-status-code | http-status-code | | ||
| | 1 | 100 | 200 | | ||
| | 2 | 200 | 200 | | ||
|
|
||
| Scenario Outline: Admin deletes a regular user | ||
| Given using OCS API version "<ocs-api-version>" | ||
| And user "brand-new-user" has been created with default attributes in the database user backend | ||
| When the administrator deletes user "brand-new-user" using the provisioning API | ||
| Then the OCS status code should be "<ocs-status-code>" | ||
| And the HTTP status code should be "<http-status-code>" | ||
| And user "brand-new-user" should not exist | ||
| Examples: | ||
| | ocs-api-version | ocs-status-code | http-status-code | | ||
| | 1 | 100 | 200 | | ||
| | 2 | 200 | 200 | | ||
|
|
||
| Scenario Outline: Administrator can edit a user email | ||
| Given using OCS API version "<ocs-api-version>" | ||
| And user "brand-new-user" has been created with default attributes in the database user backend | ||
| When the administrator changes the email of user "brand-new-user" to "[email protected]" using the provisioning API | ||
| Then the OCS status code should be "<ocs-status-code>" | ||
| And the HTTP status code should be "<http-status-code>" | ||
| And the email address of user "brand-new-user" should be "[email protected]" | ||
| Examples: | ||
| | ocs-api-version | ocs-status-code | http-status-code | | ||
| | 1 | 100 | 200 | | ||
| | 2 | 200 | 200 | | ||
|
|
||
| Scenario Outline: the administrator can edit a user display (the API allows editing the "display name" by using the key word "display") | ||
| Given using OCS API version "<ocs-api-version>" | ||
| And user "brand-new-user" has been created with default attributes in the database user backend | ||
| When the administrator changes the display of user "brand-new-user" to "A New User" using the provisioning API | ||
| Then the OCS status code should be "<ocs-status-code>" | ||
| And the HTTP status code should be "<http-status-code>" | ||
| And the display name of user "brand-new-user" should be "A New User" | ||
| Examples: | ||
| | ocs-api-version | ocs-status-code | http-status-code | | ||
| | 1 | 100 | 200 | | ||
| | 2 | 200 | 200 | | ||
|
|
||
| Scenario Outline: the administrator can edit a user display name | ||
| Given using OCS API version "<ocs-api-version>" | ||
| And user "brand-new-user" has been created with default attributes in the database user backend | ||
| When the administrator changes the display name of user "brand-new-user" to "A New User" using the provisioning API | ||
| Then the OCS status code should be "<ocs-status-code>" | ||
| And the HTTP status code should be "<http-status-code>" | ||
| And the display name of user "brand-new-user" should be "A New User" | ||
| Examples: | ||
| | ocs-api-version | ocs-status-code | http-status-code | | ||
| | 1 | 100 | 200 | | ||
| | 2 | 200 | 200 | | ||
|
|
||
| Scenario Outline: the administrator can edit a user quota | ||
| Given using OCS API version "<ocs-api-version>" | ||
| And user "brand-new-user" has been created with default attributes in the database user backend | ||
| When the administrator changes the quota of user "brand-new-user" to "12MB" using the provisioning API | ||
| Then the OCS status code should be "<ocs-status-code>" | ||
| And the HTTP status code should be "<http-status-code>" | ||
| And the quota definition of user "brand-new-user" should be "12 MB" | ||
| Examples: | ||
| | ocs-api-version | ocs-status-code | http-status-code | | ||
| | 1 | 100 | 200 | | ||
| | 2 | 200 | 200 | | ||
|
|
||
| @issue-core-33186 | ||
| Scenario Outline: admin tries to modify displayname of user for which an LDAP attribute is specified | ||
| Given using OCS API version "<ocs-api-version>" | ||
| When the administrator sets the ldap attribute "displayname" of the entry "uid=user1,ou=TestUsers" to "ldap user" | ||
| And the LDAP users are resynced | ||
| When the administrator changes the display of user "user1" to "A New User" using the provisioning API | ||
| Then the OCS status code should be "<ocs-status-code>" | ||
| And the HTTP status code should be "<http-status-code>" | ||
| And the display name of user "user1" should be "ldap user" | ||
| Examples: | ||
| | ocs-api-version | ocs-status-code | http-status-code | | ||
| | 1 | 100 | 200 | | ||
| | 2 | 200 | 200 | | ||
| # | 1 | 102 | 200 | | ||
| # | 2 | 400 | 400 | | ||
|
|
||
| @issue-core-33186 | ||
| Scenario Outline: admin tries to modify password of user for which an LDAP attribute is specified | ||
| Given using OCS API version "<ocs-api-version>" | ||
| When the administrator sets the ldap attribute "userpassword" of the entry "uid=user1,ou=TestUsers" to "ldap_password" | ||
| And the LDAP users are resynced | ||
| And the administrator resets the password of user "user1" to "api_password" using the provisioning API | ||
| Then the OCS status code should be "<ocs-status-code>" | ||
| And the HTTP status code should be "<http-status-code>" | ||
| And the content of file "textfile0.txt" for user "user1" using password "ldap_password" should be "ownCloud test text file 0" plus end-of-line | ||
| But user "brand-new-user" using password "api_password" should not be able to download file "textfile0.txt" | ||
| Examples: | ||
| | ocs-api-version | ocs-status-code | http-status-code | | ||
| | 1 | 100 | 200 | | ||
| | 2 | 200 | 200 | | ||
| # | 1 | 102 | 200 | | ||
| # | 2 | 400 | 400 | | ||
|
|
||
| @issue-core-33186 | ||
| Scenario Outline: admin tries to modify mail of user for which an LDAP attribute is specified | ||
| Given using OCS API version "<ocs-api-version>" | ||
| When the administrator sets the ldap attribute "mail" of the entry "uid=user1,ou=TestUsers" to "[email protected]" | ||
| And the LDAP users are resynced | ||
| And the administrator changes the email of user "user1" to "[email protected]" using the provisioning API | ||
| Then the OCS status code should be "<ocs-status-code>" | ||
| And the HTTP status code should be "<http-status-code>" | ||
| # And the email address of user "user1" should be "[email protected]" | ||
| And the email address of user "user1" should be "[email protected]" | ||
| Examples: | ||
| | ocs-api-version | ocs-status-code | http-status-code | | ||
| | 1 | 100 | 200 | | ||
| | 2 | 200 | 200 | | ||
| # | 1 | 102 | 200 | | ||
| # | 2 | 400 | 400 | | ||
|
|
||
| Scenario Outline: Administrator deletes a ldap user and resyncs again | ||
| Given using OCS API version "<ocs-api-version>" | ||
| When the administrator deletes user "user0" using the provisioning API | ||
| Then the OCS status code should be "<ocs-status-code>" | ||
| And the HTTP status code should be "<http-status-code>" | ||
| And user "user0" should not exist | ||
| When the LDAP users are resynced | ||
| Then user "user0" should exist | ||
| And the content of file "textfile0.txt" for user "user0" using password "123456" should be "ownCloud test text file 0" plus end-of-line | ||
| Examples: | ||
| | ocs-api-version | ocs-status-code | http-status-code | | ||
| | 1 | 100 | 200 | | ||
| | 2 | 200 | 200 | | ||
|
|
||
| Scenario Outline: Administrator tries to create a user with same name as existing ldap user | ||
| Given using OCS API version "<ocs-api-version>" | ||
| When the administrator sends a user creation request for user "user0" password "%alt1%" using the provisioning API | ||
| Then the OCS status code should be "<ocs-status-code>" | ||
| And the HTTP status code should be "<http-status-code>" | ||
| And the API should not return any data | ||
| And user "user0" should exist | ||
| And the content of file "textfile0.txt" for user "user0" using password "123456" should be "ownCloud test text file 0" plus end-of-line | ||
| But user "user0" using password "%alt1%" should not be able to download file "textfile0.txt" | ||
| Examples: | ||
| | ocs-api-version | ocs-status-code | http-status-code | | ||
| | 1 | 102 | 200 | | ||
| | 2 | 400 | 400 | |
Oops, something went wrong.