I am not in favour of this change for security reasons. If a site owner wants to do this there are several extensions available. We should be increasing security not reducing it.

Is there an issue we try to solve here which can't already be done using 3rd party extensions?
If it can be solved with an extension already, I don't see the need for us to include it into core. Looks like quite a situational usecase to me.

There are individual uses cases to solve and there are common web standards/behaviour to be included. In my opinion this patch is more for the latter. Again, I think Joomla should behave the same as other applications out of the box, after the installation, and not with additional extensions.

The correct way to do this is with a NEW authentication plugin specifically to allow login by email. That is why we have authentication plugins.

(Then we end up with exactly what the available extensions can already do - so there is no point ijn adding this to the core)

Again: I made this PR because I think that common standards should be in the core and available out of the box, as SEO, Microdata, RSS, Tags....too. The security impact is not that bad and as it is off by default at least the site-admins decision. Every different authentication method should be implemented as own plugin, true. But this is just an addition to a existing one - and not a new or different one.

If this PR not get merged is not a big thing to me. But I think it's a chance to get more even with other web-applications. Just my 2 cents.

I have tested this item ✅ successfully on f6612ba

I have tested this and it works as described - still not personally convinced its an improvement though

I have tested this item ✅ successfully on f6612ba

RTC after two successful tests.

This is a new feature so I have added the new feature option

@franz-wohlkoenig please remove the RTC - just because a new feature is tested as working doesnt mean it is a good thing and can be merged - as you can see both @Bakual and myself expressed our doubts about the usefullness of this

@brianteeman RTC removed. My Thought was that Maintainers can decide independent from Status & 2 sucessfully Tests didn't get lost.

I have tested this item ✅ successfully on f6612ba

Works perfect.

This is a very functional and great feature for the users, since it's very common to login with email address.

we have not merged better solution to solve the problem, see #10347

Some thought:
I disagree with the statement that this would degrade security. The password and 2FA do the job OK imho.
I disagree also with the statement that because some 3rd party extensions exist, we should not include this in core. Remember my plugins Unicode slugs and Registration approval for 1.5, and many others.
I also disagree with the solution that was proposed in #10347 as it was not BC.

I will reset this as RTC as it was tested and works fine.
The final decision is indeed the choice of the release leader and PLT as rightfully posted by @franz-wohlkoenig

By adding an additional WHERE clause, and because the username and email columns are only unique within themselves, it is possible now for this query to return a non-unique result set (as in 2 records versus one if somehow user A has a username of me@example.com and user B has an email address of me@example.com). This scenario needs to be addressed.

Please also check com_joomlaupdate login form iirc thy check on username only too.

The subject doesn't sound right (it was strange to read of a feature like that).
I guess the starter meant: Let users use their username OR email as credential to log in

I like this PR and think it would be useful. I think it is a UX thing. Users expect certain behaviour and if they cannot remember their username they will likely try their email address. I would argue that the email address is unique and thus could replace the username option. In that situation it would solve the problem this PR solves and I think it overcomes the security issue @brianteeman mentioned. It would break b/c though by doing it that way though. In any case I think users would try to use their email address in some cases.

A system should only have one identifier for a user. Either a username or a password. A username can be any unique value identifying that user, be it an email address, a customized username, or a system generated identifier; we don't impose a restriction that says the username has to be a value that is not used in one of the other columns in the users table.

A site can use language overrides to change the labels if they want to steer users toward using their email address as their usernames. There are also plugins which can accomplish the same.

The long and short is I still don't see something that requires us to make a core change to allow an email address to be a username as you can already do it, it is just stored as a separate field in the database. If we were to add such an option, it would introduce site management issues as we would have to force that the username AND email columns be unique (a username and email can only be the same if it is the same record, a username cannot be duplicated as an email address in another record (and vice-versa) as that would mean the system would potentially try to log into 2 different accounts). This patch does not address the data integrity issue, as I pointed it out nearly 2 months ago.

the "problem" is solved else where, closing