Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add API provisioning tests for users and groups in ldap #346

Merged
merged 1 commit into from
Feb 1, 2019
+383 −1
Merged

Add API provisioning tests for users and groups in ldap #346

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
44 changes: 44 additions & 0 deletions .drone.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -631,6 +631,17 @@ matrix:
NEED_INSTALL_APP: true
BEHAT_SUITE: apiUserLDAPSharing

- TEST_SUITE: api-acceptance
TEST_SOURCE: ldap
OC_VERSION: daily-master-qa
DB_TYPE: mysql
DB_NAME: owncloud
PHP_VERSION: 7.1
NEED_SERVER: true
NEED_CORE: true
NEED_INSTALL_APP: true
BEHAT_SUITE: apiProvisioningLDAP

# acceptance tests - ldap specific
# with php 7.2 and core master
- TEST_SUITE: web-acceptance
Expand Down Expand Up @@ -716,6 +727,17 @@ matrix:
NEED_INSTALL_APP: true
BEHAT_SUITE: apiUserLDAPSharing

- TEST_SUITE: api-acceptance
TEST_SOURCE: ldap
OC_VERSION: daily-master-qa
DB_TYPE: pgsql
DB_NAME: owncloud
PHP_VERSION: 7.2
NEED_SERVER: true
NEED_CORE: true
NEED_INSTALL_APP: true
BEHAT_SUITE: apiProvisioningLDAP

# acceptance tests - ldap specific
# with php 7.2 and core stable10
- TEST_SUITE: web-acceptance
Expand Down Expand Up @@ -787,6 +809,17 @@ matrix:
NEED_INSTALL_APP: true
BEHAT_SUITE: apiUserLDAPSharing

- TEST_SUITE: api-acceptance
TEST_SOURCE: ldap
OC_VERSION: daily-stable10-qa
DB_TYPE: mysql
DB_NAME: owncloud
PHP_VERSION: 7.2
NEED_SERVER: true
NEED_CORE: true
NEED_INSTALL_APP: true
BEHAT_SUITE: apiProvisioningLDAP

# acceptance tests - ldap specific
# with php 5.6 and core stable10
- TEST_SUITE: web-acceptance
Expand Down Expand Up @@ -894,6 +927,17 @@ matrix:
NEED_INSTALL_APP: true
BEHAT_SUITE: apiUserLDAPSharing

- TEST_SUITE: api-acceptance
TEST_SOURCE: ldap
OC_VERSION: daily-stable10-qa
DB_TYPE: mysql
DB_NAME: owncloud
PHP_VERSION: 5.6
NEED_SERVER: true
NEED_CORE: true
NEED_INSTALL_APP: true
BEHAT_SUITE: apiProvisioningLDAP

# acceptance tests - UI tests from core
- TEST_SUITE: acceptance
TEST_SOURCE: core-webUI
Expand Down
10 changes: 10 additions & 0 deletions tests/acceptance/config/behat.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -156,6 +156,16 @@ default:
- OccContext:
- TrashbinContext:

apiProvisioningLDAP:
paths:
- '%paths.base%/../features/apiProvisioningLDAP'
context: *common_ldap_suite_context
contexts:
- UserLdapGeneralContext:
- UserLdapUsersContext:
- FeatureContext: *common_feature_context_params
- OccContext:

webUIUserLDAP:
paths:
- '%paths.base%/../features/webUIUserLDAP'
Expand Down
140 changes: 140 additions & 0 deletions tests/acceptance/features/apiProvisioningLDAP/groups.feature
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,140 @@
@api @issue-268
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
# In drone the ldap groups have not synced yet. So this occ command is required to sync them.
And the administrator has invoked occ command "group:list"

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
"""
# In drone the ldap groups have not synced yet. So this occ command is required to sync them.
And the administrator has invoked occ command "group:list"
Then 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 tests/acceptance/features/apiProvisioningLDAP/users.feature
View file
Open in desktop
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 |
Loading