Opened 15 years ago

Closed 14 years ago

Last modified 15 years ago

#335 closed defect (fixed)

don't attempt to auth on empty username

Reported by: dmorton Owned by: dmorton
Priority: normal Milestone: 1.0.2
Component: PHP scripts Version: 1.0.1
Severity: normal Keywords:
Cc:

Description

After a lengthy debugging session on IRC, Adam Kosmin uncovered the following error with dbmail. When he logged in with just a username, (rewriting type 0, imap) it let him in; On all other systems it doesn't.

The result of get_user_from_email() is an empty string if there is no '@' in the input. So Maia happily tries to authenticate an empty user. The resulting IMAP session looked sort of like: (.'s are spaces)

OK.dbmail.imap.(protocol.version.4r1).server.2.1.ready.to.run..
0001.LOGIN.""."your password"..
*.BYE.internal.db.error.validating.user..
A0001.OK.completed..

In this case, dbmail gave an invalid line, followed by 'OK' which NET_IMAP takes as success.

While this isn't really Maia's fault, maybe we shouldn't even try to auth an empty username. So the question is, do we return an error, or do we ammend get_user_from_email to return the supplied $email if $email is just a username? Do we add a check in auth() for an empty username?

Change History (3)

comment:1 Changed 15 years ago by rjl

It seems to me the answer lies in how $address_rewriting_type}} is set. If the rewriting type indicates that a full e-mail address is expected, and {{{$email isn't a valid e-mail address, that should raise an error. On the other hand, if the rewriting type indicates that a bare username is expected, then the presence of a '@' in the username is an error. In short, use the rewriting type to help decide what's valid and what isn't in terms of the user input.

As for the empty username problem, clearly we should not be trying to send an empty string to any authenticator (and an assertion to that effect in auth() wouldn't hurt). The get_user_from_email() function should only be called when the supplied argument is a valid e-mail address, for one thing, and it should raise an error if the argument is anything else.

But more to the point, if the prompt on the login page asks for Email address: and the user supplies just a username, accepting that username is counter to the user's expectation. The rewriting type should determine whether a full e-mail address is required, or whether a bare username is expected, and the login page prompt should make that expectation clear (by prompting either for Email address: or Username:). Whatever we prompt for, we should restrict our acceptance criteria to that type of input, and consider any other type of input invalid.

comment:2 Changed 15 years ago by dmorton

One fundamental flaw is that one variable cannot determine both whether the login should use a username or an email and what the MTA rewriting stance is.

The proper fix is in the stats branch wrt per-domain authentication. It allows for more flexible mapping of logins to maia accounts to addresses.

comment:3 Changed 14 years ago by dmorton

  • Resolution set to fixed
  • Status changed from new to closed

in [1125] added basic check to fail if username is empty. It fixes the

bug, and we will redo it properly with per-domain auth later.

Note: See TracTickets for help on using tickets.