Hey all, every so often we have this discussion about the hostname in the preferences db. It is quite a hassle for us to have the imap hostname be part of the preferences. For instance, we allow some customer service people to impersonate customers, and only 1 specific imap server allows impersonation, which is only accessible through internal networks. But then we cant have these customer service people actually interact with settings..
I went into the code a bit, and maybe this is a workable solution. There seems to be only 2 times when the hostname is used to interact with the db. One in rcube_user::query(), and one in rcube_user::create().
Interestingly, create() has a plugin hook, which allows you to modify the hostname. But query() does not.
The code that calls query() is in rcmail.php.
$host = rcube_utils::idn_to_ascii($host); $username = rcube_utils::idn_to_ascii($username); // user already registered -> overwrite username if ($user = rcube_user::query($username, $host)) { $username = $user->data['username']; }
What if we add a plugin hook there (or actually in query()), so you can modify the created hostname during login? That way, this can all be done using plugins and people that want to can set a static hostname for preferences.
Cor
the authenticate hook fires during the login process (http://trac.roundcube.net/wiki/Plugin_Hooks#authenticate) and allows you to override the hostname - perhaps you could use this hook to do what you need? the CSR reps could use a special username format, then the authenticate hook could return the true username with the internal imap server that allows impersonation.
On 14-08-15 02:33 AM, Cor Bosman wrote:
Hey all, every so often we have this discussion about the hostname in the preferences db. It is quite a hassle for us to have the imap hostname be part of the preferences. For instance, we allow some customer service people to impersonate customers, and only 1 specific imap server allows impersonation, which is only accessible through internal networks. But then we cant have these customer service people actually interact with settings..
I went into the code a bit, and maybe this is a workable solution. There seems to be only 2 times when the hostname is used to interact with the db. One in rcube_user::query(), and one in rcube_user::create().
Interestingly, create() has a plugin hook, which allows you to modify the hostname. But query() does not.
The code that calls query() is in rcmail.php.
$host = rcube_utils::idn_to_ascii($host); $username = rcube_utils::idn_to_ascii($username); // user already registered -> overwrite username if ($user = rcube_user::query($username, $host)) { $username = $user->data['username']; }What if we add a plugin hook there (or actually in query()), so you can modify the created hostname during login? That way, this can all be done using plugins and people that want to can set a static hostname for preferences.
Cor
Roundcube Development discussion mailing list dev@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/dev
On 15 Aug 2014, at 18:28, Brendan brendan@tucows.com wrote:
the authenticate hook fires during the login process (http://trac.roundcube.net/wiki/Plugin_Hooks#authenticate) and allows you to override the hostname - perhaps you could use this hook to do what you need? the CSR reps could use a special username format, then the authenticate hook could return the true username with the internal imap server that allows impersonation.
No, I dont need the actual hostname to change. I just need the database column for mail_host to stay the same for different imap servers. Else you end up with multiple preferences, one row for each imap server.
It looks as if this can be accomplished by an extra hook in rcube_user::query()
Cor
-
Brendan -
Cor Bosman