Anyone else having problems with this? I’ve tried it in both Roundcube and Rainloop, and I get errors in both. Not very helpful errors. I’m on latest version 1.4.2
I remember experiencing this a couple of years ago and it was due to the roundcube config not being updated with the correct HESTIA port, where it had been changed from the default. Seems the correct port is set in rainloop plugin ini file and in roundcube plugins/password/config file
I’ve tried different passwords from simple to very complex, so that’s not it either.
Roundcube logfiles in /ver/log/nginx/domains/ don’t show anything, other than the password module is being accessed. No errors.
Rainloop log needs to be turned on, and is a bit more helpful: It looks like a 401 authorization error.
/etc/roundcube/plugins/password/config.inc.php does indeed have the correct values in it. I’ve also tried localhost and 127.0.0.1 for the host.
Side note: as its the updated version it uses $config instead of $rcmail_config at the front of all variables, but that’s consistent across the whole config, so not the cause of the problem. And I can see errors when I change the hostname to something else, so I know its picking up that config file.
Will have another look at this later. Been busy for the last week.
OK so I took another look, although I should have been doing work! I traced the cause (at least of the roundcube failure) back to the fact I have a stanza in /usr/local/hestia/nginx/conf/nginx.conf which implements auth_basic authorisation. If I remove that, then the password change works. If I replace it, it stops working again. So that’s the cause.
I realize that my warranty is at this point void. But I’m pretty sure roundcube password change was working OK before, and I’ve been doing this auth_basic Hestia Control Panel hack on a lot of servers over the years. So something changed recently which has incapacitated it, and I’d still like to be able to have password protection on myserver:8083 while being able to change passwords on the webmail.
I’ve looked at the new API settings, and have tried ALLOWing various IP addresses in there, server IP, remote IP, remove IPv6.
I’ve looked in /usr/local/hestia/web/mail/reset/index.php and disabled IP address checks but that doesn’t seem to help.
My understanding is that both the Hestia Web Interface and the Roundcube Password reset are accessing https://hestia.domain.com:8083/reset/mail/index.php
In both cases I’m authenticated with the same auth_basic user/password. But it works in one case, but not in the other.
I’ve also tried making an exclusion for that URL in /usr/local//hestia/nginx/conf/nginx.conf (auth_basic = “off” ) but that didn’t work either.
I realise that you’re under no obligation to help me now that I’ve revealed that it was one of my own modifications that got me into this, but if you have any ideas where to look next, I’d appreciate it.
If I can’t figure it out, maybe I might suggest, as a future feature, the ability to put an additional nginx auth_basic password on Hestia CP login.
I tried a lot of different things, and it seems only by embedding the ‘location /reset/mail/’ stanza inside the ‘location /’ stanza, will it actually work. Maybe this will help someone in the future. I’ll leave everyone in peace now.
PS. This also fixed my Rainloop change password problem, although I think I fixed the port/host issue manually a few days ago while debugging. So case closed as far as I’m concerned.