Skip to content
New issue

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

Sign up for GitHub

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

Already on GitHub? Sign in to your account

Allow "+" character in usernames #36613

Merged
merged 4 commits into from
Dec 20, 2019
Merged

Allow "+" character in usernames #36613

Show file tree
Hide file tree
Changes from 3 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
d89bd18
allow plus character when creating users
Dec 18, 2019
c8ba37a
Improve coverage of Manager createUser exceptions
phil-davis Dec 19, 2019
8be87ce
Add provisioning API tests for usernames with special characters
phil-davis Dec 19, 2019
80807c2
update uid argument description of user:add command
karakayasemi Dec 20, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions changelog/unreleased/36613
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,5 @@
Enhancement: Allow plus sign in username

The plus sign is now allowed in a username, e.g. John+Smith

https://github.com/owncloud/core/pull/36613
6 changes: 3 additions & 3 deletions lib/private/User/Manager.php
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -332,10 +332,10 @@ public function createUser($uid, $password) {
$l = \OC::$server->getL10N('lib');

// Check the name for bad characters
// Allowed are: "a-z", "A-Z", "0-9" and "_.@-'"
if (\preg_match('/[^a-zA-Z0-9 _\.@\-\']/', $uid)) {
// Allowed are: "a-z", "A-Z", "0-9" and "+_.@-'"
if (\preg_match('/[^a-zA-Z0-9 \+_\.@\-\']/', $uid)) {
karakayasemi marked this conversation as resolved.
Show resolved Hide resolved
throw new \Exception($l->t('Only the following characters are allowed in a username:'
. ' "a-z", "A-Z", "0-9", and "_.@-\'"'));
. ' "a-z", "A-Z", "0-9", and "+_.@-\'"'));
}
// No empty username
if (\trim($uid) == '') {
Expand Down
12 changes: 12 additions & 0 deletions tests/acceptance/features/apiProvisioning-v1/addUser.feature
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 "<username>" has been deleted
When the administrator sends a user creation request for user "<username>" password "%alt1%" using the provisioning API
Then the OCS status code should be "100"
And the HTTP status code should be "200"
And user "<username>" should exist
And user "<username>" 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
Expand Down
13 changes: 13 additions & 0 deletions tests/acceptance/features/apiProvisioning-v1/deleteUser.feature
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 |
| <username> | <email> |
When the administrator deletes user "<username>" using the provisioning API
Then the OCS status code should be "100"
And the HTTP status code should be "200"
And user "<username>" should not exist
Examples:
| username | email |
| a@-+_.b | [email protected] |
| a space | [email protected] |

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
Expand Down
13 changes: 13 additions & 0 deletions tests/acceptance/features/apiProvisioning-v1/disableUser.feature
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 |
| <username> | <email> |
When the administrator disables user "<username>" using the provisioning API
Then the OCS status code should be "100"
And the HTTP status code should be "200"
And user "<username>" should be disabled
Examples:
| username | email |
| a@-+_.b | [email protected] |
| a space | [email protected] |

@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:
Expand Down
13 changes: 13 additions & 0 deletions tests/acceptance/features/apiProvisioning-v1/editUser.feature
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 "[email protected]"

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 |
| <username> | <email> |
When the administrator changes the email of user "<username>" to "[email protected]" 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 "<username>" should be "[email protected]"
Examples:
| username | email |
| a@-+_.b | [email protected] |
| a space | [email protected] |

@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
Expand Down
14 changes: 14 additions & 0 deletions tests/acceptance/features/apiProvisioning-v1/enableUser.feature
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 |
| <username> | <email> |
And user "<username>" has been disabled
When the administrator enables user "<username>" using the provisioning API
Then the OCS status code should be "100"
And the HTTP status code should be "200"
And user "<username>" should be enabled
Examples:
| username | email |
| a@-+_.b | [email protected] |
| a space | [email protected] |

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"
Expand Down
15 changes: 15 additions & 0 deletions tests/acceptance/features/apiProvisioning-v1/getUser.feature
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 |
| <username> | <displayname> | <email> |
When the administrator retrieves the information of user "<username>" 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 "<displayname>"
And the email address returned by the API should be "<email>"
And the quota definition returned by the API should be "default"
Examples:
| username | displayname | email |
| a@-+_.b | A weird b | [email protected] |
| a space | A Space Name | [email protected] |

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"
Expand Down
12 changes: 12 additions & 0 deletions tests/acceptance/features/apiProvisioning-v2/addUser.feature
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 "<username>" has been deleted
When the administrator sends a user creation request for user "<username>" password "%alt1%" using the provisioning API
Then the OCS status code should be "200"
And the HTTP status code should be "200"
And user "<username>" should exist
And user "<username>" 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
Expand Down
13 changes: 13 additions & 0 deletions tests/acceptance/features/apiProvisioning-v2/deleteUser.feature
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 |
| <username> | <email> |
When the administrator deletes user "<username>" using the provisioning API
Then the OCS status code should be "200"
And the HTTP status code should be "200"
And user "<username>" should not exist
Examples:
| username | email |
| a@-+_.b | [email protected] |
| a space | [email protected] |

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
Expand Down
13 changes: 13 additions & 0 deletions tests/acceptance/features/apiProvisioning-v2/disableUser.feature
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 |
| <username> | <email> |
When the administrator disables user "<username>" using the provisioning API
Then the OCS status code should be "200"
And the HTTP status code should be "200"
And user "<username>" should be disabled
Examples:
| username | email |
| a@-+_.b | [email protected] |
| a space | [email protected] |

@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:
Expand Down
13 changes: 13 additions & 0 deletions tests/acceptance/features/apiProvisioning-v2/editUser.feature
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 "[email protected]"

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 |
| <username> | <email> |
When the administrator changes the email of user "<username>" to "[email protected]" 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 "<username>" should be "[email protected]"
Examples:
| username | email |
| a@-+_.b | [email protected] |
| a space | [email protected] |

@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
Expand Down
14 changes: 14 additions & 0 deletions tests/acceptance/features/apiProvisioning-v2/enableUser.feature
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 |
| <username> | <email> |
And user "<username>" has been disabled
When the administrator enables user "<username>" using the provisioning API
Then the OCS status code should be "200"
And the HTTP status code should be "200"
And user "<username>" should be enabled
Examples:
| username | email |
| a@-+_.b | [email protected] |
| a space | [email protected] |

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"
Expand Down
15 changes: 15 additions & 0 deletions tests/acceptance/features/apiProvisioning-v2/getUser.feature
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 |
| <username> | <displayname> | <email> |
When the administrator retrieves the information of user "<username>" 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 "<displayname>"
And the email address returned by the API should be "<email>"
And the quota definition returned by the API should be "default"
Examples:
| username | displayname | email |
| a@-+_.b | A weird b | [email protected] |
| a space | A Space Name | [email protected] |

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"
Expand Down
14 changes: 9 additions & 5 deletions tests/acceptance/features/cliProvisioning/addUser.feature
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,14 +6,18 @@ Feature: add a user using the using the occ command
So that I can give people controlled individual access to resources on the ownCloud server and
So that I can write scripts to add users

Scenario: admin creates an ordinary user using the occ command
Scenario Outline: admin creates an ordinary user using the occ command
When the administrator creates this user using the occ command:
| username |
| <username> |
Then the command should have been successful
And the command output should contain the text 'The user "<username>" was created successfully'
And user "<username>" should exist
And user "<username>" should be able to access a skeleton file
Examples:
| username |
| justauser |
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
And user "justauser" should be able to access a skeleton file
| a@-+_.b |

Scenario: admin creates an ordinary user specifying attributes using the occ command
When the administrator creates this user using the occ command:
Expand Down
20 changes: 10 additions & 10 deletions tests/acceptance/features/webUIAddUsers/addUsers.feature
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -15,19 +15,19 @@ Feature: add users
Then the user should be redirected to a webUI page with the title "Files - %productname%"

Scenario: use the webUI to create a user with special valid characters
When the administrator creates a user with the name "@-_.'" and the password "%regular%" using the webUI
When the administrator creates a user with the name "@-+_.'" and the password "%regular%" using the webUI
And the administrator logs out of the webUI
And user "@-_.'" logs in using the webUI
And user "@-+_.'" logs in using the webUI
Then the user should be redirected to a webUI page with the title "Files - %productname%"

Scenario: use the webUI to create a user with special invalid characters
When the administrator attempts to create these users then the notifications should be as listed
| user | password | notification |
| a#% | "%regular%" | Error creating user: Only the following characters are allowed in a username: "a-z", "A-Z", "0-9", and "_.@-'" |
| a+^ | "%alt1%" | Error creating user: Only the following characters are allowed in a username: "a-z", "A-Z", "0-9", and "_.@-'" |
| a)~ | "%alt2%" | Error creating user: Only the following characters are allowed in a username: "a-z", "A-Z", "0-9", and "_.@-'" |
| a(= | "%alt3%" | Error creating user: Only the following characters are allowed in a username: "a-z", "A-Z", "0-9", and "_.@-'" |
| a`*^ | "%alt4%" | Error creating user: Only the following characters are allowed in a username: "a-z", "A-Z", "0-9", and "_.@-'" |
| user | password | notification |
| a#% | "%regular%" | Error creating user: Only the following characters are allowed in a username: "a-z", "A-Z", "0-9", and "+_.@-'" |
| a+^ | "%alt1%" | Error creating user: Only the following characters are allowed in a username: "a-z", "A-Z", "0-9", and "+_.@-'" |
| a)~ | "%alt2%" | Error creating user: Only the following characters are allowed in a username: "a-z", "A-Z", "0-9", and "+_.@-'" |
| a(= | "%alt3%" | Error creating user: Only the following characters are allowed in a username: "a-z", "A-Z", "0-9", and "+_.@-'" |
| a`*^ | "%alt4%" | Error creating user: Only the following characters are allowed in a username: "a-z", "A-Z", "0-9", and "+_.@-'" |

Scenario: use the webUI to create a user with empty password
When the administrator attempts to create a user with the name "bijay" and the password "" using the webUI
Expand Down Expand Up @@ -71,7 +71,7 @@ Feature: add users
Examples:
| username | comment |
| guiusr1 | simple user-name |
| a@-_.'b | complicated user-name |
| a@-+_.'b | complicated user-name |

Scenario Outline: user sets his own password but retypes it wrongly after being created with an Email address only
When the administrator creates a user with the name "<username>" and the email "guiusr1@owncloud" without a password using the webUI
Expand All @@ -85,7 +85,7 @@ Feature: add users
Examples:
| username | comment |
| guiusr1 | simple user-name |
| a@-_.'b | complicated user-name |
| a@-+_.'b | complicated user-name |

Scenario Outline: webUI refuses to create users with invalid Email addresses
When the administrator creates a user with the name "guiusr1" and the email "<email>" without a password using the webUI
Expand Down
Loading