From 8be87ceed5818519986f346167d89dba0f14adf0 Mon Sep 17 00:00:00 2001 From: Phil Davis Date: Thu, 19 Dec 2019 17:37:39 +0545 Subject: [PATCH] Add provisioning API tests for usernames with special characters --- .../features/apiProvisioning-v1/addUser.feature | 12 ++++++++++++ .../apiProvisioning-v1/deleteUser.feature | 13 +++++++++++++ .../apiProvisioning-v1/disableUser.feature | 13 +++++++++++++ .../features/apiProvisioning-v1/editUser.feature | 13 +++++++++++++ .../apiProvisioning-v1/enableUser.feature | 14 ++++++++++++++ .../features/apiProvisioning-v1/getUser.feature | 15 +++++++++++++++ .../features/apiProvisioning-v2/addUser.feature | 12 ++++++++++++ .../apiProvisioning-v2/deleteUser.feature | 13 +++++++++++++ .../apiProvisioning-v2/disableUser.feature | 13 +++++++++++++ .../features/apiProvisioning-v2/editUser.feature | 13 +++++++++++++ .../apiProvisioning-v2/enableUser.feature | 14 ++++++++++++++ .../features/apiProvisioning-v2/getUser.feature | 15 +++++++++++++++ 12 files changed, 160 insertions(+) diff --git a/tests/acceptance/features/apiProvisioning-v1/addUser.feature b/tests/acceptance/features/apiProvisioning-v1/addUser.feature index 74eaedb3139a..9a380174526e 100644 --- a/tests/acceptance/features/apiProvisioning-v1/addUser.feature +++ b/tests/acceptance/features/apiProvisioning-v1/addUser.feature @@ -16,6 +16,18 @@ Feature: add user And user "brand-new-user" should exist And user "brand-new-user" should be able to access a skeleton file + Scenario Outline: admin creates a user with special characters in the username + Given user "" has been deleted + When the administrator sends a user creation request for user "" password "%alt1%" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "" should exist + And user "" should be able to access a skeleton file + Examples: + | username | + | a@-+_.b | + | a space | + Scenario: admin tries to create an existing user Given user "brand-new-user" has been created with default attributes and skeleton files When the administrator sends a user creation request for user "brand-new-user" password "%alt1%" using the provisioning API diff --git a/tests/acceptance/features/apiProvisioning-v1/deleteUser.feature b/tests/acceptance/features/apiProvisioning-v1/deleteUser.feature index 68707f416061..9b6b12b279aa 100644 --- a/tests/acceptance/features/apiProvisioning-v1/deleteUser.feature +++ b/tests/acceptance/features/apiProvisioning-v1/deleteUser.feature @@ -15,6 +15,19 @@ Feature: delete users And the HTTP status code should be "200" And user "brand-new-user" should not exist + Scenario Outline: Delete a user with special characters in the username + Given these users have been created with skeleton files: + | username | email | + | | | + When the administrator deletes user "" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "" should not exist + Examples: + | username | email | + | a@-+_.b | a.b@example.com | + | a space | a.space@example.com | + Scenario: Delete a user, and specify the user name in different case Given user "brand-new-user" has been created with default attributes and skeleton files When the administrator deletes user "Brand-New-User" using the provisioning API diff --git a/tests/acceptance/features/apiProvisioning-v1/disableUser.feature b/tests/acceptance/features/apiProvisioning-v1/disableUser.feature index 691a6a9100e5..a045810de44f 100644 --- a/tests/acceptance/features/apiProvisioning-v1/disableUser.feature +++ b/tests/acceptance/features/apiProvisioning-v1/disableUser.feature @@ -15,6 +15,19 @@ Feature: disable user And the HTTP status code should be "200" And user "user1" should be disabled + Scenario Outline: admin disables an user with special characters in the username + Given these users have been created with skeleton files: + | username | email | + | | | + When the administrator disables user "" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "" should be disabled + Examples: + | username | email | + | a@-+_.b | a.b@example.com | + | a space | a.space@example.com | + @smokeTest Scenario: Subadmin should be able to disable an user in their group Given these users have been created with default attributes and skeleton files: diff --git a/tests/acceptance/features/apiProvisioning-v1/editUser.feature b/tests/acceptance/features/apiProvisioning-v1/editUser.feature index e67b85edeb92..a3ceb756335e 100644 --- a/tests/acceptance/features/apiProvisioning-v1/editUser.feature +++ b/tests/acceptance/features/apiProvisioning-v1/editUser.feature @@ -15,6 +15,19 @@ Feature: edit users And the OCS status code should be "100" And the email address of user "brand-new-user" should be "brand-new-user@example.com" + Scenario Outline: the administrator can edit a user email of an user with special characters in the username + Given these users have been created with skeleton files: + | username | email | + | | | + When the administrator changes the email of user "" to "a-different-email@example.com" using the provisioning API + Then the HTTP status code should be "200" + And the OCS status code should be "100" + And the email address of user "" should be "a-different-email@example.com" + Examples: + | username | email | + | a@-+_.b | a.b@example.com | + | a space | a.space@example.com | + @smokeTest Scenario: the administrator can edit a user display (the API allows editing the "display name" by using the key word "display") Given user "brand-new-user" has been created with default attributes and skeleton files diff --git a/tests/acceptance/features/apiProvisioning-v1/enableUser.feature b/tests/acceptance/features/apiProvisioning-v1/enableUser.feature index f2798a5112b0..b9142ecd22ba 100644 --- a/tests/acceptance/features/apiProvisioning-v1/enableUser.feature +++ b/tests/acceptance/features/apiProvisioning-v1/enableUser.feature @@ -16,6 +16,20 @@ Feature: enable user And the HTTP status code should be "200" And user "user1" should be enabled + Scenario Outline: admin enables an user with special characters in the username + Given these users have been created with skeleton files: + | username | email | + | | | + And user "" has been disabled + When the administrator enables user "" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "" should be enabled + Examples: + | username | email | + | a@-+_.b | a.b@example.com | + | a space | a.space@example.com | + Scenario: admin enables another admin user Given user "another-admin" has been created with default attributes and skeleton files And user "another-admin" has been added to group "admin" diff --git a/tests/acceptance/features/apiProvisioning-v1/getUser.feature b/tests/acceptance/features/apiProvisioning-v1/getUser.feature index 9bce792b64d5..096b90628b6e 100644 --- a/tests/acceptance/features/apiProvisioning-v1/getUser.feature +++ b/tests/acceptance/features/apiProvisioning-v1/getUser.feature @@ -18,6 +18,21 @@ Feature: get user And the display name returned by the API should be "Brand New User" And the quota definition returned by the API should be "default" + Scenario Outline: admin gets an existing user with special characters in the username + Given these users have been created with skeleton files: + | username | displayname | email | + | | | | + When the administrator retrieves the information of user "" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the display name returned by the API should be "" + And the email address returned by the API should be "" + And the quota definition returned by the API should be "default" + Examples: + | username | displayname | email | + | a@-+_.b | A weird b | a.b@example.com | + | a space | A Space Name | a.space@example.com | + Scenario: admin tries to get a not existing user When the administrator retrieves the information of user "not-a-user" using the provisioning API Then the OCS status code should be "998" diff --git a/tests/acceptance/features/apiProvisioning-v2/addUser.feature b/tests/acceptance/features/apiProvisioning-v2/addUser.feature index 9cef2a178df8..a72abd826038 100644 --- a/tests/acceptance/features/apiProvisioning-v2/addUser.feature +++ b/tests/acceptance/features/apiProvisioning-v2/addUser.feature @@ -16,6 +16,18 @@ Feature: add user And user "brand-new-user" should exist And user "brand-new-user" should be able to access a skeleton file + Scenario Outline: admin creates a user with special characters in the username + Given user "" has been deleted + When the administrator sends a user creation request for user "" password "%alt1%" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And user "" should exist + And user "" should be able to access a skeleton file + Examples: + | username | + | a@-+_.b | + | a space | + Scenario: admin tries to create an existing user Given user "brand-new-user" has been created with default attributes and skeleton files When the administrator sends a user creation request for user "brand-new-user" password "%alt1%" using the provisioning API diff --git a/tests/acceptance/features/apiProvisioning-v2/deleteUser.feature b/tests/acceptance/features/apiProvisioning-v2/deleteUser.feature index e3fa5c5fc117..c618f99bf58b 100644 --- a/tests/acceptance/features/apiProvisioning-v2/deleteUser.feature +++ b/tests/acceptance/features/apiProvisioning-v2/deleteUser.feature @@ -15,6 +15,19 @@ Feature: delete users And the HTTP status code should be "200" And user "brand-new-user" should not exist + Scenario Outline: Delete a user with special characters in the username + Given these users have been created with skeleton files: + | username | email | + | | | + When the administrator deletes user "" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And user "" should not exist + Examples: + | username | email | + | a@-+_.b | a.b@example.com | + | a space | a.space@example.com | + Scenario: Delete a user, and specify the user name in different case Given user "brand-new-user" has been created with default attributes and skeleton files When the administrator deletes user "Brand-New-User" using the provisioning API diff --git a/tests/acceptance/features/apiProvisioning-v2/disableUser.feature b/tests/acceptance/features/apiProvisioning-v2/disableUser.feature index 234d82bba22b..b809d258fe9c 100644 --- a/tests/acceptance/features/apiProvisioning-v2/disableUser.feature +++ b/tests/acceptance/features/apiProvisioning-v2/disableUser.feature @@ -15,6 +15,19 @@ Feature: disable user And the HTTP status code should be "200" And user "user1" should be disabled + Scenario Outline: admin disables an user with special characters in the username + Given these users have been created with skeleton files: + | username | email | + | | | + When the administrator disables user "" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And user "" should be disabled + Examples: + | username | email | + | a@-+_.b | a.b@example.com | + | a space | a.space@example.com | + @smokeTest Scenario: Subadmin should be able to disable an user in their group Given these users have been created with default attributes and skeleton files: diff --git a/tests/acceptance/features/apiProvisioning-v2/editUser.feature b/tests/acceptance/features/apiProvisioning-v2/editUser.feature index c169763b1fb9..e31501bbdf71 100644 --- a/tests/acceptance/features/apiProvisioning-v2/editUser.feature +++ b/tests/acceptance/features/apiProvisioning-v2/editUser.feature @@ -15,6 +15,19 @@ Feature: edit users And the OCS status code should be "200" And the email address of user "brand-new-user" should be "brand-new-user@example.com" + Scenario Outline: the administrator can edit a user email of an user with special characters in the username + Given these users have been created with skeleton files: + | username | email | + | | | + When the administrator changes the email of user "" to "a-different-email@example.com" using the provisioning API + Then the HTTP status code should be "200" + And the OCS status code should be "200" + And the email address of user "" should be "a-different-email@example.com" + Examples: + | username | email | + | a@-+_.b | a.b@example.com | + | a space | a.space@example.com | + @smokeTest Scenario: the administrator can edit a user display (the API allows editing the "display name" by using the key word "display") Given user "brand-new-user" has been created with default attributes and skeleton files diff --git a/tests/acceptance/features/apiProvisioning-v2/enableUser.feature b/tests/acceptance/features/apiProvisioning-v2/enableUser.feature index 763ef2233cc3..fa6f07a1a01d 100644 --- a/tests/acceptance/features/apiProvisioning-v2/enableUser.feature +++ b/tests/acceptance/features/apiProvisioning-v2/enableUser.feature @@ -16,6 +16,20 @@ Feature: enable user And the HTTP status code should be "200" And user "user1" should be enabled + Scenario Outline: admin enables an user with special characters in the username + Given these users have been created with skeleton files: + | username | email | + | | | + And user "" has been disabled + When the administrator enables user "" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And user "" should be enabled + Examples: + | username | email | + | a@-+_.b | a.b@example.com | + | a space | a.space@example.com | + Scenario: admin enables another admin user Given user "another-admin" has been created with default attributes and skeleton files And user "another-admin" has been added to group "admin" diff --git a/tests/acceptance/features/apiProvisioning-v2/getUser.feature b/tests/acceptance/features/apiProvisioning-v2/getUser.feature index b661dd1c9efb..7ef50c39e951 100644 --- a/tests/acceptance/features/apiProvisioning-v2/getUser.feature +++ b/tests/acceptance/features/apiProvisioning-v2/getUser.feature @@ -18,6 +18,21 @@ Feature: get user And the display name returned by the API should be "Brand New User" And the quota definition returned by the API should be "default" + Scenario Outline: admin gets an existing user with special characters in the username + Given these users have been created with skeleton files: + | username | displayname | email | + | | | | + When the administrator retrieves the information of user "" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the display name returned by the API should be "" + And the email address returned by the API should be "" + And the quota definition returned by the API should be "default" + Examples: + | username | displayname | email | + | a@-+_.b | A weird b | a.b@example.com | + | a space | A Space Name | a.space@example.com | + Scenario: admin tries to get a not existing user When the administrator retrieves the information of user "not-a-user" using the provisioning API Then the OCS status code should be "404"