http_authentication: Allow logon with credentials through login forms (support logouts properly)

[DeRaja]

After upgrading it to php 7.3, Roundcube stopped working on centos 7.3. Now I wanted to use Roundcube 1.4. RC 1 under a subdirectory before patching it to the stable 1.38. The setup is:

/../public_html/.htaccess (with dir protection) /../public_html/roundcube/index.php .htaccess (default file by RC) /../public_html/roundcube/public_html/index.php

First I had problems to login. After a getting into debugging = 9, I manage to find out that the password entered in the login form of Roundcube was correct but its Roundcube php scripts used a the one from htaccess (with dir protection) for comparing it with stored MD5 one. The entered password was not used or neglected. I removed the htaccess from the main directory. Everything started to work. Now I identified a second problem: The earlier password is somewhere in the cache or system that it still remembered.

I had: $config['smtp_server'] = 'localhost'; $config['smtp_auth_type'] = 'PLAIN'; $config['smtp_port'] = 25; $config['smtp_user'] = '%t'; $config['smtp_pass'] = '';

After changing it to:

$config['smtp_server'] = 'localhost'; $config['smtp_auth_type'] = 'PLAIN'; $config['smtp_port'] = 25; $config['smtp_user'] = '%d'; $config['smtp_pass'] = '%p';

It does not work as well. Is this is a bug?

[DeRaja]

I found out that this appears to be a Waterfox problem. I could login without any problems, keeping everything the same. With Firefox, I can login and php config is the same. But Waterfox has this problem of remembering earlier passwords. This of course does not require any further attention to. I should have checked this before. I now close the thread with an excuse.

[DeRaja]

The above observation in Firefox, that I could login and could not with Waterfox, appeared to be a short happy end. Most likely, this was cached and I could login without problems. After new start and clearing caches, etc. I could replicate the nature of the above mentioned problem in Waterfox as well as in Firefox. Logs produced are in both cases same. The password entered in the login form is not used. Instead, it uses htaccess password. I used the latest theme elastic. Let me repeat my observation of today in both cases:

• I have put htaccess file under subdomain.com/public_html/.htaccess
• I have installed and configured Roundcube 1.4 RC1 under subdomain.com/public_html/roundcube

If I try to login this roundcube installation roundcube/index.php or roundcube/public_html/index.php, the password from htaccess is taken and is fed into the _POST variable for login array.

This is not allowed. If Roundcube uses htaccess for a reason, then here that is making things go wrong.

Consequently, it appears to me that it could be a bug. I would appreciate if someone could check this out and confirm independently on a different system. While this may be a bit of work to make it work under a subdirectory, it is worth it because it truly may create a nasty situation later in stable versions, if this mistake is not found and ironed out now, if it does exists.

[alecpl]

I don't understand your issue. Roundcube uses $_POST['_pass'] on logon. I don't see how it could get the password from basic auth. Until you're using some plugin. Are you?

[DeRaja]

Thanks for your prompt response. I did not manually configure any plugins. I have downloaded the complete package available. The plugin array is as follows:

$config['plugins'] = array('acl', 'additional_message_headers', 'archive', 'attachment_reminder', 'autologon', 'debug_logger', 'emoticons', 'enigma', 'example_addressbook', 'filesystem_attachments', 'help', 'hide_blockquote', 'http_authentication', 'identicon', 'identity_select', 'jqueryui', 'krb_authentication', 'managesieve', 'markasjunk', 'new_user_dialog', 'new_user_identity', 'newmail_notifier', 'password', 'show_additional_headers', 'squirrelmail_usercopy', 'subscriptions_option', 'userinfo', 'vcard_attachments', 'virtuser_file', 'virtuser_query', 'zipdownload'); Do you something in there which could trigger a variable to capture htaccess password and feed into the login process? Even if it does, then there is a bug in the script because this cannot be a normal procedure. I would be happy to delete that plugin upon your recommendation. But that bug should be eradicated.

[alecpl]

http_authentication does that magic. Disable it. Also, disable krb_authentication, autologon. Why you enable plguins you don't know how they work? We can support all possible configuration, and definitely we do not support external plugins (autologon)

[alecpl]

This might be a bug in http_authentication plugin. I'll leave this ticket open for further investigation.

[DeRaja]

Ha, I came here to tell you that it the bug is in no other plugin other than in http_authentication. Uh, you were faster to write here. I checked it with autologin plugin. Having htaccess in the parent directory did not disturb the login process. However there is no connection to the files on the disk, it the http_authentication remains in the array. The function interrupts login authentication and htaccess password credentials are entered in the session. This is - to me - a confirmed bug. You can test this out. I have Roundcube 1.38 stable. But this did not work after I installed in the newly configured Centos 7 with php 7.3. Earlier I had php 5.6, which I needed to change. Because it did not work on the new system, I need to check and test it out before going for an update in the /etc dir. So I had downloaded the complete package to also test elastic theme. Consequently, I could not login at all. I still wonder if the latest 1.4 RC1 will work with php 7.3. Have not done this as an upgrade in this manner manually. I am not too far with reading the readme and wiki. But thanks to quickly spotting out the culprit buggy plug-in. Of course it would be better to iron this bug from the function authenticate. I believe that in there things may not be correct, the initialization.

[DeRaja]

Or instead rename the plugin as http_htaccess_authentication. Then give an user to choose which one he may want and have loggin automatically through htaccess. Further, I had to observe that it will enter only one password from htaccess, obviously, which was used to authenticate. That is captured from the array of current session. So instead of removing this feature, better to enhance it and offer double possibility. However only one could remain active at one given time. Consequently, if htaccess_authentication is deactivated, it will allow http_authentication. Just my thought...

[DeRaja]

How about using in the plugin http_authentication in function authenticate: if ($_SERVER['REQUEST_METHOD'] == 'POST') or if(!empty($_POST)) With this, the function will check if that request is actually posted from the browser or not. If not, it may default to without, which eventually could result into htaccess authentication. Just an idea. I have not tested it and do not know if it may work.

[alecpl]

The idea behind http_authentication plugin is to not present the login form at all.

[DeRaja]

Well, I understand your answer. But in my case, I had it installed by default from the complete package. Thus, this problem occured. I was wondering if the authentication function in that plugin could be made better, which would be regardless of the login form. This means, if a situation like mine repeats, it will prevent. Following, one could have that plugin installed and have no fear of such a problem. But those are just thoughts. I just made a small suggestion as follows and do not know if you think it could be helpful:

function authenticate($args)

if (!empty($_SERVER['PHP_AUTH_USER'] && ($_SERVER['REQUEST_METHOD'] == 'POST'))) {
    // code
} elseif ( (!empty($_POST)) ) && ($_SERVER['REQUEST_METHOD'] == 'POST')) ) {
   // code
} else {
   // code
}