Tickets :: Comment on [#7720] _authenticate function in Horde/Auth/imap.php fails to read imap error status

* Your Email Address
* Spam protection	Enter the letters below: ._.. ..__..__.. . \| \ /[__]\| \|\ / _\|_ \/ \| \|\|__\ \/
Comment	>> I don't quite understand the logic of all this. Couldn't Horde behave > >> just like any other Imap client, such as Thunderbird? Thunderbird for > >> instance _does_ give exact error messages, rather than lie to the > >> user. > > > > Because IMP 4 does not talk directly to the IMAP server. Please read > what I have written in this ticket about > c-client/imap_error/imap_last_error(). In IMP 5 this might change > due to the switch in IMAP client, but for now, no. > > > >> If the server is not running, Thunderbird _does_ say > >> "Connection refused". If the server has a bad certificate, > >> Thunderbird pops up a dialog box asking the user whether he wants to > >> accept it anyways. For some weird reason, Thunderbird doesn't think > >> "users are too dumb to understand error messages". > > > > Thunderbird vs. IMP is a bad analogy. If thunderbird is broken, > you (as a user) must debug it. If IMP is broken, a user can't do > anything about it. Instead, an admin must fix it. And error message > shown to a user isn't going to be that helpful - rather, and admin is > going to look at a log (on either the IMAP or webmail side) to fix > the problem. > > > >> Moreover, a cursory examination shows that even Horde itself tries to > >> return correct messages for other back ends than Imap. For example, > >> Samba (lib/Horde/Auth/smb.php, lib/Horde/Auth/smbclient.php), Radius > >> (lib/Horde/Auth/radius.php), SASL (lib/Horde/Auth/pam.php, > >> lib/Horde/Auth/peclsasl.php), PAM (lib/Horde/Auth/pam.php), LDAP > >> (lib/Horde/Auth/ldap.php) all do make use of AUTH_REASON_MESSAGE to > >> communicate failure reasons such as "Failed to connect to SMB server" > >> or "Failed to create new SASL connection". > > > > Exactly. All of these auth drivers directly handle the connection to > the backend so they can provide better error messages. But how do we > do that with this function? > > http://us.php.net/imap_open > > > > Again, you CAN'T rely on imap_last_error() to provide a meaningful > description, so what are we supposed to report to the user? > > > >> And what's worse, even the admin doesn't see the failure reason; all > >> that is in the log is > >> Dec 03 02:44:22 HORDE [error] [horde] FAILED LOGIN for a > >> [83.99.45.228] to Horde [on line 116 of "/usr/share/horde3/login.php"] > >> without any reason _why_ the login failed. > >> Nobody asks you to log all spurious IMAP debug messages. But if a > >> situation is sufficiently serious that an IMAP API call fails, the > >> reason why it failed should definitely not be lost. > > > > See above. > > > > Regardless, this request has already become moot in IMP 5 where we > can directly parse the IMAP status response returned by the IMAP > server on any IMAP failure.
Attachment
Watch this ticket

Saved Queries