diff --git a/.drone.yml b/.drone.yml index 867e3c8d7..432bda38b 100644 --- a/.drone.yml +++ b/.drone.yml @@ -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 + #with php 7.2 and core master - TEST_SUITE: web-acceptance TEST_SOURCE: ldap @@ -715,6 +726,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 + #with php 7.2 and core stable10 - TEST_SUITE: web-acceptance TEST_SOURCE: ldap @@ -785,6 +807,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 + #with php 5.6 and core stable10 - TEST_SUITE: web-acceptance TEST_SOURCE: ldap @@ -891,6 +924,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 diff --git a/tests/acceptance/config/behat.yml b/tests/acceptance/config/behat.yml index 33eb9f06b..7d5adf094 100644 --- a/tests/acceptance/config/behat.yml +++ b/tests/acceptance/config/behat.yml @@ -156,6 +156,15 @@ default: - OccContext: - TrashbinContext: + apiProvisioningLDAP: + paths: + - '%paths.base%/../features/apiProvisioningLDAP' + context: *common_ldap_suite_context + contexts: + - UserLdapGeneralContext: + - UserLdapUsersContext: + - FeatureContext: *common_feature_context_params + webUIUserLDAP: paths: - '%paths.base%/../features/webUIUserLDAP' diff --git a/tests/acceptance/features/apiProvisioningLDAP/groups.feature b/tests/acceptance/features/apiProvisioningLDAP/groups.feature new file mode 100644 index 000000000..4c8754964 --- /dev/null +++ b/tests/acceptance/features/apiProvisioningLDAP/groups.feature @@ -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 "" + When the administrator sends a group creation request for group "simplegroup" using the provisioning API + Then the OCS status code should be "" + And the HTTP status code should be "" + 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 "" + 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 "" + And the HTTP status code should be "" + 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 "" + 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 "" + And the HTTP status code should be "" + 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 "" + 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 "" + And the HTTP status code should be "" + 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 "" + When the LDAP users are resynced + And the administrator deletes group "grp1" using the provisioning API + Then the OCS status code should be "" + And the HTTP status code should be "" + 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 "" + 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 "" + And the HTTP status code should be "" + 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 "" + 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 "" + And the HTTP status code should be "" + 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 "" + When the administrator adds user "user1" to group "grp2" using the provisioning API + Then the OCS status code should be "" + And the HTTP status code should be "" + 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 "" + When the administrator sends a group creation request for group "grp1" using the provisioning API + Then the OCS status code should be "" + And the HTTP status code should be "" + And group "grp1" should exist + Examples: + | ocs-api-version | ocs-status-code | http-status-code | + | 1 | 102 | 200 | + | 2 | 400 | 400 | \ No newline at end of file diff --git a/tests/acceptance/features/apiProvisioningLDAP/users.feature b/tests/acceptance/features/apiProvisioningLDAP/users.feature new file mode 100644 index 000000000..c7894208f --- /dev/null +++ b/tests/acceptance/features/apiProvisioningLDAP/users.feature @@ -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 "" + 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 "" + And the HTTP status code should be "" + 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 "" + 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 "" + And the HTTP status code should be "" + 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 "" + 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 "brand-new-user@example.com" using the provisioning API + Then the OCS status code should be "" + And the HTTP status code should be "" + And the email address of user "brand-new-user" should be "brand-new-user@example.com" + 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 "" + 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 "" + And the HTTP status code should be "" + 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 "" + 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 "" + And the HTTP status code should be "" + 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 "" + 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 "" + And the HTTP status code should be "" + 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 "" + 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 "" + And the HTTP status code should be "" + 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 "" + 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 "" + And the HTTP status code should be "" + 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 "" + When the administrator sets the ldap attribute "mail" of the entry "uid=user1,ou=TestUsers" to "ldapuser@oc.com" + And the LDAP users are resynced + And the administrator changes the email of user "user1" to "apiuser@example.com" using the provisioning API + Then the OCS status code should be "" + And the HTTP status code should be "" + # And the email address of user "user1" should be "ldapuser@example.com" + And the email address of user "user1" should be "apiuser@example.com" + 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 "" + When the administrator deletes user "user0" using the provisioning API + Then the OCS status code should be "" + And the HTTP status code should be "" + 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 "" + When the administrator sends a user creation request for user "user0" password "%alt1%" using the provisioning API + Then the OCS status code should be "" + And the HTTP status code should be "" + 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 | \ No newline at end of file diff --git a/tests/acceptance/features/bootstrap/UserLdapGeneralContext.php b/tests/acceptance/features/bootstrap/UserLdapGeneralContext.php index 74ccb2c3a..7236e3a8f 100644 --- a/tests/acceptance/features/bootstrap/UserLdapGeneralContext.php +++ b/tests/acceptance/features/bootstrap/UserLdapGeneralContext.php @@ -47,6 +47,8 @@ class UserLdapGeneralContext extends RawMinkContext implements Context { private $ldapGroupsOU; private $toDeleteDNs = []; private $toDeleteLdapConfigs = []; + private $ldapCreatedUsers = []; + private $ldapCreatedGroups = []; /** * @@ -241,6 +243,7 @@ public function deleteValueFromLdapAttribute($value, $attribute, $entry) { /** * @When the administrator imports this ldif data: + * @Given the administrator has imported this ldif data: * * @param PyStringNode $ldifData * @@ -437,13 +440,28 @@ public function connectToLdap($suiteParameters) { */ public function importLdifData($ldifData) { $items = Zend\Ldap\Ldif\Encoder::decode($ldifData); - if (isset($items['dn'])) { //only one item in the ldif data $this->ldap->add($items['dn'], $items); + if (isset($items['uid'])) { + $this->featureContext->addUserToCreatedUsersList($items['uid'][0], $items['userpassword'][0]); + \array_push($this->ldapCreatedUsers, $items['uid'][0]); + } + if (isset($items['objectclass']) && $items['objectclass'][0] === 'posixGroup') { + $this->featureContext->addGroupToCreatedGroupsList($items['cn'][0]); + \array_push($this->ldapCreatedGroups, $items['cn'][0]); + } } else { foreach ($items as $item) { $this->ldap->add($item['dn'], $item); + if (isset($item['uid'])) { + $this->featureContext->addUserToCreatedUsersList($item['uid'][0], $item['userpassword'][0]); + \array_push($this->ldapCreatedUsers, $item['uid'][0]); + } + if (isset($item['objectclass']) && \in_array('posixGroup', $item['objectclass'])) { + $this->featureContext->addGroupToCreatedGroupsList($item['cn'][0]); + \array_push($this->ldapCreatedGroups, $item['cn'][0]); + } } } } @@ -483,6 +501,14 @@ public function deleteUserAndGroups() { foreach ($this->toDeleteDNs as $dn) { $this->ldap->delete($dn, true); } + + foreach ($this->ldapCreatedUsers as $user) { + $this->featureContext->rememberThatUserIsNotExpectedToExist($user); + } + foreach ($this->ldapCreatedGroups as $group) { + $this->featureContext->rememberThatGroupIsNotExpectedToExist($group); + } + $this->theLdapUsersHaveBeenResynced(); }