diff --git a/composer.lock b/composer.lock index 9e7ea14fe..b721dc9d1 100644 --- a/composer.lock +++ b/composer.lock @@ -9,21 +9,21 @@ "packages-dev": [ { "name": "bamarni/composer-bin-plugin", - "version": "1.4.0", + "version": "1.4.1", "source": { "type": "git", "url": "https://github.com/bamarni/composer-bin-plugin.git", - "reference": "46cb272590cc6b7f5947655063a7fd6ea097838b" + "reference": "9329fb0fbe29e0e1b2db8f4639a193e4f5406225" }, "dist": { "type": "zip", - "url": "https://api.github.com/repos/bamarni/composer-bin-plugin/zipball/46cb272590cc6b7f5947655063a7fd6ea097838b", - "reference": "46cb272590cc6b7f5947655063a7fd6ea097838b", + "url": "https://api.github.com/repos/bamarni/composer-bin-plugin/zipball/9329fb0fbe29e0e1b2db8f4639a193e4f5406225", + "reference": "9329fb0fbe29e0e1b2db8f4639a193e4f5406225", "shasum": "" }, "require": { "composer-plugin-api": "^1.0 || ^2.0", - "php": "^5.6 || ^7.0 || ^8.0" + "php": "^5.5.9 || ^7.0 || ^8.0" }, "require-dev": { "composer/composer": "^1.0 || ^2.0", @@ -51,7 +51,7 @@ "isolation", "tool" ], - "time": "2020-04-17T09:33:47+00:00" + "time": "2020-05-03T08:27:20+00:00" }, { "name": "laminas/laminas-ldap", @@ -112,16 +112,16 @@ }, { "name": "laminas/laminas-zendframework-bridge", - "version": "1.0.3", + "version": "1.0.4", "source": { "type": "git", "url": "https://github.com/laminas/laminas-zendframework-bridge.git", - "reference": "bfbbdb6c998d50dbf69d2187cb78a5f1fa36e1e9" + "reference": "fcd87520e4943d968557803919523772475e8ea3" }, "dist": { "type": "zip", - "url": "https://api.github.com/repos/laminas/laminas-zendframework-bridge/zipball/bfbbdb6c998d50dbf69d2187cb78a5f1fa36e1e9", - "reference": "bfbbdb6c998d50dbf69d2187cb78a5f1fa36e1e9", + "url": "https://api.github.com/repos/laminas/laminas-zendframework-bridge/zipball/fcd87520e4943d968557803919523772475e8ea3", + "reference": "fcd87520e4943d968557803919523772475e8ea3", "shasum": "" }, "require": { @@ -160,7 +160,7 @@ "laminas", "zf" ], - "time": "2020-04-03T16:01:00+00:00" + "time": "2020-05-20T16:45:56+00:00" } ], "aliases": [], diff --git a/l10n/et_EE.js b/l10n/et_EE.js index a83a99beb..89e76fd74 100644 --- a/l10n/et_EE.js +++ b/l10n/et_EE.js @@ -2,6 +2,7 @@ OC.L10N.register( "user_ldap", { "The Base DN appears to be wrong" : "Näib, et Base DN on vale", + "Testing configuration…" : "Seadete testimine...", "Configuration incorrect" : "Seadistus on vigane", "Configuration incomplete" : "Seadistus on puudulik", "Configuration OK" : "Seadistus on korras", @@ -89,6 +90,7 @@ OC.L10N.register( "Not recommended, use it for testing only! If connection only works with this option, import the LDAP server's SSL certificate in your %s server." : "Pole soovitatav, kasuta seda ainult testimiseks! Kui ühendus toimib ainult selle valikuga, siis impordi LDAP serveri SSL sertifikaat oma %s serverisse.", "Cache Time-To-Live" : "Puhvri iga", "in seconds. A change empties the cache." : "sekundites. Muudatus tühjendab vahemälu.", + "Network Timeout" : "Võrguühenduse aegumine", "Directory Settings" : "Kausta seaded", "User Display Name Field" : "Kasutaja näidatava nime väli", "The LDAP attribute to use to generate the user's display name." : "LDAP atribuut, mida kasutatakse kasutaja kuvatava nime loomiseks.", @@ -113,7 +115,6 @@ OC.L10N.register( "User Home Folder Naming Rule" : "Kasutaja kodukataloogi nimetamise reegel", "Leave empty for user name (default). Otherwise, specify an LDAP/AD attribute." : "Kasutajanime (vaikeväärtus) kasutamiseks jäta tühjaks. Vastasel juhul määra LDAP/AD omadus.", "Internal Username" : "Sisemine kasutajanimi", - "By default the internal username will be created from the UUID attribute. It makes sure that the username is unique and characters do not need to be converted. The internal username has the restriction that only these characters are allowed: [ a-zA-Z0-9_.@- ]. Other characters are replaced with their ASCII correspondence or simply omitted. On collisions a number will be added/increased. The internal username is used to identify a user internally. It is also the default name for the user home folder. It is also a part of remote URLs, for instance for all *DAV services. With this setting, the default behavior can be overridden. To achieve a similar behavior as before ownCloud 5 enter the user display name attribute in the following field. Leave it empty for default behavior. Changes will have effect only on newly mapped (added) LDAP users." : "Vaikimisi tekitatakse sisemine kasutajanimi UUID atribuudist. See tagab, et kasutajanimi on unikaalne ja sümboleid pole vaja muuta. Sisemisel kasutajatunnuse puhul on lubatud ainult järgmised sümbolid: [ a-zA-Z0-9_.@- ]. Muud sümbolid asendatakse nende ASCII vastega või lihtsalt hüljatakse. Tõrgete korral lisatakse number või suurendatakse seda. Sisemist kasutajatunnust kasutatakse kasutaja sisemiseks tuvastamiseks. Ühtlasi on see ownCloudis kasutaja vaikimisi kodukataloogi nimeks. See on ka serveri URLi osaks, näiteks kõikidel *DAV teenustel. Selle seadistusega saab tühistada vaikimisi käitumise. Saavutamaks sarnast käitumist eelnevate ownCloud 5 versioonidega, sisesta kasutaja kuvatava nime atribuut järgnevale väljale. Vaikimisi seadistuseks jäta tühjaks. Muudatused mõjutavad ainult uusi (lisatud) LDAP kasutajate vastendusi.", "Internal Username Attribute:" : "Sisemise kasutajatunnuse atribuut:", "Override UUID detection" : "Tühista UUID tuvastus", "By default, the UUID attribute is automatically detected. The UUID attribute is used to doubtlessly identify LDAP users and groups. Also, the internal username will be created based on the UUID, if not specified otherwise above. You can override the setting and pass an attribute of your choice. You must make sure that the attribute of your choice can be fetched for both users and groups and it is unique. Leave it empty for default behavior. Changes will have effect only on newly mapped (added) LDAP users and groups." : "Vaikimis ownCloud tuvastab automaatselt UUID atribuudi. UUID atribuuti kasutatakse LDAP kasutajate ja gruppide kindlaks tuvastamiseks. Samuti tekitatakse sisemine kasutajanimi UUID alusel, kui pole määratud teisiti. Sa saad tühistada selle seadistuse ning määrata atribuudi omal valikul. Pead veenduma, et valitud atribuut toimib nii kasutajate kui gruppide puhul ning on unikaalne. Vaikimisi seadistuseks jäta tühjaks. Muudatused mõjutavad ainult uusi (lisatud) LDAP kasutajate vastendusi.", diff --git a/l10n/et_EE.json b/l10n/et_EE.json index 3d2a767f8..4575f84db 100644 --- a/l10n/et_EE.json +++ b/l10n/et_EE.json @@ -1,5 +1,6 @@ { "translations": { "The Base DN appears to be wrong" : "Näib, et Base DN on vale", + "Testing configuration…" : "Seadete testimine...", "Configuration incorrect" : "Seadistus on vigane", "Configuration incomplete" : "Seadistus on puudulik", "Configuration OK" : "Seadistus on korras", @@ -87,6 +88,7 @@ "Not recommended, use it for testing only! If connection only works with this option, import the LDAP server's SSL certificate in your %s server." : "Pole soovitatav, kasuta seda ainult testimiseks! Kui ühendus toimib ainult selle valikuga, siis impordi LDAP serveri SSL sertifikaat oma %s serverisse.", "Cache Time-To-Live" : "Puhvri iga", "in seconds. A change empties the cache." : "sekundites. Muudatus tühjendab vahemälu.", + "Network Timeout" : "Võrguühenduse aegumine", "Directory Settings" : "Kausta seaded", "User Display Name Field" : "Kasutaja näidatava nime väli", "The LDAP attribute to use to generate the user's display name." : "LDAP atribuut, mida kasutatakse kasutaja kuvatava nime loomiseks.", @@ -111,7 +113,6 @@ "User Home Folder Naming Rule" : "Kasutaja kodukataloogi nimetamise reegel", "Leave empty for user name (default). Otherwise, specify an LDAP/AD attribute." : "Kasutajanime (vaikeväärtus) kasutamiseks jäta tühjaks. Vastasel juhul määra LDAP/AD omadus.", "Internal Username" : "Sisemine kasutajanimi", - "By default the internal username will be created from the UUID attribute. It makes sure that the username is unique and characters do not need to be converted. The internal username has the restriction that only these characters are allowed: [ a-zA-Z0-9_.@- ]. Other characters are replaced with their ASCII correspondence or simply omitted. On collisions a number will be added/increased. The internal username is used to identify a user internally. It is also the default name for the user home folder. It is also a part of remote URLs, for instance for all *DAV services. With this setting, the default behavior can be overridden. To achieve a similar behavior as before ownCloud 5 enter the user display name attribute in the following field. Leave it empty for default behavior. Changes will have effect only on newly mapped (added) LDAP users." : "Vaikimisi tekitatakse sisemine kasutajanimi UUID atribuudist. See tagab, et kasutajanimi on unikaalne ja sümboleid pole vaja muuta. Sisemisel kasutajatunnuse puhul on lubatud ainult järgmised sümbolid: [ a-zA-Z0-9_.@- ]. Muud sümbolid asendatakse nende ASCII vastega või lihtsalt hüljatakse. Tõrgete korral lisatakse number või suurendatakse seda. Sisemist kasutajatunnust kasutatakse kasutaja sisemiseks tuvastamiseks. Ühtlasi on see ownCloudis kasutaja vaikimisi kodukataloogi nimeks. See on ka serveri URLi osaks, näiteks kõikidel *DAV teenustel. Selle seadistusega saab tühistada vaikimisi käitumise. Saavutamaks sarnast käitumist eelnevate ownCloud 5 versioonidega, sisesta kasutaja kuvatava nime atribuut järgnevale väljale. Vaikimisi seadistuseks jäta tühjaks. Muudatused mõjutavad ainult uusi (lisatud) LDAP kasutajate vastendusi.", "Internal Username Attribute:" : "Sisemise kasutajatunnuse atribuut:", "Override UUID detection" : "Tühista UUID tuvastus", "By default, the UUID attribute is automatically detected. The UUID attribute is used to doubtlessly identify LDAP users and groups. Also, the internal username will be created based on the UUID, if not specified otherwise above. You can override the setting and pass an attribute of your choice. You must make sure that the attribute of your choice can be fetched for both users and groups and it is unique. Leave it empty for default behavior. Changes will have effect only on newly mapped (added) LDAP users and groups." : "Vaikimis ownCloud tuvastab automaatselt UUID atribuudi. UUID atribuuti kasutatakse LDAP kasutajate ja gruppide kindlaks tuvastamiseks. Samuti tekitatakse sisemine kasutajanimi UUID alusel, kui pole määratud teisiti. Sa saad tühistada selle seadistuse ning määrata atribuudi omal valikul. Pead veenduma, et valitud atribuut toimib nii kasutajate kui gruppide puhul ning on unikaalne. Vaikimisi seadistuseks jäta tühjaks. Muudatused mõjutavad ainult uusi (lisatud) LDAP kasutajate vastendusi.", diff --git a/tests/acceptance/features/apiProvisioningLDAP/groups.feature b/tests/acceptance/features/apiProvisioningLDAP/groups.feature index 06788cebb..0c1a72de5 100644 --- a/tests/acceptance/features/apiProvisioningLDAP/groups.feature +++ b/tests/acceptance/features/apiProvisioningLDAP/groups.feature @@ -5,7 +5,7 @@ Feature: manage groups 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 + Given user "Alice" 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" @@ -23,10 +23,10 @@ Feature: manage groups 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 + When the administrator adds user "Alice" 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" + And user "Alice" should belong to group "simplegroup" Examples: | ocs-api-version | ocs-status-code | http-status-code | | 1 | 100 | 200 | @@ -48,14 +48,14 @@ Feature: manage groups 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 "Alice" 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 | + | Alice | + | 123 | Examples: | ocs-api-version | ocs-status-code | http-status-code | | 1 | 100 | 200 | @@ -82,7 +82,7 @@ Feature: manage groups 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" + And user "Alice" should not belong to group "grp1" Examples: | ocs-api-version | ocs-status-code | http-status-code | | 1 | 100 | 200 | @@ -93,11 +93,11 @@ Feature: manage groups 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 - And user "user1" has been created with default attributes and without skeleton files - When the administrator adds user "user1" to group "db-group" using the provisioning API + And user "Brian" has been created with default attributes and without skeleton files + When the administrator adds user "Brian" 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" + And user "Brian" should belong to group "db-group" Examples: | ocs-api-version | ocs-status-code | http-status-code | | 1 | 100 | 200 | @@ -106,12 +106,12 @@ Feature: manage groups @issue-core-25224 Scenario Outline: Add ldap user to ldap group Given using OCS API version "" - And user "user1" has been created with default attributes and without skeleton files + And user "Brian" has been created with default attributes and without skeleton files And group "grp2" has been created - When the administrator adds user "user1" to group "grp2" using the provisioning API + When the administrator adds user "Brian" 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" + And user "Brian" should not belong to group "grp2" Examples: | ocs-api-version | ocs-status-code | http-status-code | | 1 | 100 | 200 | @@ -123,72 +123,72 @@ Feature: manage groups Given group "db-group" has been created in the database user backend And these users have been created with default attributes and without skeleton files: | username | - | user1 | - | user2 | - And user "user1" has been added to database backend group "db-group" + | Brian | + | Carol | + And user "Brian" has been added to database backend group "db-group" When the administrator imports this ldif data: """ dn: cn=db-group,ou=TestGroups,dc=owncloud,dc=com cn: db-group gidnumber: 4700 - memberuid: user2 + memberuid: Carol 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 not exist - And user "user2" should not belong to group "db-group" - But user "user1" should belong to group "db-group" + And user "Carol" should not belong to group "db-group" + But user "Brian" should belong to group "db-group" Scenario: creating a group in an OU that is different to the other groups - Given user "user3" has been created with default attributes and without skeleton files + Given user "David" has been created with default attributes and without skeleton files When the administrator creates group "new-group-in-other-ou" in ldap OU "TestUsers" - And the administrator adds user "user3" to group "new-group-in-other-ou" in ldap OU "TestUsers" + And the administrator adds user "David" to group "new-group-in-other-ou" in ldap OU "TestUsers" And the administrator invokes occ command "group:list" - Then user "user3" should belong to group "new-group-in-other-ou" + Then user "David" should belong to group "new-group-in-other-ou" Scenario: creating a group with a name that already exists in LDAP but in a other OU Given these users have been created with default attributes and without skeleton files: | username | - | user2 | - | user3 | + | Carol | + | David | And these groups have been created: - | groupname | - | grp1 | - And user "user2" has been added to group "grp1" + | groupname | + | grp1 | + And user "Carol" has been added to group "grp1" When the administrator creates group "grp1" in ldap OU "TestUsers" - And the administrator adds user "user3" to group "grp1" in ldap OU "TestUsers" + And the administrator adds user "David" to group "grp1" in ldap OU "TestUsers" And the administrator invokes occ command "group:list" - Then user "user2" should belong to group "grp1" - But user "user3" should not belong to group "grp1" + Then user "Carol" should belong to group "grp1" + But user "David" should not belong to group "grp1" And group "grp1_2" should not exist Scenario: creating two groups with the same name in different LDAP OUs at the same time Given these users have been created with default attributes and without skeleton files: | username | - | user1 | - | user2 | + | Brian | + | Carol | When the administrator imports this ldif data: """ dn: cn=so-far-unused-group-name,ou=TestUsers,dc=owncloud,dc=com cn: so-far-unused-group-name gidnumber: 4700 - memberuid: user2 + memberuid: Carol objectclass: top objectclass: posixGroup dn: cn=so-far-unused-group-name,ou=TestGroups,dc=owncloud,dc=com cn: so-far-unused-group-name gidnumber: 4700 - memberuid: user1 + memberuid: Brian objectclass: top objectclass: posixGroup """ And the administrator invokes occ command "group:list" Then group "so-far-unused-group-name" should exist - And user "user2" should belong to group "so-far-unused-group-name" - But user "user1" should not belong to group "so-far-unused-group-name" + And user "Carol" should belong to group "so-far-unused-group-name" + But user "Brian" should not belong to group "so-far-unused-group-name" Scenario Outline: Add database group with same name as existing ldap group Given using OCS API version "" @@ -200,4 +200,4 @@ Feature: manage groups Examples: | ocs-api-version | ocs-status-code | http-status-code | | 1 | 102 | 200 | - | 2 | 400 | 400 | \ No newline at end of file + | 2 | 400 | 400 | diff --git a/tests/acceptance/features/apiProvisioningLDAP/userSync.feature b/tests/acceptance/features/apiProvisioningLDAP/userSync.feature index b1ae15a8c..6259cd567 100644 --- a/tests/acceptance/features/apiProvisioningLDAP/userSync.feature +++ b/tests/acceptance/features/apiProvisioningLDAP/userSync.feature @@ -4,20 +4,50 @@ Feature: Single user sync using the OCS API Background: Given these users have been created with default attributes and without skeleton files: | username | - | user0 | - | user1 | + | Alice | + | Brian | Scenario Outline: admin deletes ldap users and syncs only one of them Given using OCS API version "" - When the administrator deletes user "user0" using the provisioning API - And the administrator deletes user "user1" using the provisioning API - Then user "user0" should not exist - And user "user1" should not exist - When the administrator tries to sync user "user0" using the OCS API + When the administrator deletes user "Alice" using the provisioning API + And the administrator deletes user "Brian" using the provisioning API + Then user "Alice" should not exist + And user "Brian" should not exist + When the administrator tries to sync user "Alice" using the OCS API Then the HTTP status code should be "200" And the OCS status code should be "" - And user "user0" should exist - And user "user1" should not exist + And user "Alice" should exist + And user "Brian" should not exist + Examples: + | ocs-api-version | ocs-status-code | + | 1 | 100 | + | 2 | 200 | + + Scenario Outline: admin syncs after changing display name of a ldap user + Given using OCS API version "" + When the administrator sets the ldap attribute "displayname" of the entry "uid=Alice,ou=TestUsers" to "ldap user zero" + When the administrator sets the ldap attribute "displayname" of the entry "uid=Brian,ou=TestUsers" to "ldap user one" + And the administrator tries to sync user "Alice" using the OCS API + Then the HTTP status code should be "200" + And the OCS status code should be "" + And user "Alice" should exist + And the display name of user "Alice" should be "ldap user zero" + And the display name of user "Brian" should be "Brian Murphy" + Examples: + | ocs-api-version | ocs-status-code | + | 1 | 100 | + | 2 | 200 | + + Scenario Outline: admin syncs after changing email address of a ldap user + Given using OCS API version "" + When the administrator sets the ldap attribute "mail" of the entry "uid=Alice,ou=TestUsers" to "ldapAlice@example.com" + When the administrator sets the ldap attribute "mail" of the entry "uid=Brian,ou=TestUsers" to "ldapBrian@example.com" + And the administrator tries to sync user "Alice" using the OCS API + Then the HTTP status code should be "200" + And the OCS status code should be "" + And user "Alice" should exist + And the email address of user "Alice" should be "ldapAlice@example.com" + And the email address of user "Brian" should be "brian@example.org" Examples: | ocs-api-version | ocs-status-code | | 1 | 100 | diff --git a/tests/acceptance/features/apiProvisioningLDAP/users.feature b/tests/acceptance/features/apiProvisioningLDAP/users.feature index 59724dcdd..09466ea62 100644 --- a/tests/acceptance/features/apiProvisioningLDAP/users.feature +++ b/tests/acceptance/features/apiProvisioningLDAP/users.feature @@ -6,12 +6,15 @@ Feature: Manage users using the Provisioning API 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 + And user "Alice" has been deleted + When the administrator sends a user creation request with the following attributes using the provisioning API: + | username | Alice | + | password | %alt1% | + | displayname | Brand New User | 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 + And user "Alice" should exist + And user "Alice" should be able to access a skeleton file Examples: | ocs-api-version | ocs-status-code | http-status-code | | 1 | 100 | 200 | @@ -19,11 +22,11 @@ Feature: Manage users using the Provisioning API 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 + And user "Alice" has been created with default attributes in the database user backend + When the administrator deletes user "Alice" 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 + And user "Alice" should not exist Examples: | ocs-api-version | ocs-status-code | http-status-code | | 1 | 100 | 200 | @@ -31,11 +34,11 @@ Feature: Manage users using the Provisioning API 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 + And user "Alice" has been created with default attributes in the database user backend + When the administrator changes the email of user "Alice" to "someone@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" + And the email address of user "Alice" should be "someone@example.com" Examples: | ocs-api-version | ocs-status-code | http-status-code | | 1 | 100 | 200 | @@ -43,11 +46,11 @@ Feature: Manage users using the Provisioning API 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 + And user "Alice" has been created with default attributes in the database user backend + When the administrator changes the display of user "Alice" 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" + And the display name of user "Alice" should be "A New User" Examples: | ocs-api-version | ocs-status-code | http-status-code | | 1 | 100 | 200 | @@ -55,11 +58,11 @@ Feature: Manage users using the Provisioning API 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 + And user "Alice" has been created with default attributes in the database user backend + When the administrator changes the display name of user "Alice" 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" + And the display name of user "Alice" should be "A New User" Examples: | ocs-api-version | ocs-status-code | http-status-code | | 1 | 100 | 200 | @@ -67,11 +70,11 @@ Feature: Manage users using the Provisioning API 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 + And user "Alice" has been created with default attributes in the database user backend + When the administrator changes the quota of user "Alice" 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" + And the quota definition of user "Alice" should be "12 MB" Examples: | ocs-api-version | ocs-status-code | http-status-code | | 1 | 100 | 200 | @@ -80,13 +83,13 @@ Feature: Manage users using the Provisioning API @issue-core-33186 Scenario Outline: admin tries to modify displayname of user for which an LDAP attribute is specified Given using OCS API version "" - And user "user1" has been created with default attributes and without skeleton files - When the administrator sets the ldap attribute "displayname" of the entry "uid=user1,ou=TestUsers" to "ldap user" + And user "Alice" has been created with default attributes and without skeleton files + When the administrator sets the ldap attribute "displayname" of the entry "uid=Alice,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 + When the administrator changes the display of user "Alice" 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" + And the display name of user "Alice" should be "ldap user" Examples: | ocs-api-version | ocs-status-code | http-status-code | | 1 | 100 | 200 | @@ -97,14 +100,14 @@ Feature: Manage users using the Provisioning API @issue-core-33186 Scenario Outline: admin tries to modify password of user for which an LDAP attribute is specified Given using OCS API version "" - And user "user1" has been created with default attributes and skeleton files - When the administrator sets the ldap attribute "userpassword" of the entry "uid=user1,ou=TestUsers" to "ldap_password" + And user "Alice" has been created with default attributes and skeleton files + When the administrator sets the ldap attribute "userpassword" of the entry "uid=Alice,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 + And the administrator resets the password of user "Alice" 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" + And the content of file "textfile0.txt" for user "Alice" using password "ldap_password" should be "ownCloud test text file 0" plus end-of-line + But user "Alice" 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 | @@ -115,16 +118,16 @@ Feature: Manage users using the Provisioning API @issue-core-33186 Scenario Outline: admin tries to modify mail of user for which an LDAP attribute is specified Given using OCS API version "" - And user "user1" has been created with default attributes and without skeleton files - When the administrator sets the ldap attribute "mail" of the entry "uid=user1,ou=TestUsers" to "ldapuser@oc.com" + And user "Alice" has been created with default attributes and without skeleton files + When the administrator sets the ldap attribute "mail" of the entry "uid=Alice,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 + And the administrator changes the email of user "Alice" 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@oc.com" - And the email address of user "user1" should be "apiuser@example.com" + # And the email address of user "Alice" should be "ldapuser@oc.com" + And the email address of user "Alice" should be "apiuser@example.com" And the LDAP users are resynced - And the email address of user "user1" should be "ldapuser@oc.com" + And the email address of user "Alice" should be "ldapuser@oc.com" Examples: | ocs-api-version | ocs-status-code | http-status-code | | 1 | 100 | 200 | @@ -135,18 +138,18 @@ Feature: Manage users using the Provisioning API @issue-core-33186 Scenario Outline: admin tries to modify quota of user for which an LDAP attribute is specified Given using OCS API version "" - And user "user1" has been created with default attributes and without skeleton files + And user "Alice" has been created with default attributes and without skeleton files #to set Quota we can just misuse any LDAP text field And LDAP config "LDAPTestId" has key "ldapQuotaAttribute" set to "employeeNumber" - When the administrator sets the ldap attribute "employeeNumber" of the entry "uid=user1,ou=TestUsers" to "10 MB" + When the administrator sets the ldap attribute "employeeNumber" of the entry "uid=Alice,ou=TestUsers" to "10 MB" And the LDAP users are resynced - And the administrator changes the quota of user "user1" to "13MB" using the provisioning API + And the administrator changes the quota of user "Alice" to "13MB" using the provisioning API Then the OCS status code should be "" And the HTTP status code should be "" - And the quota definition of user "user1" should be "13 MB" - #And the quota definition of user "user1" should be "10 MB" + And the quota definition of user "Alice" should be "13 MB" + #And the quota definition of user "Alice" should be "10 MB" When the LDAP users are resynced - Then the quota definition of user "user1" should be "10 MB" + Then the quota definition of user "Alice" should be "10 MB" Examples: | ocs-api-version | ocs-status-code | http-status-code | | 1 | 100 | 200 | @@ -156,16 +159,16 @@ Feature: Manage users using the Provisioning API Scenario Outline: admin sets quota of user for which no LDAP quota attribute is specified Given using OCS API version "" - And user "user1" has been created with default attributes and without skeleton files + And user "Alice" has been created with default attributes and without skeleton files #to set Quota we can just misuse any LDAP text field And LDAP config "LDAPTestId" has key "ldapQuotaAttribute" set to "employeeNumber" And the LDAP users have been resynced - When the administrator changes the quota of user "user1" to "13MB" using the provisioning API + When the administrator changes the quota of user "Alice" to "13MB" using the provisioning API Then the OCS status code should be "" And the HTTP status code should be "" - And the quota definition of user "user1" should be "13 MB" + And the quota definition of user "Alice" should be "13 MB" When the LDAP users are resynced - Then the quota definition of user "user1" should be "13 MB" + Then the quota definition of user "Alice" should be "13 MB" Examples: | ocs-api-version | ocs-status-code | http-status-code | | 1 | 100 | 200 | @@ -174,18 +177,18 @@ Feature: Manage users using the Provisioning API @issue-core-33186 Scenario Outline: admin sets quota of user for which no LDAP quota attribute is specified but a default quota is set in the LDAP settings Given using OCS API version "" - And user "user1" has been created with default attributes and without skeleton files + And user "Alice" has been created with default attributes and without skeleton files #to set Quota we can just misuse any LDAP text field And LDAP config "LDAPTestId" has key "ldapQuotaAttribute" set to "employeeNumber" And LDAP config "LDAPTestId" has key "ldapQuotaDefault" set to "10MB" And the LDAP users have been resynced - When the administrator changes the quota of user "user1" to "13MB" using the provisioning API + When the administrator changes the quota of user "Alice" to "13MB" using the provisioning API Then the OCS status code should be "" And the HTTP status code should be "" - And the quota definition of user "user1" should be "13 MB" - #And the quota definition of user "user1" should be "10MB" + And the quota definition of user "Alice" should be "13 MB" + #And the quota definition of user "Alice" should be "10MB" And the LDAP users are resynced - And the quota definition of user "user1" should be "10MB" + And the quota definition of user "Alice" should be "10MB" Examples: | ocs-api-version | ocs-status-code | http-status-code | | 1 | 100 | 200 | @@ -195,15 +198,15 @@ Feature: Manage users using the Provisioning API Scenario Outline: admin sets quota of user in LDAP when a default quota is set in the LDAP settings Given using OCS API version "" - And user "user1" has been created with default attributes and without skeleton files + And user "Alice" has been created with default attributes and without skeleton files #to set Quota we can just misuse any LDAP text field And LDAP config "LDAPTestId" has key "ldapQuotaAttribute" set to "employeeNumber" And LDAP config "LDAPTestId" has key "ldapQuotaDefault" set to "10MB" And the LDAP users have been resynced - When the administrator sets the ldap attribute "employeeNumber" of the entry "uid=user1,ou=TestUsers" to "13 MB" - Then the quota definition of user "user1" should be "10MB" + When the administrator sets the ldap attribute "employeeNumber" of the entry "uid=Alice,ou=TestUsers" to "13 MB" + Then the quota definition of user "Alice" should be "10MB" And the LDAP users are resynced - And the quota definition of user "user1" should be "13 MB" + And the quota definition of user "Alice" should be "13 MB" Examples: | ocs-api-version | ocs-status-code | http-status-code | | 1 | 100 | 200 | @@ -212,19 +215,19 @@ Feature: Manage users using the Provisioning API @issue-core-33186 Scenario Outline: admin sets quota of user when the quota LDAP attribute is specified and a default quota is set in the LDAP settings Given using OCS API version "" - And user "user1" has been created with default attributes and without skeleton files + And user "Alice" has been created with default attributes and without skeleton files #to set Quota we can just misuse any LDAP text field And LDAP config "LDAPTestId" has key "ldapQuotaAttribute" set to "employeeNumber" And LDAP config "LDAPTestId" has key "ldapQuotaDefault" set to "10MB" - When the administrator sets the ldap attribute "employeeNumber" of the entry "uid=user1,ou=TestUsers" to "11 MB" + When the administrator sets the ldap attribute "employeeNumber" of the entry "uid=Alice,ou=TestUsers" to "11 MB" And the LDAP users are resynced - And the administrator changes the quota of user "user1" to "13MB" using the provisioning API + And the administrator changes the quota of user "Alice" to "13MB" using the provisioning API Then the OCS status code should be "" And the HTTP status code should be "" - And the quota definition of user "user1" should be "13 MB" - #And the quota definition of user "user1" should be "11 MB" + And the quota definition of user "Alice" should be "13 MB" + #And the quota definition of user "Alice" should be "11 MB" And the LDAP users are resynced - And the quota definition of user "user1" should be "11 MB" + And the quota definition of user "Alice" should be "11 MB" Examples: | ocs-api-version | ocs-status-code | http-status-code | | 1 | 100 | 200 | @@ -234,15 +237,15 @@ Feature: Manage users using the Provisioning API Scenario Outline: Administrator deletes a ldap user and resyncs again Given using OCS API version "" - And user "user0" has been created with default attributes and without skeleton files - And user "user0" has uploaded file with content "new file that should be overwritten after user deletion" to "textfile0.txt" - When the administrator deletes user "user0" using the provisioning API + And user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "new file that should be overwritten after user deletion" to "textfile0.txt" + When the administrator deletes user "Alice" using the provisioning API Then the OCS status code should be "" And the HTTP status code should be "" - And user "user0" should not exist + And user "Alice" 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 + Then user "Alice" should exist + And the content of file "textfile0.txt" for user "Alice" 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 | @@ -250,15 +253,18 @@ Feature: Manage users using the Provisioning API Scenario Outline: Administrator tries to create a user with same name as existing ldap user Given using OCS API version "" - And user "user0" has been created with default attributes and skeleton files - When the administrator sends a user creation request for user "user0" password "%alt1%" using the provisioning API + And user "Alice" has been created with default attributes and skeleton files + When the administrator sends a user creation request with the following attributes using the provisioning API: + | username | Alice | + | password | %alt1% | + | displayname | Alice Hansen | 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" + And user "Alice" should exist + And the content of file "textfile0.txt" for user "Alice" using password "123456" should be "ownCloud test text file 0" plus end-of-line + But user "Alice" 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 + | 2 | 400 | 400 | diff --git a/tests/acceptance/features/apiUserLDAP/backupServerConnection.feature b/tests/acceptance/features/apiUserLDAP/backupServerConnection.feature index 1e9693c4a..7b86bfe4a 100644 --- a/tests/acceptance/features/apiUserLDAP/backupServerConnection.feature +++ b/tests/acceptance/features/apiUserLDAP/backupServerConnection.feature @@ -1,47 +1,47 @@ @api Feature: connect to a backup LDAP serer -As an administrator -I want to be able to set up a backup LDAP server -So that user authentication still works when the main LDAP server is not reachable + As an administrator + I want to be able to set up a backup LDAP server + So that user authentication still works when the main LDAP server is not reachable Background: Given the owncloud log level has been set to "warning" And the owncloud log has been cleared - And user "user0" has been created with default attributes and skeleton files + And user "Alice" has been created with default attributes and skeleton files Scenario: authentication works when the main server is not reachable but the backup server is Given LDAP config "LDAPTestId" has key "ldapHost" set to "not-existent" And LDAP config "LDAPTestId" has key "ldapBackupHost" set to "%ldap_host%" And LDAP config "LDAPTestId" has key "ldapBackupPort" set to "%ldap_port%" - When user "user0" requests "/index.php/apps/files" with "GET" using basic auth + When user "Alice" requests "/index.php/apps/files" with "GET" using basic auth Then the HTTP status code should be "200" Scenario: authentication works when the main server and the backup server are reachable Given LDAP config "LDAPTestId" has key "ldapBackupHost" set to "%ldap_host%" And LDAP config "LDAPTestId" has key "ldapBackupPort" set to "%ldap_port%" - When user "user0" requests "/index.php/apps/files" with "GET" using basic auth + When user "Alice" requests "/index.php/apps/files" with "GET" using basic auth Then the HTTP status code should be "200" Scenario: authentication works when the backup server is not reachable but the main server is Given LDAP config "LDAPTestId" has key "ldapBackupHost" set to "not-existent" And LDAP config "LDAPTestId" has key "ldapBackupPort" set to "%ldap_port%" - When user "user0" requests "/index.php/apps/files" with "GET" using basic auth + When user "Alice" requests "/index.php/apps/files" with "GET" using basic auth Then the HTTP status code should be "200" Scenario Outline: authentication fails when the main server and backup server is not reachable and works again when one server comes back Given LDAP config "LDAPTestId" has key "ldapHost" set to "not-existent" And LDAP config "LDAPTestId" has key "ldapBackupHost" set to "not-existent" And LDAP config "LDAPTestId" has key "ldapBackupPort" set to "%ldap_port%" - When user "user0" requests "/index.php/apps/files" with "GET" using basic auth + When user "Alice" requests "/index.php/apps/files" with "GET" using basic auth Then the HTTP status code should be "401" And the last lines of the log file should contain log-entries containing these attributes: - | app | message | - | user_ldap | Error when searching: Can't contact LDAP server code -1 | - | user_ldap | Attempt for Paging? | - | core | Login failed: 'user0' (Remote IP: | + | app | message | + | user_ldap | Error when searching: Can't contact LDAP server code -1 | + | user_ldap | Attempt for Paging? | + | core | Login failed: 'Alice' (Remote IP: | When the administrator sets the LDAP config "LDAPTestId" key "" to "%ldap_host%" using the occ command - And user "user0" requests "/index.php/apps/files" with "GET" using basic auth + And user "Alice" requests "/index.php/apps/files" with "GET" using basic auth Then the HTTP status code should be "200" Examples: | server-that-comes-back | @@ -52,6 +52,6 @@ So that user authentication still works when the main LDAP server is not reachab Given LDAP config "LDAPTestId" has key "ldapHost" set to "not-existent" And LDAP config "LDAPTestId" has key "ldapBackupHost" set to "%ldap_host%" And LDAP config "LDAPTestId" has key "ldapBackupPort" set to "%ldap_port%" - When the administrator sets the ldap attribute "userpassword" of the entry "uid=user0,ou=TestUsers" to "new-password" - Then user "user0" using password "%regular%" should not be able to download file "textfile0.txt" - But the content of file "textfile0.txt" for user "user0" using password "new-password" should be "ownCloud test text file 0" plus end-of-line + When the administrator sets the ldap attribute "userpassword" of the entry "uid=Alice,ou=TestUsers" to "new-password" + Then user "Alice" using password "%regular%" should not be able to download file "textfile0.txt" + But the content of file "textfile0.txt" for user "Alice" using password "new-password" should be "ownCloud test text file 0" plus end-of-line diff --git a/tests/acceptance/features/apiUserLDAP/groupFilter.feature b/tests/acceptance/features/apiUserLDAP/groupFilter.feature index 8c2e4e5df..96d9a7efa 100644 --- a/tests/acceptance/features/apiUserLDAP/groupFilter.feature +++ b/tests/acceptance/features/apiUserLDAP/groupFilter.feature @@ -14,7 +14,6 @@ Feature: filter groups | ShareeGroup | | ShareeGroup2 | - Scenario: single group filter When the administrator sets these settings of LDAP config "LDAPTestId" using the occ command | key | value | @@ -22,9 +21,9 @@ Feature: filter groups And the administrator gets the groups in JSON format using the occ command Then the command should have been successful And the groups returned by the occ command should be - | group | - | admin | - | grp2 | + | group | + | admin | + | grp2 | Scenario: filter with asterisk When the administrator sets these settings of LDAP config "LDAPTestId" using the occ command @@ -50,8 +49,8 @@ Feature: filter groups | group1 | | group2 | - Scenario: filter groups that are in multiple OUs but have the same CN - Given the administrator has imported this ldif data: + Scenario: filter groups that are in multiple OUs but have the same CN + Given the administrator has imported this ldif data: """ dn: cn=grp1,ou=TestUsers,dc=owncloud,dc=com cn: grp1 @@ -59,12 +58,12 @@ Feature: filter groups objectclass: top objectclass: posixGroup """ - When the administrator sets these settings of LDAP config "LDAPTestId" using the occ command - | key | value | - | ldapGroupFilter | (&(\|(objectclass=posixGroup))(\|(cn=grp1))) | - And the administrator gets the groups in JSON format using the occ command - Then the command should have been successful - And the groups returned by the occ command should be - | group | - | admin | - | grp1 | + When the administrator sets these settings of LDAP config "LDAPTestId" using the occ command + | key | value | + | ldapGroupFilter | (&(\|(objectclass=posixGroup))(\|(cn=grp1))) | + And the administrator gets the groups in JSON format using the occ command + Then the command should have been successful + And the groups returned by the occ command should be + | group | + | admin | + | grp1 | diff --git a/tests/acceptance/features/apiUserLDAP/moveUser.feature b/tests/acceptance/features/apiUserLDAP/moveUser.feature index e0a8fba21..d7639a02e 100644 --- a/tests/acceptance/features/apiUserLDAP/moveUser.feature +++ b/tests/acceptance/features/apiUserLDAP/moveUser.feature @@ -5,30 +5,28 @@ Feature: move users between OUs Given the owncloud log level has been set to "info" And the owncloud log backend has been set to "owncloud" And the owncloud log has been cleared - And user "user0" has been created with default attributes and without skeleton files - And user "user0" has uploaded file with content "new file that should still exist" to "textfile_new.txt" - When the administrator deletes the ldap entry "uid=user0,ou=TestUsers" + And user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "new file that should still exist" to "textfile_new.txt" + When the administrator deletes the ldap entry "uid=Alice,ou=TestUsers" And the administrator imports this ldif data: """ - dn: uid=user0,ou=TestGroups,dc=owncloud,dc=com - cn: User0 + dn: uid=Alice,ou=TestGroups,dc=owncloud,dc=com + cn: Alice sn: One displayname: User Zero - gecos: User0 + gecos: Alice gidnumber: 5000 - givenname: User0 - homedirectory: /home/openldap/user0 + givenname: Alice + homedirectory: /home/openldap/Alice loginshell: /bin/bash - mail: user0@example.org + mail: alice@example.org objectclass: posixAccount objectclass: inetOrgPerson - uid: user0 + uid: Alice uidnumber: 30000 userpassword: 123456 """ - Then the content of file "textfile_new.txt" for user "user0" should be "new file that should still exist" + Then the content of file "textfile_new.txt" for user "Alice" should be "new file that should still exist" And the log file should contain at least one entry matching each of these lines: | user | app | method | message | - | -- | OCA\User_LDAP\User\Manager::resolveUID | GET | DN changed! Found user user0 by uuid user0, updating dn to uid=user0,ou=testgroups,dc=owncloud,dc=com | - - + | -- | OCA\User_LDAP\User\Manager::resolveUID | GET | DN changed! Found user Alice by uuid Alice, updating dn to uid=alice,ou=testgroups,dc=owncloud,dc=com | diff --git a/tests/acceptance/features/apiUserLDAP/serverConnection.feature b/tests/acceptance/features/apiUserLDAP/serverConnection.feature index 8d6e2e3a0..230917e30 100644 --- a/tests/acceptance/features/apiUserLDAP/serverConnection.feature +++ b/tests/acceptance/features/apiUserLDAP/serverConnection.feature @@ -4,86 +4,86 @@ Feature: connect to LDAP serer Background: Given the owncloud log level has been set to "warning" And the owncloud log has been cleared - And user "user0" has been created with default attributes and skeleton files + And user "Alice" has been created with default attributes and skeleton files Scenario: authentication fails when the configuration does not contain an ldap port Given LDAP config "LDAPTestId" has key "ldapPort" set to "" - When user "user0" requests "/index.php/apps/files" with "GET" using basic auth + When user "Alice" requests "/index.php/apps/files" with "GET" using basic auth Then the HTTP status code should be "401" And the last lines of the log file should contain log-entries with these attributes: - | app | message | - | user_ldap | Configuration Error (prefix LDAPTestId): No LDAP Port given! | + | app | message | + | user_ldap | Configuration Error (prefix LDAPTestId): No LDAP Port given! | When the administrator sets the LDAP config "LDAPTestId" key "ldapPort" to "%ldap_port%" using the occ command - And user "user0" requests "/index.php/apps/files" with "GET" using basic auth + And user "Alice" requests "/index.php/apps/files" with "GET" using basic auth Then the HTTP status code should be "200" Scenario: authentication fails when the configuration has a wrong hostname Given LDAP config "LDAPTestId" has key "ldapHost" set to "not-existent" - When user "user0" requests "/index.php/apps/files" with "GET" using basic auth + When user "Alice" requests "/index.php/apps/files" with "GET" using basic auth Then the HTTP status code should be "401" And the last lines of the log file should contain log-entries containing these attributes: - | app | message | - | user_ldap | Error when searching: Can't contact LDAP server code -1 | - | user_ldap | Attempt for Paging? | - | core | Login failed: 'user0' (Remote IP: | + | app | message | + | user_ldap | Error when searching: Can't contact LDAP server code -1 | + | user_ldap | Attempt for Paging? | + | core | Login failed: 'Alice' (Remote IP: | When the administrator sets the LDAP config "LDAPTestId" key "ldapHost" to "%ldap_host%" using the occ command - And user "user0" requests "/index.php/apps/files" with "GET" using basic auth + And user "Alice" requests "/index.php/apps/files" with "GET" using basic auth Then the HTTP status code should be "200" Scenario: authentication works when the hostname contains the protocol Given LDAP config "LDAPTestId" has key "ldapHost" set to "%ldap_host%" - When user "user0" requests "/index.php/apps/files" with "GET" using basic auth + When user "Alice" requests "/index.php/apps/files" with "GET" using basic auth Then the HTTP status code should be "200" Scenario: authentication works when the hostname does not contain the protocol Given LDAP config "LDAPTestId" has key "ldapHost" set to "%ldap_host_without_scheme%" - When user "user0" requests "/index.php/apps/files" with "GET" using basic auth + When user "Alice" requests "/index.php/apps/files" with "GET" using basic auth Then the HTTP status code should be "200" Scenario: authentication does not work when the hostname contains a wrong protocol Given LDAP config "LDAPTestId" has key "ldapHost" set to "http://%ldap_host_without_scheme%" - When user "user0" requests "/index.php/apps/files" with "GET" using basic auth + When user "Alice" requests "/index.php/apps/files" with "GET" using basic auth Then the HTTP status code should be "401" And the last lines of the log file should contain log-entries containing these attributes: - | app | message | - | PHP | ldap_connect(): Could not create session handle: Bad parameter to an ldap routine at | - | PHP | ldap_set_option(): supplied argument is not a valid ldap link resource at | + | app | message | + | PHP | ldap_connect(): Could not create session handle: Bad parameter to an ldap routine at | + | PHP | ldap_set_option(): supplied argument is not a valid ldap link resource at | @issue-49 Scenario: authentication works when second of multiple configurations has an unreachable host configured Given a new LDAP config with the name "wrongLdapConfig" has been created And LDAP config "wrongLdapConfig" has these settings: - | key | value | - | ldapHost | notexisting | - | ldapAgentName | cn=admin,dc=owncloud,dc=com | - | ldapAgentPassword | admin | - | ldapBase | dc=owncloud,dc=com | - | ldapBaseGroups | dc=owncloud,dc=com | - | ldapBaseUsers | dc=owncloud,dc=com | - | ldapEmailAttribute | mail | - | ldapExpertUUIDUserAttr | uid | - | ldapGroupDisplayName | cn | - | ldapGroupFilter | (&(\|(objectclass=posixGroup))) | - | ldapGroupFilterObjectclass | posixGroup | - | ldapGroupMemberAssocAttr | memberUid | - | ldapLoginFilter | (&(\|(objectclass=inetOrgPerson))(\|(uid=%uid)(\|(mailPrimaryAddress=%uid)(mail=%uid)))) | - | ldapLoginFilterEmail | 1 | - | ldapLoginFilterMode | 0 | - | ldapLoginFilterUsername | 1 | - | ldapNestedGroups | 0 | - | ldapPagingSize | 500 | - | ldapPort | %ldap_port% | - | ldapTLS | 0 | - | ldapUserDisplayName | displayName | - | ldapUserFilter | (\|(objectclass=inetOrgPerson)) | - | ldapUserFilterMode | 0 | - | ldapUserFilterObjectclass | inetOrgPerson | - | ldapUuidGroupAttribute | auto | - | ldapUuidUserAttribute | auto | - | turnOffCertCheck | 0 | - | useMemberOfToDetectMembership| 1 | - | ldapConfigurationActive | 1 | - When user "user0" requests "/index.php/apps/files" with "GET" using basic auth + | key | value | + | ldapHost | notexisting | + | ldapAgentName | cn=admin,dc=owncloud,dc=com | + | ldapAgentPassword | admin | + | ldapBase | dc=owncloud,dc=com | + | ldapBaseGroups | dc=owncloud,dc=com | + | ldapBaseUsers | dc=owncloud,dc=com | + | ldapEmailAttribute | mail | + | ldapExpertUUIDUserAttr | uid | + | ldapGroupDisplayName | cn | + | ldapGroupFilter | (&(\|(objectclass=posixGroup))) | + | ldapGroupFilterObjectclass | posixGroup | + | ldapGroupMemberAssocAttr | memberUid | + | ldapLoginFilter | (&(\|(objectclass=inetOrgPerson))(\|(uid=%uid)(\|(mailPrimaryAddress=%uid)(mail=%uid)))) | + | ldapLoginFilterEmail | 1 | + | ldapLoginFilterMode | 0 | + | ldapLoginFilterUsername | 1 | + | ldapNestedGroups | 0 | + | ldapPagingSize | 500 | + | ldapPort | %ldap_port% | + | ldapTLS | 0 | + | ldapUserDisplayName | displayName | + | ldapUserFilter | (\|(objectclass=inetOrgPerson)) | + | ldapUserFilterMode | 0 | + | ldapUserFilterObjectclass | inetOrgPerson | + | ldapUuidGroupAttribute | auto | + | ldapUuidUserAttribute | auto | + | turnOffCertCheck | 0 | + | useMemberOfToDetectMembership | 1 | + | ldapConfigurationActive | 1 | + When user "Alice" requests "/index.php/apps/files" with "GET" using basic auth Then the HTTP status code should be "500" #Then the HTTP status code should be "200" @@ -92,114 +92,114 @@ Feature: connect to LDAP serer Given LDAP config "LDAPTestId" has key "ldapHost" set to "not-existent" And a new LDAP config with the name "SecondaryLdapConfig" has been created And LDAP config "SecondaryLdapConfig" has these settings: - | key | value | - | ldapHost | %ldap_host% | - | ldapAgentName | cn=admin,dc=owncloud,dc=com | - | ldapAgentPassword | admin | - | ldapBase | dc=owncloud,dc=com | - | ldapBaseGroups | dc=owncloud,dc=com | - | ldapBaseUsers | dc=owncloud,dc=com | - | ldapEmailAttribute | mail | - | ldapExpertUUIDUserAttr | uid | - | ldapGroupDisplayName | cn | - | ldapGroupFilter | (&(\|(objectclass=posixGroup))) | - | ldapGroupFilterObjectclass | posixGroup | - | ldapGroupMemberAssocAttr | memberUid | - | ldapLoginFilter | (&(\|(objectclass=inetOrgPerson))(\|(uid=%uid)(\|(mailPrimaryAddress=%uid)(mail=%uid)))) | - | ldapLoginFilterEmail | 1 | - | ldapLoginFilterMode | 0 | - | ldapLoginFilterUsername | 1 | - | ldapNestedGroups | 0 | - | ldapPagingSize | 500 | - | ldapPort | %ldap_port% | - | ldapTLS | 0 | - | ldapUserDisplayName | displayName | - | ldapUserFilter | (\|(objectclass=inetOrgPerson)) | - | ldapUserFilterMode | 0 | - | ldapUserFilterObjectclass | inetOrgPerson | - | ldapUuidGroupAttribute | auto | - | ldapUuidUserAttribute | auto | - | turnOffCertCheck | 0 | - | useMemberOfToDetectMembership| 1 | - | ldapConfigurationActive | 1 | - When user "user0" requests "/index.php/apps/files" with "GET" using basic auth + | key | value | + | ldapHost | %ldap_host% | + | ldapAgentName | cn=admin,dc=owncloud,dc=com | + | ldapAgentPassword | admin | + | ldapBase | dc=owncloud,dc=com | + | ldapBaseGroups | dc=owncloud,dc=com | + | ldapBaseUsers | dc=owncloud,dc=com | + | ldapEmailAttribute | mail | + | ldapExpertUUIDUserAttr | uid | + | ldapGroupDisplayName | cn | + | ldapGroupFilter | (&(\|(objectclass=posixGroup))) | + | ldapGroupFilterObjectclass | posixGroup | + | ldapGroupMemberAssocAttr | memberUid | + | ldapLoginFilter | (&(\|(objectclass=inetOrgPerson))(\|(uid=%uid)(\|(mailPrimaryAddress=%uid)(mail=%uid)))) | + | ldapLoginFilterEmail | 1 | + | ldapLoginFilterMode | 0 | + | ldapLoginFilterUsername | 1 | + | ldapNestedGroups | 0 | + | ldapPagingSize | 500 | + | ldapPort | %ldap_port% | + | ldapTLS | 0 | + | ldapUserDisplayName | displayName | + | ldapUserFilter | (\|(objectclass=inetOrgPerson)) | + | ldapUserFilterMode | 0 | + | ldapUserFilterObjectclass | inetOrgPerson | + | ldapUuidGroupAttribute | auto | + | ldapUuidUserAttribute | auto | + | turnOffCertCheck | 0 | + | useMemberOfToDetectMembership | 1 | + | ldapConfigurationActive | 1 | + When user "Alice" requests "/index.php/apps/files" with "GET" using basic auth Then the HTTP status code should be "500" #Then the HTTP status code should be "200" Scenario: authentication works when there are multiple configurations and both connect correctly to the same host Given a new LDAP config with the name "SecondaryLdapConfig" has been created And LDAP config "SecondaryLdapConfig" has these settings: - | key | value | - | ldapHost | %ldap_host% | - | ldapAgentName | cn=admin,dc=owncloud,dc=com | - | ldapAgentPassword | admin | - | ldapBase | dc=owncloud,dc=com | - | ldapBaseGroups | dc=owncloud,dc=com | - | ldapBaseUsers | dc=owncloud,dc=com | - | ldapEmailAttribute | mail | - | ldapExpertUUIDUserAttr | uid | - | ldapGroupDisplayName | cn | - | ldapGroupFilter | (&(\|(objectclass=posixGroup))) | - | ldapGroupFilterObjectclass | posixGroup | - | ldapGroupMemberAssocAttr | memberUid | - | ldapLoginFilter | (&(\|(objectclass=inetOrgPerson))(\|(uid=%uid)(\|(mailPrimaryAddress=%uid)(mail=%uid)))) | - | ldapLoginFilterEmail | 1 | - | ldapLoginFilterMode | 0 | - | ldapLoginFilterUsername | 1 | - | ldapNestedGroups | 0 | - | ldapPagingSize | 500 | - | ldapPort | %ldap_port% | - | ldapTLS | 0 | - | ldapUserDisplayName | displayName | - | ldapUserFilter | (\|(objectclass=inetOrgPerson)) | - | ldapUserFilterMode | 0 | - | ldapUserFilterObjectclass | inetOrgPerson | - | ldapUuidGroupAttribute | auto | - | ldapUuidUserAttribute | auto | - | turnOffCertCheck | 0 | - | useMemberOfToDetectMembership| 1 | - | ldapConfigurationActive | 1 | - When user "user0" requests "/index.php/apps/files" with "GET" using basic auth + | key | value | + | ldapHost | %ldap_host% | + | ldapAgentName | cn=admin,dc=owncloud,dc=com | + | ldapAgentPassword | admin | + | ldapBase | dc=owncloud,dc=com | + | ldapBaseGroups | dc=owncloud,dc=com | + | ldapBaseUsers | dc=owncloud,dc=com | + | ldapEmailAttribute | mail | + | ldapExpertUUIDUserAttr | uid | + | ldapGroupDisplayName | cn | + | ldapGroupFilter | (&(\|(objectclass=posixGroup))) | + | ldapGroupFilterObjectclass | posixGroup | + | ldapGroupMemberAssocAttr | memberUid | + | ldapLoginFilter | (&(\|(objectclass=inetOrgPerson))(\|(uid=%uid)(\|(mailPrimaryAddress=%uid)(mail=%uid)))) | + | ldapLoginFilterEmail | 1 | + | ldapLoginFilterMode | 0 | + | ldapLoginFilterUsername | 1 | + | ldapNestedGroups | 0 | + | ldapPagingSize | 500 | + | ldapPort | %ldap_port% | + | ldapTLS | 0 | + | ldapUserDisplayName | displayName | + | ldapUserFilter | (\|(objectclass=inetOrgPerson)) | + | ldapUserFilterMode | 0 | + | ldapUserFilterObjectclass | inetOrgPerson | + | ldapUuidGroupAttribute | auto | + | ldapUuidUserAttribute | auto | + | turnOffCertCheck | 0 | + | useMemberOfToDetectMembership | 1 | + | ldapConfigurationActive | 1 | + When user "Alice" requests "/index.php/apps/files" with "GET" using basic auth Then the HTTP status code should be "200" Scenario: authentication fails when both configurations have an unreachable host configured Given LDAP config "LDAPTestId" has key "ldapHost" set to "not-existent" And a new LDAP config with the name "SecondaryLdapConfig" has been created And LDAP config "SecondaryLdapConfig" has these settings: - | key | value | - | ldapHost | also-not-there | - | ldapAgentName | cn=admin,dc=owncloud,dc=com | - | ldapAgentPassword | admin | - | ldapBase | dc=owncloud,dc=com | - | ldapBaseGroups | dc=owncloud,dc=com | - | ldapBaseUsers | dc=owncloud,dc=com | - | ldapEmailAttribute | mail | - | ldapExpertUUIDUserAttr | uid | - | ldapGroupDisplayName | cn | - | ldapGroupFilter | (&(\|(objectclass=posixGroup))) | - | ldapGroupFilterObjectclass | posixGroup | - | ldapGroupMemberAssocAttr | memberUid | - | ldapLoginFilter | (&(\|(objectclass=inetOrgPerson))(\|(uid=%uid)(\|(mailPrimaryAddress=%uid)(mail=%uid)))) | - | ldapLoginFilterEmail | 1 | - | ldapLoginFilterMode | 0 | - | ldapLoginFilterUsername | 1 | - | ldapNestedGroups | 0 | - | ldapPagingSize | 500 | - | ldapPort | %ldap_port% | - | ldapTLS | 0 | - | ldapUserDisplayName | displayName | - | ldapUserFilter | (\|(objectclass=inetOrgPerson)) | - | ldapUserFilterMode | 0 | - | ldapUserFilterObjectclass | inetOrgPerson | - | ldapUuidGroupAttribute | auto | - | ldapUuidUserAttribute | auto | - | turnOffCertCheck | 0 | - | useMemberOfToDetectMembership| 1 | - | ldapConfigurationActive | 1 | - When user "user0" requests "/index.php/apps/files" with "GET" using basic auth + | key | value | + | ldapHost | also-not-there | + | ldapAgentName | cn=admin,dc=owncloud,dc=com | + | ldapAgentPassword | admin | + | ldapBase | dc=owncloud,dc=com | + | ldapBaseGroups | dc=owncloud,dc=com | + | ldapBaseUsers | dc=owncloud,dc=com | + | ldapEmailAttribute | mail | + | ldapExpertUUIDUserAttr | uid | + | ldapGroupDisplayName | cn | + | ldapGroupFilter | (&(\|(objectclass=posixGroup))) | + | ldapGroupFilterObjectclass | posixGroup | + | ldapGroupMemberAssocAttr | memberUid | + | ldapLoginFilter | (&(\|(objectclass=inetOrgPerson))(\|(uid=%uid)(\|(mailPrimaryAddress=%uid)(mail=%uid)))) | + | ldapLoginFilterEmail | 1 | + | ldapLoginFilterMode | 0 | + | ldapLoginFilterUsername | 1 | + | ldapNestedGroups | 0 | + | ldapPagingSize | 500 | + | ldapPort | %ldap_port% | + | ldapTLS | 0 | + | ldapUserDisplayName | displayName | + | ldapUserFilter | (\|(objectclass=inetOrgPerson)) | + | ldapUserFilterMode | 0 | + | ldapUserFilterObjectclass | inetOrgPerson | + | ldapUuidGroupAttribute | auto | + | ldapUuidUserAttribute | auto | + | turnOffCertCheck | 0 | + | useMemberOfToDetectMembership | 1 | + | ldapConfigurationActive | 1 | + When user "Alice" requests "/index.php/apps/files" with "GET" using basic auth Then the HTTP status code should be "401" And the last lines of the log file should contain log-entries containing these attributes: - | app | message | - | user_ldap | Error when searching: Can't contact LDAP server code -1 | - | user_ldap | Attempt for Paging? | - | core | Login failed: 'user0' (Remote IP: | + | app | message | + | user_ldap | Error when searching: Can't contact LDAP server code -1 | + | user_ldap | Attempt for Paging? | + | core | Login failed: 'Alice' (Remote IP: | diff --git a/tests/acceptance/features/apiUserLDAP/sharingLocalUserLdapUser.feature b/tests/acceptance/features/apiUserLDAP/sharingLocalUserLdapUser.feature index 523992822..c370b90c5 100644 --- a/tests/acceptance/features/apiUserLDAP/sharingLocalUserLdapUser.feature +++ b/tests/acceptance/features/apiUserLDAP/sharingLocalUserLdapUser.feature @@ -7,15 +7,15 @@ Feature: Sharing between local and LDAP users Given user "local-user" has been created with default attributes in the database user backend And these users have been created with default attributes and skeleton files: | username | - | user0 | - | user1 | - | user2 | + | Alice | + | Brian | + | Carol | And group "grp1" has been created - And user "user1" has been added to group "grp1" - And user "user2" has been added to group "grp1" + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp1" Scenario: Share a folder from an LDAP user to a local user - When user "user0" shares folder "/PARENT" with user "local-user" using the sharing API + When user "Alice" shares folder "/PARENT" with user "local-user" using the sharing API Then the content of file "/PARENT (2)/parent.txt" for user "local-user" should be: """ ownCloud test text file parent @@ -23,48 +23,48 @@ Feature: Sharing between local and LDAP users """ Scenario: Share a folder from an LDAP user to a local user and change folder content - Given user "user0" has shared folder "/PARENT" with user "local-user" + Given user "Alice" has shared folder "/PARENT" with user "local-user" When user "local-user" uploads file with content "new file" to "PARENT (2)/new-file.txt" using the WebDAV API And user "local-user" uploads file with content "changed file" to "PARENT (2)/parent.txt" using the WebDAV API - Then the content of file "/PARENT/new-file.txt" for user "user0" should be "new file" - And the content of file "/PARENT/parent.txt" for user "user0" should be "changed file" + Then the content of file "/PARENT/new-file.txt" for user "Alice" should be "new file" + And the content of file "/PARENT/parent.txt" for user "Alice" should be "changed file" Scenario: Share a folder from an LDAP user to a local user read only - Given user "user0" has shared folder "/PARENT" with user "local-user" with permissions "read" - When user "local-user" uploads file with content "new file" to "PARENT (2)/new-file.txt" using the WebDAV API - Then the HTTP status code should be "403" - And as "user0" file "/PARENT/new-file.txt" should not exist - When user "local-user" uploads file with content "changed file" to "PARENT (2)/parent.txt" using the WebDAV API - Then the HTTP status code should be "403" - And the content of file "/PARENT/parent.txt" for user "user0" should be: + Given user "Alice" has shared folder "/PARENT" with user "local-user" with permissions "read" + When user "local-user" uploads file with content "new file" to "PARENT (2)/new-file.txt" using the WebDAV API + Then the HTTP status code should be "403" + And as "Alice" file "/PARENT/new-file.txt" should not exist + When user "local-user" uploads file with content "changed file" to "PARENT (2)/parent.txt" using the WebDAV API + Then the HTTP status code should be "403" + And the content of file "/PARENT/parent.txt" for user "Alice" should be: """ ownCloud test text file parent """ Scenario: Share a folder from a local user to an LDAP user - When user "local-user" shares folder "/PARENT" with user "user0" using the sharing API - Then the content of file "/PARENT (2)/parent.txt" for user "user0" should be: + When user "local-user" shares folder "/PARENT" with user "Alice" using the sharing API + Then the content of file "/PARENT (2)/parent.txt" for user "Alice" should be: """ ownCloud test text file parent """ Scenario: Share a folder from a local user to an LDAP user and change folder content - Given user "local-user" has shared folder "/PARENT" with user "user0" - When user "user0" uploads file with content "new file" to "PARENT (2)/new-file.txt" using the WebDAV API - And user "user0" uploads file with content "changed file" to "PARENT (2)/parent.txt" using the WebDAV API + Given user "local-user" has shared folder "/PARENT" with user "Alice" + When user "Alice" uploads file with content "new file" to "PARENT (2)/new-file.txt" using the WebDAV API + And user "Alice" uploads file with content "changed file" to "PARENT (2)/parent.txt" using the WebDAV API Then the content of file "/PARENT/new-file.txt" for user "local-user" should be "new file" And the content of file "/PARENT/parent.txt" for user "local-user" should be "changed file" Scenario: Share a folder from a local user to an LDAP user without write permissions - Given user "local-user" has shared folder "/PARENT" with user "user0" with permissions "read" - When user "user0" uploads file with content "new file" to "PARENT (2)/new-file.txt" using the WebDAV API - Then the HTTP status code should be "403" - And as "local-user" file "/PARENT/new-file.txt" should not exist - When user "user0" uploads file with content "changed file" to "PARENT (2)/parent.txt" using the WebDAV API - Then the HTTP status code should be "403" - And the content of file "/PARENT/parent.txt" for user "local-user" should be: + Given user "local-user" has shared folder "/PARENT" with user "Alice" with permissions "read" + When user "Alice" uploads file with content "new file" to "PARENT (2)/new-file.txt" using the WebDAV API + Then the HTTP status code should be "403" + And as "local-user" file "/PARENT/new-file.txt" should not exist + When user "Alice" uploads file with content "changed file" to "PARENT (2)/parent.txt" using the WebDAV API + Then the HTTP status code should be "403" + And the content of file "/PARENT/parent.txt" for user "local-user" should be: """ ownCloud test text file parent @@ -73,7 +73,7 @@ Feature: Sharing between local and LDAP users Scenario: Share a folder from an LDAP user to a local group, delete the group Given group "local-group" has been created in the database user backend And user "local-user" has been added to database backend group "local-group" - When user "user0" shares folder "/PARENT" with group "local-group" using the sharing API + When user "Alice" shares folder "/PARENT" with group "local-group" using the sharing API Then the content of file "/PARENT (2)/parent.txt" for user "local-user" should be: """ ownCloud test text file parent @@ -84,24 +84,24 @@ Feature: Sharing between local and LDAP users Scenario: Share a folder from a local user to an LDAP group, delete the group When user "local-user" shares folder "/PARENT" with group "grp1" using the sharing API - Then the content of file "/PARENT (2)/parent.txt" for user "user1" should be: + Then the content of file "/PARENT (2)/parent.txt" for user "Brian" should be: """ ownCloud test text file parent """ - And the content of file "/PARENT (2)/parent.txt" for user "user2" should be: + And the content of file "/PARENT (2)/parent.txt" for user "Carol" should be: """ ownCloud test text file parent """ When the administrator deletes ldap group "grp1" - Then as "user1" file "/PARENT (2)/parent.txt" should not exist - And as "user2" file "/PARENT (2)/parent.txt" should not exist + Then as "Brian" file "/PARENT (2)/parent.txt" should not exist + And as "Carol" file "/PARENT (2)/parent.txt" should not exist Scenario: Share a folder from an LDAP user to a local group, take member out of the group Given group "local-group" has been created in the database user backend And user "local-user" has been added to database backend group "local-group" - When user "user0" shares folder "/PARENT" with group "local-group" using the sharing API + When user "Alice" shares folder "/PARENT" with group "local-group" using the sharing API Then the content of file "/PARENT (2)/parent.txt" for user "local-user" should be: """ ownCloud test text file parent @@ -112,23 +112,23 @@ Feature: Sharing between local and LDAP users Scenario: Share a folder from a local user to an LDAP group, take member out of the group When user "local-user" shares folder "/PARENT" with group "grp1" using the sharing API - Then the content of file "/PARENT (2)/parent.txt" for user "user1" should be: + Then the content of file "/PARENT (2)/parent.txt" for user "Brian" should be: """ ownCloud test text file parent """ - And the content of file "/PARENT (2)/parent.txt" for user "user2" should be: + And the content of file "/PARENT (2)/parent.txt" for user "Carol" should be: """ ownCloud test text file parent """ - When the administrator removes user "user1" from ldap group "grp1" - Then as "user1" file "/PARENT (2)/parent.txt" should not exist - But as "user2" file "/PARENT (2)/parent.txt" should exist + When the administrator removes user "Brian" from ldap group "grp1" + Then as "Brian" file "/PARENT (2)/parent.txt" should not exist + But as "Carol" file "/PARENT (2)/parent.txt" should exist @issue-364 Scenario: Share a folder from an LDAP user to a local user - Given user "user0" has shared folder "/PARENT" with user "local-user" + Given user "Alice" has shared folder "/PARENT" with user "local-user" When the administrator sets the LDAP config "LDAPTestId" key "ldapHost" to "not-existing" using the occ command And user "local-user" downloads file "/PARENT (2)/parent.txt" using the WebDAV API Then the HTTP status code should be "500" @@ -157,4 +157,4 @@ Feature: Sharing between local and LDAP users """ ownCloud test text file parent - """ \ No newline at end of file + """ diff --git a/tests/acceptance/features/cliProvisioning/groups.feature b/tests/acceptance/features/cliProvisioning/groups.feature index cc3b4fab8..78a5cf67f 100644 --- a/tests/acceptance/features/cliProvisioning/groups.feature +++ b/tests/acceptance/features/cliProvisioning/groups.feature @@ -8,8 +8,8 @@ Feature: add group # In drone the ldap groups have not synced yet. So this occ command is required to sync them. Given the administrator has invoked occ command "group:list" And this user has been created using the occ command: - | username | - | brand-new-user | + | username | displayname | + | Alice | Alice Hansen | Scenario Outline: admin creates a group When the administrator creates group "" using the occ command @@ -25,12 +25,12 @@ Feature: add group Scenario Outline: admin removes a user from a group When the administrator creates group "" using the occ command Then the command should have been successful - When the administrator adds user "brand-new-user" to group "" using the occ command + When the administrator adds user "Alice" to group "" using the occ command Then the command should have been successful - When the administrator removes user "brand-new-user" from group "" using the occ command + When the administrator removes user "Alice" from group "" using the occ command Then the command should have been successful - And the command output should contain the text 'Member "brand-new-user" removed from group ""' - And user "brand-new-user" should not belong to group "" + And the command output should contain the text 'Member "Alice" removed from group ""' + And user "Alice" should not belong to group "" Examples: | group_id | comment | | simplegroup | nothing special here | @@ -41,10 +41,10 @@ Feature: add group Scenario Outline: adding a user to a group When the administrator creates group "" using the occ command Then the command should have been successful - When the administrator adds user "brand-new-user" to group "" using the occ command + When the administrator adds user "Alice" to group "" using the occ command Then the command should have been successful - And the command output should contain the text 'User "brand-new-user" added to group ""' - And user "brand-new-user" should belong to group "" + And the command output should contain the text 'User "Alice" added to group ""' + And user "Alice" should belong to group "" Examples: | group_id | comment | | simplegroup | nothing special here | @@ -70,4 +70,4 @@ Feature: add group And the administrator deletes group "grp1" using the occ command Then the command should have failed with exit code 1 And the command output should contain the text "The specified group could not be deleted" - And group "grp1" should exist \ No newline at end of file + And group "grp1" should exist diff --git a/tests/acceptance/features/cliProvisioning/userSync.feature b/tests/acceptance/features/cliProvisioning/userSync.feature index aaf582353..32373c221 100644 --- a/tests/acceptance/features/cliProvisioning/userSync.feature +++ b/tests/acceptance/features/cliProvisioning/userSync.feature @@ -8,28 +8,28 @@ Feature: sync user using occ command Background: Given these users have been created with default attributes and without skeleton files: | username | - | user0 | - | user1 | + | Alice | + | Brian | @skipOnOcV10.3 Scenario: admin deletes ldap users and syncs only one of them - When the administrator deletes user "user0" using the occ command - And the administrator deletes user "user1" using the occ command - Then user "user0" should not exist - And user "user1" should not exist - When LDAP user "user0" is resynced - Then user "user0" should exist - And user "user1" should not exist + When the administrator deletes user "Alice" using the occ command + And the administrator deletes user "Brian" using the occ command + Then user "Alice" should not exist + And user "Brian" should not exist + When LDAP user "Alice" is resynced + Then user "Alice" should exist + And user "Brian" should not exist @skipOnOcV10.3 Scenario: admin edits ldap users email and syncs only one of them - When the administrator changes the email of user "user0" to "user0@example0.com" using the occ command - And the administrator changes the email of user "user1" to "user1@example1.com" using the occ command - Then user "user0" should exist - And user "user1" should exist - When LDAP user "user0" is resynced - Then the email address of user "user0" should be "user0@example.org" - And the email address of user "user1" should be "user1@example1.com" + When the administrator changes the email of user "Alice" to "alice@example0.com" using the occ command + And the administrator changes the email of user "Brian" to "brian@example1.com" using the occ command + Then user "Alice" should exist + And user "Brian" should exist + When LDAP user "Alice" is resynced + Then the email address of user "Alice" should be "alice@example.org" + And the email address of user "Brian" should be "brian@example1.com" Scenario: admin lists all the enabled backends When the admin lists the enabled user backends using the occ command @@ -41,13 +41,13 @@ Feature: sync user using occ command """ Scenario: admin deletes ldap users and performs full sync - When the administrator deletes user "user0" using the occ command - And the administrator deletes user "user1" using the occ command - Then user "user0" should not exist - And user "user1" should not exist + When the administrator deletes user "Alice" using the occ command + And the administrator deletes user "Brian" using the occ command + Then user "Alice" should not exist + And user "Brian" should not exist When the LDAP users have been resynced - Then user "user0" should exist - And user "user1" should exist + Then user "Alice" should exist + And user "Brian" should exist @issue-511 Scenario: sync a local user diff --git a/tests/acceptance/features/cliProvisioning/users.feature b/tests/acceptance/features/cliProvisioning/users.feature index a7838af23..0c3b0d2e1 100644 --- a/tests/acceptance/features/cliProvisioning/users.feature +++ b/tests/acceptance/features/cliProvisioning/users.feature @@ -8,13 +8,13 @@ Feature: add a user using the using the occ command Background: And these users have been created with default attributes and skeleton files: | username | - | user0 | - | user1 | + | Alice | + | Brian | Scenario: admin creates an ordinary user using the occ command When the administrator creates this user using the occ command: - | username | - | justauser | + | username | displayname | + | justauser | Just User | Then the command should have been successful And the command output should contain the text 'The user "justauser" was created successfully' And user "justauser" should exist @@ -22,25 +22,25 @@ Feature: add a user using the using the occ command Scenario: admin tries to create an existing user Given this user has been created using the occ command: - | username | - | brand-new-user | + | username | displayname | + | brand-new-user | Brand New User | When the administrator tries to create a user "brand-new-user" using the occ command Then the command should have failed with exit code 1 And the command output should contain the text 'The user "brand-new-user" already exists.' Scenario: admin deletes a user Given this user has been created using the occ command: - | username | - | brand-new-user | + | username | displayname | + | brand-new-user | Brand New User | When the administrator deletes user "brand-new-user" using the occ command Then the command should have been successful - And the command output should contain the text "User with uid 'brand-new-user', display name 'brand-new-user', email '' was deleted" + And the command output should contain the text "User with uid 'brand-new-user', display name 'Brand New User', email '' was deleted" And user "brand-new-user" should not exist Scenario: the administrator can edit a user email Given this user has been created using the occ command: - | username | - | brand-new-user | + | username | displayname | + | brand-new-user | Brand New User | When the administrator changes the email of user "brand-new-user" to "brand-new-user@example.com" using the occ command Then the command should have been successful And the command output should contain the text 'The email address of brand-new-user updated to brand-new-user@example.com' @@ -50,8 +50,8 @@ Feature: add a user using the using the occ command Scenario: the administrator can edit a user display name Given this user has been created using the occ command: - | username | - | brand-new-user | + | username | displayname | + | brand-new-user | Brand New User | When the administrator changes the display name of user "brand-new-user" to "A New User" using the occ command Then the command should have been successful And the command output should contain the text 'The displayname of brand-new-user updated to A New User' @@ -60,40 +60,39 @@ Feature: add a user using the using the occ command | displayname | A New User | Scenario: admin deletes ldap defined user and syncs again - When the administrator deletes user "user0" using the occ command + When the administrator deletes user "Alice" using the occ command Then the command should have been successful - And the command output should contain the text "User with uid 'user0', display name 'User Zero', email 'user0@example.org' was deleted" - And user "user0" should not exist + And the command output should contain the text "User with uid 'Alice', display name 'Alice Hansen', email 'alice@example.org' was deleted" + And user "Alice" should not exist When the LDAP users are resynced - Then user "user0" should exist + Then user "Alice" should exist Scenario: admin tries to modify displayname of user for which an LDAP attribute is specified - When the administrator sets the ldap attribute "displayname" of the entry "uid=user1,ou=TestUsers" to "ldap user" + When the administrator sets the ldap attribute "displayname" of the entry "uid=Brian,ou=TestUsers" to "ldap user" And the LDAP users are resynced - And the administrator changes the display name of user "user1" to "occ user" using the occ command + And the administrator changes the display name of user "Brian" to "occ user" using the occ command Then the command should have failed with exit code 1 - And user "user1" should exist + And user "Brian" should exist And the user attributes returned by the API should include - | displayname | ldap user | + | displayname | ldap user | Scenario: admin tries to modify password of user for which an LDAP attribute is specified - When the administrator sets the ldap attribute "userpassword" of the entry "uid=user1,ou=TestUsers" to "ldap_password" + When the administrator sets the ldap attribute "userpassword" of the entry "uid=Brian,ou=TestUsers" to "ldap_password" And the LDAP users are resynced - And the administrator resets the password of user "user1" to "occ_password" using the occ command + And the administrator resets the password of user "Brian" to "occ_password" using the occ command Then the command should have failed with exit code 1 - And user "user1" should exist - 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 "user1" using password "occ_password" should not be able to download file "textfile0.txt" + And user "Brian" should exist + And the content of file "textfile0.txt" for user "Brian" using password "ldap_password" should be "ownCloud test text file 0" plus end-of-line + But user "Brian" using password "occ_password" should not be able to download file "textfile0.txt" @issue-core-33186 Scenario: admin tries to modify mail of user for which an LDAP attribute is specified - When the administrator sets the ldap attribute "mail" of the entry "uid=user1,ou=TestUsers" to "ldapuser@oc.com" + When the administrator sets the ldap attribute "mail" of the entry "uid=Brian,ou=TestUsers" to "ldapuser@oc.com" And the LDAP users are resynced - And the administrator changes the email of user "user1" to "occuser@oc.com" using the occ command + And the administrator changes the email of user "Brian" to "occuser@oc.com" using the occ command Then the command should have been successful #Then the command should have failed with exit code 1 - And user "user1" should exist + And user "Brian" should exist And the user attributes returned by the API should include #| email | ldapuser@oc.com| - | email | occuser@oc.com| - + | email | occuser@oc.com | diff --git a/tests/acceptance/features/webUIProvisioning/groups.feature b/tests/acceptance/features/webUIProvisioning/groups.feature index 6cd58c621..d4640fbc8 100644 --- a/tests/acceptance/features/webUIProvisioning/groups.feature +++ b/tests/acceptance/features/webUIProvisioning/groups.feature @@ -7,14 +7,14 @@ Feature: add group Background: And these users have been created with default attributes and skeleton files: | username | - | user0 | - | user1 | - | user2 | + | Alice | + | Brian | + | Carol | And group "grp1" has been created # 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" - And user "user1" has been added to group "grp1" - And user "user2" has been added to group "grp1" + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp1" And user admin has logged in using the webUI And the administrator has browsed to the users page @@ -54,8 +54,8 @@ Feature: add group Scenario: delete ldap defined group When the administrator deletes the group named "grp1" using the webUI and confirms the deletion using the webUI Then dialog should be displayed on the webUI - | title | content | - | Unable to delete grp1 | Unable to delete group. | + | title | content | + | Unable to delete grp1 | Unable to delete group. | And group "grp1" should exist Scenario: Adding database user to database group should be possible @@ -77,13 +77,13 @@ Feature: add group Scenario: Adding LDAP user to database group should be possible Given group "db-group" has been created in the database user backend And the administrator has browsed to the users page - When the administrator adds user "user0" to group "db-group" using the webUI - Then user "user0" should exist - And user "user0" should belong to group "db-group" + When the administrator adds user "Alice" to group "db-group" using the webUI + Then user "Alice" should exist + And user "Alice" should belong to group "db-group" @issue-core-25224 Scenario: Adding LDAP user to LDAP group should not be possible Given the administrator has browsed to the users page - When the administrator adds user "user0" to group "grp1" using the webUI - Then user "user0" should exist - And user "user0" should not belong to group "grp1" + When the administrator adds user "Alice" to group "grp1" using the webUI + Then user "Alice" should exist + And user "Alice" should not belong to group "grp1" diff --git a/tests/acceptance/features/webUIProvisioning/users.feature b/tests/acceptance/features/webUIProvisioning/users.feature index a6e1cabf7..b01765700 100644 --- a/tests/acceptance/features/webUIProvisioning/users.feature +++ b/tests/acceptance/features/webUIProvisioning/users.feature @@ -7,8 +7,8 @@ Feature: add users Background: Given these users have been created with default attributes and skeleton files: | username | - | user0 | - | user1 | + | Alice | + | Brian | And user admin has logged in using the webUI And the administrator has browsed to the users page @@ -35,7 +35,7 @@ Feature: add users Then "New User" should be shown as the name of the current user on the WebUI And user "new-user" should exist And the user attributes returned by the API should include - | displayname | New User | + | displayname | New User | Scenario: Admin changes the password of the user Given user "new-user" has been created with default attributes in the database user backend @@ -46,75 +46,75 @@ Feature: add users But user "new-user" using password "%regular%" should not be able to download file "textfile0.txt" Scenario: use the webUI to create a simple user with same username as existing ldap user - When the administrator creates a user with the name "user1" and the password "%regular%" using the webUI + When the administrator creates a user with the name "Brian" and the password "%regular%" using the webUI Then a notification should be displayed on the webUI with the text "Error creating user: A user with that name already exists." - And user "user1" should exist - But user "user1" using password "%regular%" should not be able to download file "textfile0.txt" + And user "Brian" should exist + But user "Brian" using password "%regular%" should not be able to download file "textfile0.txt" Scenario: admin deletes ldap defined user and syncs again - When the administrator deletes user "user0" using the webUI and confirms the deletion using the webUI - Then user "user0" should not exist - When the deleted user "user0" tries to login using the password "%alt1%" using the webUI + When the administrator deletes user "Alice" using the webUI and confirms the deletion using the webUI + Then user "Alice" should not exist + When the deleted user "Alice" tries to login using the password "%alt1%" using the webUI Then the user should be redirected to a webUI page with the title "%productname%" When the LDAP users are resynced - Then user "user0" should exist + Then user "Alice" should exist When the user has browsed to the login page - And user "user0" logs in using the webUI + And user "Alice" logs in using the webUI Then the user should be redirected to a webUI page with the title "Files - %productname%" @issue-core-33186 Scenario: admin tries to modify displayname of user for which an LDAP attribute is specified - When the administrator sets the ldap attribute "displayname" of the entry "uid=user0,ou=TestUsers" to "ldap user" - And the administrator changes the display name of user "user0" to "New User" using the webUI + When the administrator sets the ldap attribute "displayname" of the entry "uid=Alice,ou=TestUsers" to "ldap user" + And the administrator changes the display name of user "Alice" to "New User" using the webUI And the administrator logs out of the webUI - And user "user0" logs in using the webUI + And user "Alice" logs in using the webUI Then "ldap user" should be shown as the name of the current user on the WebUI - And user "user0" should exist + And user "Alice" should exist And the user attributes returned by the API should include - | displayname | ldap user | + | displayname | ldap user | @issue-core-33186 Scenario: admin tries to modify email of user for which an LDAP attribute is specified - When the administrator sets the ldap attribute "mail" of the entry "uid=user1,ou=TestUsers" to "ldapuser@oc.com" - And the administrator changes the email of user "user1" to "webuiemail@oc.com" using the webUI + When the administrator sets the ldap attribute "mail" of the entry "uid=Brian,ou=TestUsers" to "ldapuser@oc.com" + And the administrator changes the email of user "Brian" to "webuiemail@oc.com" using the webUI And the LDAP users are resynced - Then user "user1" should exist - But the email address of user "user1" should be "ldapuser@oc.com" + Then user "Brian" should exist + But the email address of user "Brian" should be "ldapuser@oc.com" @issue-core-33186 Scenario: admin tries to modify password of user for which an LDAP attribute is specified Given the administrator has browsed to the users page - When the administrator sets the ldap attribute "userpassword" of the entry "uid=user0,ou=TestUsers" to "ldap_password" - And the administrator changes the password of user "user0" to "webui_password" using the webUI - Then user "user0" should exist - And user "user0" using password "webui_password" should not be able to download file "textfile0.txt" - And the content of file "textfile0.txt" for user "user0" using password "ldap_password" should be "ownCloud test text file 0" plus end-of-line + When the administrator sets the ldap attribute "userpassword" of the entry "uid=Alice,ou=TestUsers" to "ldap_password" + And the administrator changes the password of user "Alice" to "webui_password" using the webUI + Then user "Alice" should exist + And user "Alice" using password "webui_password" should not be able to download file "textfile0.txt" + And the content of file "textfile0.txt" for user "Alice" using password "ldap_password" should be "ownCloud test text file 0" plus end-of-line @issue-core-33186 Scenario: admin tries to modify quota of user for which an LDAP attribute is specified #to set Quota we can just misuse any LDAP text field Given LDAP config "LDAPTestId" has key "ldapQuotaAttribute" set to "employeeNumber" - When the administrator sets the ldap attribute "employeeNumber" of the entry "uid=user0,ou=TestUsers" to "10 MB" - And the administrator sets the quota of user "user0" to "13 MB" using the webUI - Then the quota definition of user "user0" should be "13 MB" - And the quota of user "user0" should be set to "13 MB" on the webUI - #And the quota definition of user "user0" should be "10 MB" + When the administrator sets the ldap attribute "employeeNumber" of the entry "uid=Alice,ou=TestUsers" to "10 MB" + And the administrator sets the quota of user "Alice" to "13 MB" using the webUI + Then the quota definition of user "Alice" should be "13 MB" + And the quota of user "Alice" should be set to "13 MB" on the webUI + #And the quota definition of user "Alice" should be "10 MB" When the LDAP users are resynced And the administrator reloads the users page - Then the quota definition of user "user0" should be "10 MB" - And the quota of user "user0" should be set to "10 MB" on the webUI + Then the quota definition of user "Alice" should be "10 MB" + And the quota of user "Alice" should be set to "10 MB" on the webUI Scenario: admin sets quota of user for which no LDAP quota attribute is specified #to set Quota we can just misuse any LDAP text field Given LDAP config "LDAPTestId" has key "ldapQuotaAttribute" set to "employeeNumber" And the LDAP users have been resynced - And the administrator sets the quota of user "user0" to "13 MB" using the webUI - Then the quota definition of user "user0" should be "13 MB" - And the quota of user "user0" should be set to "13 MB" on the webUI + And the administrator sets the quota of user "Alice" to "13 MB" using the webUI + Then the quota definition of user "Alice" should be "13 MB" + And the quota of user "Alice" should be set to "13 MB" on the webUI When the LDAP users are resynced And the administrator reloads the users page - Then the quota definition of user "user0" should be "13 MB" - And the quota of user "user0" should be set to "13 MB" on the webUI + Then the quota definition of user "Alice" should be "13 MB" + And the quota of user "Alice" should be set to "13 MB" on the webUI @issue-core-33186 Scenario: admin sets quota of user for which no LDAP quota attribute is specified but a default quota is set in the LDAP settings @@ -122,39 +122,39 @@ Feature: add users Given LDAP config "LDAPTestId" has key "ldapQuotaAttribute" set to "employeeNumber" And LDAP config "LDAPTestId" has key "ldapQuotaDefault" set to "10MB" And the LDAP users have been resynced - When the administrator sets the quota of user "user0" to "13 MB" using the webUI - Then the quota definition of user "user0" should be "13 MB" - And the quota of user "user0" should be set to "13 MB" on the webUI - #Then the administrator should not be able to set the quota for user "user0" using the webUI + When the administrator sets the quota of user "Alice" to "13 MB" using the webUI + Then the quota definition of user "Alice" should be "13 MB" + And the quota of user "Alice" should be set to "13 MB" on the webUI + #Then the administrator should not be able to set the quota for user "Alice" using the webUI When the LDAP users are resynced And the administrator reloads the users page - Then the quota definition of user "user0" should be "10MB" - And the quota of user "user0" should be set to "10MB" on the webUI + Then the quota definition of user "Alice" should be "10MB" + And the quota of user "Alice" should be set to "10MB" on the webUI Scenario: admin sets quota of user in LDAP when a default quota is set in the LDAP settings #to set Quota we can just misuse any LDAP text field Given LDAP config "LDAPTestId" has key "ldapQuotaAttribute" set to "employeeNumber" And LDAP config "LDAPTestId" has key "ldapQuotaDefault" set to "10MB" And the LDAP users have been resynced - When the administrator sets the ldap attribute "employeeNumber" of the entry "uid=user0,ou=TestUsers" to "13 MB" + When the administrator sets the ldap attribute "employeeNumber" of the entry "uid=Alice,ou=TestUsers" to "13 MB" And the administrator reloads the users page - Then the quota of user "user0" should be set to "10MB" on the webUI + Then the quota of user "Alice" should be set to "10MB" on the webUI When the LDAP users are resynced And the administrator reloads the users page - Then the quota of user "user0" should be set to "13 MB" on the webUI + Then the quota of user "Alice" should be set to "13 MB" on the webUI @issue-core-33186 Scenario: admin sets quota of user when the quota LDAP attribute is specified and a default quota is set in the LDAP settings #to set Quota we can just misuse any LDAP text field Given LDAP config "LDAPTestId" has key "ldapQuotaAttribute" set to "employeeNumber" And LDAP config "LDAPTestId" has key "ldapQuotaDefault" set to "10MB" - When the administrator sets the ldap attribute "employeeNumber" of the entry "uid=user0,ou=TestUsers" to "11 MB" + When the administrator sets the ldap attribute "employeeNumber" of the entry "uid=Alice,ou=TestUsers" to "11 MB" And the LDAP users are resynced - And the administrator sets the quota of user "user0" to "13 MB" using the webUI - #Then the administrator should not be able to set the quota for user "user0" using the webUI - Then the quota definition of user "user0" should be "13 MB" - And the quota of user "user0" should be set to "13 MB" on the webUI + And the administrator sets the quota of user "Alice" to "13 MB" using the webUI + #Then the administrator should not be able to set the quota for user "Alice" using the webUI + Then the quota definition of user "Alice" should be "13 MB" + And the quota of user "Alice" should be set to "13 MB" on the webUI When the LDAP users are resynced And the administrator reloads the users page - Then the quota definition of user "user0" should be "11 MB" - And the quota of user "user0" should be set to "11 MB" on the webUI \ No newline at end of file + Then the quota definition of user "Alice" should be "11 MB" + And the quota of user "Alice" should be set to "11 MB" on the webUI diff --git a/tests/acceptance/features/webUIUserLDAP/avatar.feature b/tests/acceptance/features/webUIUserLDAP/avatar.feature index 426adc68c..3d9a6c9de 100644 --- a/tests/acceptance/features/webUIUserLDAP/avatar.feature +++ b/tests/acceptance/features/webUIUserLDAP/avatar.feature @@ -6,18 +6,18 @@ Feature: providing an avatar by LDAP So that other users can recognize me by my picture Background: - Given user "user2" has been created with default attributes and without skeleton files + Given user "Alice" has been created with default attributes and without skeleton files @skip @issue-198 #we cannot revert this even with deleting the user Scenario: upload an avatar to the LDAP server - When the administrator sets the ldap attribute "jpegPhoto" of the entry "uid=user2,ou=TestUsers" to the content of the file "testavatar.jpg" - And user "user2" has logged in using the webUI + When the administrator sets the ldap attribute "jpegPhoto" of the entry "uid=Alice,ou=TestUsers" to the content of the file "testavatar.jpg" + And user "Alice" has logged in using the webUI Then the display name should not be visible on the WebUI And an avatar should be shown for the current user on the WebUI Scenario: set the avatar on the LDAP server to an invalid string - When the administrator sets the ldap attribute "jpegPhoto" of the entry "uid=user2,ou=TestUsers" to "0" - And user "user2" has logged in using the webUI + When the administrator sets the ldap attribute "jpegPhoto" of the entry "uid=Alice,ou=TestUsers" to "0" + And user "Alice" has logged in using the webUI Then the display name should be visible on the WebUI - And "User Two" should be shown as the name of the current user on the WebUI - And no avatar should be shown for the current user on the WebUI \ No newline at end of file + And "Alice Hansen" should be shown as the name of the current user on the WebUI + And no avatar should be shown for the current user on the WebUI diff --git a/tests/acceptance/features/webUIUserLDAP/changingDisplayName.feature b/tests/acceptance/features/webUIUserLDAP/changingDisplayName.feature index 85794b627..e1b312398 100644 --- a/tests/acceptance/features/webUIUserLDAP/changingDisplayName.feature +++ b/tests/acceptance/features/webUIUserLDAP/changingDisplayName.feature @@ -6,11 +6,11 @@ Feature: changing display name So that users can be found by their LDAP names Background: - Given user "user1" has been created with default attributes and without skeleton files + Given user "Alice" has been created with default attributes and without skeleton files Scenario Outline: change display name on the LDAP server - Given the administrator sets the ldap attribute "displayname" of the entry "uid=user1,ou=TestUsers" to "" - When user "user1" logs in using the webUI + Given the administrator sets the ldap attribute "displayname" of the entry "uid=Alice,ou=TestUsers" to "" + When user "Alice" logs in using the webUI Then "" should be shown as the name of the current user on the WebUI Examples: | new-displayname | @@ -20,14 +20,14 @@ Feature: changing display name @skip @issue-core-30657 Scenario: change display name on the LDAP server - Given the administrator sets the ldap attribute "displayname" of the entry "uid=user1,ou=TestUsers" to "0" - When user "user1" logs in using the webUI + Given the administrator sets the ldap attribute "displayname" of the entry "uid=Alice,ou=TestUsers" to "0" + When user "Alice" logs in using the webUI Then "0" should be shown as the name of the current user on the WebUI Scenario: delete display name on the LDAP server - Given user "user2" has been created with default attributes and without skeleton files - And the administrator sets the ldap attribute "displayname" of the entry "uid=user1,ou=TestUsers" to "" - When user "user1" logs in using the webUI - Then "user1" should be shown as the name of the current user on the WebUI - When the user re-logs in as "user2" using the webUI - Then "User Two" should be shown as the name of the current user on the WebUI \ No newline at end of file + Given user "Brian" has been created with default attributes and without skeleton files + And the administrator sets the ldap attribute "displayname" of the entry "uid=Alice,ou=TestUsers" to "" + When user "Alice" logs in using the webUI + Then "Alice" should be shown as the name of the current user on the WebUI + When the user re-logs in as "Brian" using the webUI + Then "Brian Murphy" should be shown as the name of the current user on the WebUI diff --git a/tests/acceptance/features/webUIUserLDAP/changingPassword.feature b/tests/acceptance/features/webUIUserLDAP/changingPassword.feature index 4102970ea..239e21116 100644 --- a/tests/acceptance/features/webUIUserLDAP/changingPassword.feature +++ b/tests/acceptance/features/webUIUserLDAP/changingPassword.feature @@ -6,13 +6,13 @@ Feature: changing password So that I do not have to remember multiple passwords Scenario Outline: change password on the LDAP server - Given user "user1" has been created with default attributes and without skeleton files - When the administrator sets the ldap attribute "userpassword" of the entry "uid=user1,ou=TestUsers" to "" - Then it should not be possible to login with the username "user1" and password "%alt1%" using the WebUI - But it should be possible to login with the username "user1" and password "" using the WebUI + Given user "Alice" has been created with default attributes and without skeleton files + When the administrator sets the ldap attribute "userpassword" of the entry "uid=Alice,ou=TestUsers" to "" + Then it should not be possible to login with the username "Alice" and password "%regular%" using the WebUI + But it should be possible to login with the username "Alice" and password "" using the WebUI Examples: | new-password | | 999 | | 0 | | пароль | - | null | \ No newline at end of file + | null | diff --git a/tests/acceptance/features/webUIUserLDAP/groupMembership.feature b/tests/acceptance/features/webUIUserLDAP/groupMembership.feature index 389624285..d77ffc2a6 100644 --- a/tests/acceptance/features/webUIUserLDAP/groupMembership.feature +++ b/tests/acceptance/features/webUIUserLDAP/groupMembership.feature @@ -8,46 +8,46 @@ Feature: group membership Background: Given these users have been created with default attributes and skeleton files: | username | - | user1 | - | user2 | - | user3 | - | user4 | + | Alice | + | Brian | + | Carol | + | David | And group "grp1" has been created And group "grp3" has been created - And user "user1" has been added to group "grp1" - And user "user2" has been added to group "grp1" - And user "user3" has been added to group "grp3" - And user "user1" has logged in using the webUI + And user "Alice" has been added to group "grp1" + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp3" + And user "Alice" has logged in using the webUI @skipOnOcV10.2 Scenario: adding a new user to a group after a folder was shared with that group When the user shares folder "simple-folder" with group "grp1" using the webUI #ToDo use API calls - And the administrator adds user "user3" to ldap group "grp1" - When the user re-logs in as "user3" using the webUI + And the administrator adds user "Carol" to ldap group "grp1" + When the user re-logs in as "Carol" using the webUI Then folder "simple-folder (2)" should be listed on the webUI - And folder "simple-folder (2)" should be marked as shared with "grp1" by "User One" on the webUI + And folder "simple-folder (2)" should be marked as shared with "grp1" by "Alice" on the webUI @skipOnOcV10.2 Scenario: deleting a user from a group after a folder was shared with that group When the user shares folder "simple-folder" with group "grp1" using the webUI #ToDo use API calls - And the administrator removes user "user2" from ldap group "grp1" - When the user re-logs in as "user2" using the webUI + And the administrator removes user "Brian" from ldap group "grp1" + When the user re-logs in as "Brian" using the webUI Then folder "simple-folder (2)" should not be listed on the webUI @skipOnOcV10.2 Scenario: simple sharing with a group When the user shares folder "simple-folder" with group "grp1" using the webUI #ToDo use API calls - When the user re-logs in as "user2" using the webUI + When the user re-logs in as "Brian" using the webUI Then folder "simple-folder (2)" should be listed on the webUI @skipOnOcV10.2 Scenario: simple sharing with a group but user no in it When the user shares folder "simple-folder" with group "grp1" using the webUI #ToDo use API calls - When the user re-logs in as "user3" using the webUI + When the user re-logs in as "Carol" using the webUI Then folder "simple-folder (2)" should not be listed on the webUI @skipOnOcV10.2 @@ -55,16 +55,16 @@ Feature: group membership When the user shares folder "simple-folder" with group "grp1" using the webUI #ToDo use API calls And the administrator deletes ldap group "grp1" - When the user re-logs in as "user2" using the webUI + When the user re-logs in as "Brian" using the webUI Then folder "simple-folder (2)" should not be listed on the webUI @skipOnOcV10.2 Scenario: sharing with non unique group name (using non-unique group name) Given the administrator creates group "grp1" in ldap OU "TestUsers" - And the administrator adds user "user3" to group "grp1" in ldap OU "TestUsers" + And the administrator adds user "Carol" to group "grp1" in ldap OU "TestUsers" When the user shares folder "simple-folder" with group "grp1" using the webUI #ToDo use API calls - When the user re-logs in as "user3" using the webUI + When the user re-logs in as "Carol" using the webUI Then folder "simple-folder (2)" should not be listed on the webUI @skipOnOcV10.2 @@ -75,7 +75,7 @@ Feature: group membership | key | value | | ldapGroupFilter | (&(\|(objectclass=posixGroup))(\|(cn=grp2))) | | ldapGroupFilterGroups | grp2 | - When the user re-logs in as "user2" using the webUI + When the user re-logs in as "Brian" using the webUI Then folder "simple-folder (2)" should not be listed on the webUI @skipOnOcV10.2 diff --git a/tests/acceptance/features/webUIUserLDAP/loginUsingEmailAddress.feature b/tests/acceptance/features/webUIUserLDAP/loginUsingEmailAddress.feature index 427b5c637..1e9c20f99 100644 --- a/tests/acceptance/features/webUIUserLDAP/loginUsingEmailAddress.feature +++ b/tests/acceptance/features/webUIUserLDAP/loginUsingEmailAddress.feature @@ -6,25 +6,25 @@ Feature: login users So that they only need to remember one username and password (SSO) Background: - Given user "user1" has been created with default attributes and without skeleton files + Given user "Alice" has been created with default attributes and without skeleton files Scenario: login with default settings When the LDAP users have been resynced - Then it should be possible to login with the username "user1@example.org" and password "%alt1%" using the WebUI + Then it should be possible to login with the username "alice@example.org" and password "%regular%" using the WebUI Scenario: using ldap filter including email field When LDAP config "LDAPTestId" has these settings: | key | value | | ldapLoginFilter | (&(objectclass=inetOrgPerson)(\|(uid=%uid)(mailPrimaryAddress=%uid)(mail=%uid))) | | ldapEmailAttribute | | - Then it should be possible to login with the username "user1@example.org" and password "%alt1%" using the WebUI + Then it should be possible to login with the username "alice@example.org" and password "%regular%" using the WebUI Scenario: using ldapEmailAttribute but loginFilter lacks email field When LDAP config "LDAPTestId" has these settings: | key | value | | ldapLoginFilter | (&(objectclass=inetOrgPerson)(uid=%uid)) | | ldapEmailAttribute | mail | - Then it should be possible to login with the username "user1@example.org" and password "%alt1%" using the WebUI + Then it should be possible to login with the username "alice@example.org" and password "%regular%" using the WebUI Scenario: no ldapEmailAttribute and loginFilter lacks email field When LDAP config "LDAPTestId" has these settings: @@ -32,34 +32,34 @@ Feature: login users | ldapLoginFilter | (&(objectclass=inetOrgPerson)(uid=%uid)) | | ldapEmailAttribute | | And the LDAP users have been resynced - Then it should not be possible to login with the username "user1@example.org" and password "%alt1%" using the WebUI + Then it should not be possible to login with the username "alice@example.org" and password "%regular%" using the WebUI Scenario: change Email address on LDAP server - When the administrator sets the ldap attribute "mail" of the entry "uid=user1,ou=TestUsers" to "user1-change@example.org" + When the administrator sets the ldap attribute "mail" of the entry "uid=Alice,ou=TestUsers" to "Alice-change@example.org" And the LDAP users have been resynced #need a sync here because the automatic sync only happens after login #so after changing the email address one last login is possible with the old address - Then it should not be possible to login with the username "user1@example.org" and password "%alt1%" using the WebUI - But it should be possible to login with the username "user1-change@example.org" and password "%alt1%" using the WebUI + Then it should not be possible to login with the username "alice@example.org" and password "%regular%" using the WebUI + But it should be possible to login with the username "Alice-change@example.org" and password "%regular%" using the WebUI Scenario: change Email address on LDAP server, do not sync - When the administrator sets the ldap attribute "mail" of the entry "uid=user1,ou=TestUsers" to "user1-change@example.org" - Then it should be possible to login with the username "user1-change@example.org" and password "%alt1%" using the WebUI + When the administrator sets the ldap attribute "mail" of the entry "uid=Alice,ou=TestUsers" to "Alice-change@example.org" + Then it should be possible to login with the username "Alice-change@example.org" and password "%regular%" using the WebUI Scenario: add a second Email address - When the administrator adds "user1-change@example.org" to the ldap attribute "mail" of the entry "uid=user1,ou=TestUsers" - Then it should be possible to login with the username "user1@example.org" and password "%alt1%" using the WebUI + When the administrator adds "Alice-change@example.org" to the ldap attribute "mail" of the entry "uid=Alice,ou=TestUsers" + Then it should be possible to login with the username "alice@example.org" and password "%regular%" using the WebUI When the user logs out of the webUI - Then it should be possible to login with the username "user1-change@example.org" and password "%alt1%" using the WebUI + Then it should be possible to login with the username "Alice-change@example.org" and password "%regular%" using the WebUI Scenario: delete the Email address - Given user "user2" has been created with default attributes and without skeleton files - When the administrator sets the ldap attribute "mail" of the entry "uid=user1,ou=TestUsers" to "" + Given user "Brian" has been created with default attributes and without skeleton files + When the administrator sets the ldap attribute "mail" of the entry "uid=Alice,ou=TestUsers" to "" And the LDAP users have been resynced - Then it should not be possible to login with the username "user1@example.org" and password "%alt1%" using the WebUI - But it should be possible to login with the username "user1" and password "%alt1%" using the WebUI + Then it should not be possible to login with the username "alice@example.org" and password "%regular%" using the WebUI + But it should be possible to login with the username "Alice" and password "%regular%" using the WebUI When the user logs out of the webUI - Then it should be possible to login with the username "user2@example.org" and password "%alt2%" using the WebUI + Then it should be possible to login with the username "brian@example.org" and password "%alt1%" using the WebUI @skipOnOcV10.2 Scenario: login with a new user diff --git a/tests/acceptance/features/webUIUserLDAP/paging.feature b/tests/acceptance/features/webUIUserLDAP/paging.feature index 938aa4d54..dde3ae2c0 100644 --- a/tests/acceptance/features/webUIUserLDAP/paging.feature +++ b/tests/acceptance/features/webUIUserLDAP/paging.feature @@ -39,4 +39,3 @@ Feature: paging When the user types "12" in the share-with-field Then all users and groups that contain the string "12" in their name should be listed in the autocomplete list on the webUI And the users own name should not be listed in the autocomplete list on the webUI -