When a user attempts to log in with an email as their username, one of these should happen:
As it is, the email is passed on to the application as the name. For the Discourse case, this then fails, because @ is not allowed in usernames. This is good in the sense that the user does not end up with two possible accounts on the application, but bad because it's a terrible user experience.
@
I can imagine other applications that just blithely accept both username and email@example.com as separate authenticated users.
username
email@example.com
I mean, is it on fire? Smouldering, I'd say. It's bad, and a regression from the migration (because as I understand it, FAS2 had behavior #1 above).
Metadata Update from @zlopez: - Issue priority set to: Waiting on Assignee (was: Needs Review) - Issue tagged with: authentication, dev, high-trouble, medium-gain
There has been previous requests for this feature: - https://github.com/fedora-infra/noggin/issues/606 - https://pagure.io/ipsilon/issue/358
I think I found the proper solution but it needs a change in python-pam again. I've opened the issue here: https://github.com/FirefighterBlu3/python-pam/issues/26 I would love to propose a patch but I don't know C or python-ctypes, so if somebody here has experience with it I'd be happy to get some help.
Metadata Update from @abompard: - Issue untagged with: authentication, dev, high-trouble, medium-gain - Issue priority set to: Needs Review (was: Waiting on Assignee)
Metadata Update from @kevin: - Issue priority set to: Waiting on Assignee (was: Needs Review) - Issue tagged with: medium-gain, medium-trouble, ops
I think I've found a way to make it work: https://pagure.io/ipsilon/pull-request/363
So, this means email once again works? Thats a bit changed from our messaging where we didn't want it to, but ok...
Oh. I can add a feature to recognize email addresses in Ipsilon and reject them, but it's actually not so hard to accept them too (once I've found out the precise system call to make). What do we want to do?
Well, I suppose if we can make it work then we can enable it... I wonder if there's any other weird corners where it wouldn't work. I guess if noggin can handle them and ipsilon that should take care of it.
We've had the case recently of someone creating an account on pagure with an email instead of an username (by entering their email to ipsilon). Could it be related?
I don't care which of the above two approaches we take, but it shouldn't be what is apparently happening now: the client application (I'm sorry, not clear on the right terminology; the Oauth2 consumer) is getting the email address as the username, causing breakage (possibly the same thing @pingou reports). That's bad. It needs to either reject this case with a clear message or make sure that when it happens, the actual username is what is used under the hood.
That's the plan, the email address would be accepted but the username would be transmitted to the OAuth2 consumer.
Note that we can currently do shell logins on our systems using the email address, and get the right username. I'm sure nobody tried this heresy, but here it is:
$ su - aurelien@bompard.org First Factor: Second Factor: Last login: Wed Dec 15 07:54:53 GMT 2021 from 10.3.163.31 on pts/25 [abompard@batcave01 ~][PROD-IAD2]$
So where are we here? Waiting on a ipsilon release?
So, is there any way to unblock this? I know there is a new python-pam upstream now, but the fedora/epel maintainer only built it in epel9 and rawhide. If they can't/don't want to build it, we should just build in infra tags. ;)
This is finally done! Kudos to @abompard !
Please do file any new issues you run into with the new version... sorry for how long this took to resolve.
Metadata Update from @kevin: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.