email addresses with "+" get stuck in registration (or other forbidden characters)

[kolAflash]

When registering an email with a + in the address, the registration gets stuck when setting a password after verifying the email address.

This is because of the setting:
Administration settings -> Registration -> User settings -> Force email as login name

Related: server#21313 Allowed characters in username/userid

 

Steps to reproduce

1. open Nextcloud in browser
2. click Register
3. Enter an email you own with a + character. E.g. your.name+something@gmail.com (GMail forwards mails to arbitrary prefixes behind a + for existing addresses)
4. enter the verification code you got via mail
5. try to set a passwort

 

Expected behaviour

Users should be able to register, regardless which characters their email addresses contain.

 

I guess the best solution in line with the Force email as login name policy would be to somehow automatically derive a valid username.

E.g. for first.last+something@example.org the + could be replaced with a _.

Just add a strategy for possible collisions. In case a user first.last+something@example.org and a user first.last_something@example.org register. (first the + and second the _, and also the other way around)

 

Actual behaviour

Only the following characters are allowed in a username: "a-z", "A-Z", "0-9", spaces and "_.@-'"
There's no input field to set another username.
There's only the password input field and a disabled input field which shows the registered email address.

 

Server configuration

Web server: Apache (all Debian-12 default software)

Nextcloud version: 28 and 29 tested

[nickvergessen]

Same with &

[nickvergessen]

Random thought: hash the email (sha1, md5, …) as a user id.
The main idea behind the setting was to "avoid registering as 'admin'", that would still be prevented, while & and + are no problem and at the same time it's possible to "verify that the email matches the user and the user has access to the email".

If verifying the authenticity is not necessary, also a UUID could be generated

[kolAflash]

@nickvergessen Having a hash value as a user id sounds unhandy.

[nickvergessen]

The user can still login using the email with & or +, so the fact that the user id that is only user facing in federated sharing, sounds very acceptable to me 🤷
Supporting & and + on user ids will not be possible without a lot of api breaking and modification in all clients, etc.

[kolAflash]

@nickvergessen I don't suggest supporting & and + on user ids.
Please read my initial report. It states this quite clearly.

And if Force email as login name is enabled, the user can't workaround the problem without using another email address. And using another email address often isn't a possibility when you're expected to use your business email to create accounts at business partner systems.

[nickvergessen]

And if Force email as login name is enabled, the user can't workaround the problem without using another email address. And using another email address often isn't a possibility when you're expected to use your business email to create accounts at business partner systems.

I totally agree and that was exactly my point. The user should not have to care, and the only possible way at the moment is to use something else than the actual email. Using a hash (which you opposed without giving a reason) is the only way to make sure that the same user can not register multiple times with the same email address.

[kolAflash]

The reason I gave for not using a hash is: sounds unhandy
If first.last+something@example.org becomes fa075f0aca37c3d7852dd69c724eab69711bf05d529e3086d811c5c93d9dd8e8 (sha256) either the user nor anyone else will recognize the username.

 

There must already be a list of valid characters. I think best would be an deterministic, algorithmic replacement pattern for all invalid characters. While leaving all valid characters untouched.

A simple algorithm would be to replace all invalid characters with _. But that may easily cause collisions.

A better algorithm would be a proper escape pattern, possibly using a hex representation. It needs one additional invalid character, so let's choose - (could be any other character).
Two examples using this algorithm:
first.last+something@example.org => first.last_2Bsomething@example.org (2B is Unicode hex for +)
first.last_something@example.org => first.last_5Fsomething@example.org (5F is Unicode hex for _)

[nickvergessen]

If first.last+something@example.org becomes fa075f0aca37c3d7852dd69c724eab69711bf05d529e3086d811c5c93d9dd8e8 (sha256) either the user nor anyone else will recognize the username.

yes, but also no user should ever have to see this value anyway. the fa075f0aca37c3d7852dd69c724eab69711bf05d529e3086d811c5c93d9dd8e8 user can still login with their email address and the additional privacy feature to not expose the users email address as avatar URL is included for free.

But all good from my side. I gave my hint and workaround from another place and will unsubscribe now again.