[#29471] - [4.0][RFC] Email as username on registration/login
- New
- Medium
- Build: master
- # 29471
Problem identified
There is a issue opened about this ( #29403), but i would like here to propose a solution. I know some of you think this is not important but i've seen that there are problems with the existing plugins (some are old, some just don't do this job).
I'm no experienced coder, i'm a github newbie so i don't know how to pull requests but i use Joomla since 2009 and love this project.
My suggestion is just an alternative, not a radical change. So the site owner can choose to use email as username or not.
This fix is for registration, module login and component login.
I'll paste images and code if someone want to try the fix. I've tested on J4beta and works
Proposed solution
Change these files:
<field
name="emailAsUsername"
type="radio"
label="COM_USERS_CONFIG_FIELD_EMAILASUSERNAME_LABEL"
layout="joomla.form.field.radio.switcher"
default="0"
showon="allowUserRegistration:1">
<option value="0">JNO</option>
<option value="1">JYES</option>
</field>
COM_USERS_CONFIG_FIELD_EMAILASUSERNAME_LABEL="Use Email As Username"
if (ComponentHelper::getParams('com_users')->get('emailAsUsername') == 1)
{
$this->setMessage(Text::_('COM_USERS_REGISTRATION_SAVE_SUCCESS_MAIL_ONLY'));
} else {
$this->setMessage(Text::_('COM_USERS_REGISTRATION_SAVE_SUCCESS'));
}
First:
if (ComponentHelper::getParams('com_users')->get('emailAsUsername') == 1)
{
$form->removeField('username');
}Second:
if (ComponentHelper::getParams('com_users')->get('emailAsUsername') == 1)
{
$data['username'] = $data['email'];
}
<?php if (ComponentHelper::getParams('com_users')->get('emailAsUsername') == 0) : ?>
<a class="com-users-login__remind list-group-item" href="<?php echo Route::_('index.php?option=com_users&view=remind'); ?>">
<?php echo Text::_('COM_USERS_LOGIN_REMIND'); ?>
</a>
<?php endif; ?>
COM_USERS_REGISTRATION_SAVE_SUCCESS_MAIL_ONLY="Thank you for registering. You may now log in using the email and password you registered with."in libraries/src/Table/User.php
if (ComponentHelper::getParams('com_users')->get('emailAsUsername') == 0)
{
if ($filterInput->clean($this->username, 'TRIM') == '')
{
$this->setError(Text::_('JLIB_DATABASE_ERROR_PLEASE_ENTER_A_USER_NAME'));
return false;
}
if (preg_match('#[<>"\'%;()&\\\\]|\\.\\./#', $this->username) || StringHelper::strlen($this->username) < 2
|| $filterInput->clean($this->username, 'TRIM') !== $this->username || StringHelper::strlen($this->username) > 150)
{
$this->setError(Text::sprintf('JLIB_DATABASE_ERROR_VALID_AZ09', 2));
return false;
}
} else {
$this->username = $this->email;
}Last fix:
TODO: in module and component form check the email and not the username
Open questions
One open question: can this request be part of the joomla core? Why use outdated plugins (hoping that the developer will never retire) to add a functionality that can be part of the core?
joomla-cms-bot
- | Labels |
Added:
?
?
|
||
Quy
- 
thank you @richard67 for your kind answer. I'm learning how to use git and github, now i've forked the project and created a branch with the file modification. What i can't do is how to "attach" multiple files modifications to the pull request.. by now if i modifiy another file i get a whole new branch... is this intended or am i missing something?
Anyway before wasting your time teaching me (it will take time but i will learn it :D ) I would like to know if this change can be taken into account or is to be rejected by default due to decisions already made on the structure of the cms... like "we think that username must always be explicit for this good reason".
If there is a valid reason I'd like to know, so I'd stop asking for changes.
Otherwise I think it's a change at least to be considered since Joomla asks for many default fields during registration (name, username, mail [twice], and password [twice]) when in most cases mail and password would be enough.
Thank you!
What happens with non-unique email addresses
hi @brianteeman , what do you mean?
If an email address is already in the database a new user can't use that email to register, the check is still present.
Only if they are using the core registration component. The email address field is not a unique field and so it is perfectly possible for an email address to be used multiple times. Not a good idea but possible.
Well this scenario can create problems more system-wide than this specific modification... for example the "forgot username" and "forgot password" will stop working as well i guess.
If someone uses another registration component this suggested modification is irrelevant, besides the fact that it is optional therefore one can decide not to activate it from the control panel
Yes it could create problems with those two features but they can be disabled
Also this feature can be disabled, or better is delivered disabled and can be enabled only if necessary
Actually my code is wrong when an admin enable this option after he already collected some usernames... i was simply changing the labels but for this system to work propery you really need to check email instead of usernames, even if they are identical.
This solves also the rare situation when a user register with a mail as username and a different email as email.
Unfortunately this a "to do", i really don't know how to modify component and module login to check mail instead of username... need to study a bit more :)
The email address field is not a unique field and so it is perfectly possible for an email address to be used multiple times.
That's not correct. Email is unique.
Maybe when added by core code. But in database there is no unique constraint, it's just a normal (non unique) index. For the username we (meanwhile) have a unique index.
I have once created a solution for a customer of mine who wanted this 'feature'. The username and email where synced on the front-end via a small JavaScript function, no other changes required because in that case username = email. Also no duplicate emails possible because when synced they well not register (= username = unique).
quick-and-dirty but it served the use case very well (for this customer), not something to put into core but posting here as possible out-of-the-box idea
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/29471.
Thank you @Ruud68 for your tip, i was aiming to create a global setting that can be used sitewide and be read by other components who want to use joomla registration component.
However I have investigated the problem and I have seen that it has been discussed for a long time also here on github (like #15725 or others), i guess it really no need to be part of the core... but the suggestions to use plugins are getting weak as the plugins are very few and most of them are now unsupported or outdated ( https://extensions.joomla.org/tags/email-authentication/ )
All popular social networks and services offer at least 2 options (and some even 3) for authorization on the site
You can login @github using username or email
You can login @twitter using username or email or phone
You can login @linkedin using email or phone
You can login @google using email or phone
You can login @facebook using email or phone
You can login @amzn using email or phone
These services are used by billions of people on our planet, and each service has an option when you can enter your e-mail address in the login field.
So yes, I believe that an e-mail address is like a standard that we cannot ignore. People use email and it's easy. I believe that this is worthy of being in the CMS (naturally optional, with the ability to enable/disable and a script to check for previously created sites for a unique login/email)
The email address field is not a unique field and so it is perfectly possible for an email address to be used multiple times.
Up until very recently username column wasn't unique either.
The email address field is not a unique field and so it is perfectly possible for an email address to be used multiple times.
Up until very recently username column wasn't unique either.
When did the username column became unique? The update created problems in installations with non-unique usernames?
The email address field is not a unique field and so it is perfectly possible for an email address to be used multiple times.
Up until very recently username column wasn't unique either.
I think that such an instruction can be issued if the option is added to the CMS that the login will be possible by e-mail. Anyway, when this columns are unique - that's good.
I think this time webmasters will have much less problems than the username unique.
well if we did take the step to make usernames unique i guess email should follow... i can't find a reasonable reason for two accounts to share the email address.
If we decide to go this way than login/register with email only should be easier and totally backward compatible
I'd like to have the E-mail as user name.
The E-mail in Joomla is unique. Not the field in the database, but it is verified. Try to add a user with an existing E-mail address and you will get
Error
Save failed with the following error: The email address you entered is already in use. Please enter another email address.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/29471.
@chmst It was the same with the user name, it always had been verified in PHP that it's unique. But in some case MySQL produced duplicate usernames, that's why a while ago the unique key has been added. So theoretically we can't rely on the email address being unique on all installations with their update history, even if practically we can (because spam bots may fill in more likely long usernames which might be truncated by MySQL than doing that with email addresses).
Maybe we could implement a post install message shown up after an update when an email address is not unique and a button to fix that and adding the unique key (like we should have done with the user name instead of blindly adding the unique key)?
I guess that having duplicate usernames (impossible now: good) and duplicate emails (possible now: bad) is conceptually wrong. Apart from email login/registration i guess we should fix this as we did with usernames.
Knowing what happened when we added the unique key to usernames we can do like @richard67 suggests and fix it post-installation or, maybe better in my opinion, block the update if there are duplicate keys... something like "you can't update to J4 because there are X identical emails in your database: [list]. Fix this before upgrade"
@wilsonge Would this be an option for 4.0? Or has it to go into 4.1?
@PixedBo What would you like us to do (beside reviewing your suggestions)? Would you prefer to be advised how you can make a pull request (PR), or would you prefer someone else making a PR?