impossible to login

[patpro]

Hi,
I'm trying to use Roundcube on FreeBSD (from ports), PHP 5.2.x with Suhosin-Patch 0.9.6.2, and courier-imap. I can't log in Roundcube. Squirrel Mail or dedicated email clients (Mail, Thunderbird, ...) work flawlessly.

It appears Roundcube adds quote around the login string. I've disabled magic_quotes_gpc in php.ini, but it does not change anything, as you can see from the authdaemond logfile:

Code Select Expand

imapd: Connection, ip=[127.0.0.1]
authdaemond: received auth request, service=imap, authtype=cram-md5
authdaemond: authuserdb: trying this module
authdaemond: cram: challenge=*********, response=*********
authdaemond: cram: decoded challenge/response, username '"my_login"'
authdaemond: userdb: opened /usr/local/etc/userdb.dat
authdaemond: userdb: entry not found
authdaemond: authuserdb: REJECT - try next module
authdaemond: FAIL, all modules rejected
The interesting part is username '"my_login"'. You can see the login my_login is quoted (double quotes)!
If I login into Squirrel Mail (or other), I read: username 'my_login': no double quotes, and it works.

Any idea?

[patpro]

nobody ? Am I the only one running PHP5+Suhosin-Patch on FreeBSD, and having problems with Roundcube ?

[bpat1434]

I'll take a shot.

In /program/include/rcube_imap.inc look around line 94 you should see:
 /**
   * Connect to an IMAP server
   *
   * @param  string   Host to connect
   * @param  string   Username for IMAP account
   * @param  string   Password for IMAP account
   * @param  number   Port to connect to
   * @param  string   SSL schema (either ssl or tls) or null if plain connection
   * @return boolean  TRUE on success, FALSE on failure
   * @access public
   */
  function connect($host, $user, $pass, $port=143, $use_ssl=null)
    {
    global $ICL_SSL, $ICL_PORT, $IMAP_USE_INTERNAL_DATE;
    
    // check for Open-SSL support in PHP build
    if ($use_ssl && in_array('openssl', get_loaded_extensions()))
      $ICL_SSL = $use_ssl == 'imaps' ? 'ssl' : $use_ssl;
    else if ($use_ssl)
      {
      raise_error(array('code' => 403, 'type' => 'imap', 'file' => __FILE__,
                        'message' => 'Open SSL not available;'), TRUE, FALSE);
      $port = 143;
      }

    $ICL_PORT = $port;
    $IMAP_USE_INTERNAL_DATE = false;
    
    $this->conn = iil_Connect($host, $user, $pass, array('imap' => 'check'));
    $this->host = $host;
    $this->user = $user;
    $this->pass = $pass;
    $this->port = $port;
    $this->ssl = $use_ssl;
Now, between these two lines:
    $IMAP_USE_INTERNAL_DATE = false;
    
    $this->conn = iil_Connect($host, $user, $pass, array('imap' => 'check'));
Add the following:
    // Look for a quoted username:

if(substr($user, 0, 1) == '"')

  {

  $message = 'Username quoted, fixing ... From ['.$user.'] to [';

  $user = substr($user, 1);

  // If we have an ending quote...

  if(substr($user, -1) == '"')

    $user = substr($user, 0, -1);

  $message = $user.']';

  raise_error(array('code' => '999',

               'type' => 'imap',

               'message' => $message, TRUE, FALSE);

  }

If a username is quoted, it should put an error in the log which shows the first and translasted username.  Try that out, and see if it helps.  If it does, let me know so I can submit a patch to fix this.

[patpro]

Thanks for your help. Unfortunately it won't work.
By the way, a ")" is missing after "$message" here : ...$message, TRUE, FALSE...

It looks like the $user is not quoted at this stage. I've put authdaemond in debug mode again, to see what's going on. As far as I understand, roundcube tries 2 different login methods. The first one uses CRAM-MD5. When the IMAP server and Roundcube try to resolve the challenge, they find a quoted username:

Code Select Expand


imapd: Connection, ip=[127.0.0.1]
authdaemond: received auth request, service=imap, authtype=cram-md5
authdaemond: authuserdb: trying this module
authdaemond: cram: challenge=**********, response=***********
authdaemond: cram: decoded challenge/response, username [B]'"MY_LOGIN"'[/B]
authdaemond: userdb: opened /usr/local/etc/userdb.dat
authdaemond: userdb: entry not found
authdaemond: authuserdb: REJECT - try next module
authdaemond: FAIL, all modules rejected


Just after that, Roundcube falls back in "login" authtype, and you can see the username is good (no double quotes):

Code Select Expand


authdaemond: received auth request, service=imap, authtype=login
authdaemond: authuserdb: trying this module
authdaemond: userdb: opened /usr/local/etc/userdb.dat
authdaemond: userdb: looking up [B]'MY_LOGIN'[/B]
authdaemond: userdb: home=/home/MY_LOGIN, uid=1001, gid=0, shell=/usr/local/bin/bash, mail=, quota=, gecos=MY NAME, options=
authdaemond: found systempw in userdbshadow
authdaemond: authuserdb: sysusername=, sysuserid=1001, homedir=/home/MY_LOGIN, address=MY_LOGIN, fullname=MY NAME, maildir=, quota=, options=
authdaemond: authuserdb: clearpasswd=, passwd=*
authdaemond: supplied password 'MY_PASSWORD' does not match encrypted password '*'
authdaemond: authuserdb: REJECT - try next module
authdaemond: FAIL, all modules rejected


no quotes -> login found, but unfortunately the userdb does not include a real system password (systempw). The userdb is configured so that only CRAM-MD5 challenge authentication is possible.

As I said earlier, Squirrel Mail and other IMAP clients use CRAM-MD5 with success, because the login is provided to the server without double quotes.
I think the problem may be in the CRAM-MD5 code of RoundCube, but I don't know where to look...

[bgp]

Try roundcubemail-0.1-rc2 (2007-10-20 16:02)

program/lib/imap.inc
........
function iil_C_Authenticate(&$conn, $user, $pass, $encChallenge) {
.......
//in new version:
$reply = base64_encode('"' . $user . '" "' . $hash . '"');
......
//in old version of roundcube:
$reply = base64_encode($user." ".$hash);

replace this line and try to log in.

http://trac.roundcube.net/ticket/1484819

[patpro]

//in old version of roundcube:
$reply = base64_encode($user." ".$hash);

that's it !
thank you very much.

[jimmyb]

That also worked for me, yay!

[sirocco]

For info this problem exists since 0.1-stable

http://trac.roundcube.net/ticket/1484819

[bcnme70]

Worked for me too! MacMini, 10.5.4 server