Roundcubemail: 401 error (feature?) breaks website monitoring

[Pantos]

Today I updated roundcube to 1.4.0. After updating my website monitor returns the website is unauthorized/unreachable because of the 401. I'm using updown.io and phpservermonitor to monitor roundcube. I found out that the 401 isn't an error, it's a feature (#6800)?

It would be great to have the possibility to change this behaviour in an easy and safe way. Also it would be great to have this (a little bit unusual behaviour) documented somewhere.

[fabianbur]

The same happens when you have the roundcube virtual machine behind haproxy, as in my case. I solved it by passing layer 7 monitoring, where it didn't work, to layer 4.

I also manipulated the roundcube code and it worked in layer 7, but I would expect a more elegant solution. An accessible function that does it or an available plugin.

[alecpl]

Try this plugin (save as plugins/unauthcode/unauthcode.php and enable the plugin in config):

<?php
class unauthcode extends rcube_plugin
{
    function init()
    {
        $this->add_hook('unauthenticated', function($args) {
            $args['http_code'] = 200;
            return $args;
        });
    }
}

[thomascube]

@alecpl Where does that "feature" atually come from? I also think it's a rather unexpected behavior that the bare login page returns a 401 status code. I'd also tend to make this behavior optional by config and go back to regular 200 responses.

[alecpl]

It comes from #5663. So, the request was indeed for "failed login attempts" only. So, maybe we should make it return 401 only on failed logins.

[thomascube]

With regards to the many feedbacks in this and related tickets, we should indeed revert to the default 200 response for the regular login page. For failed login attempts, a 401 response may make sense.

[alecpl]

Fixed.

[fabianbur]

Thank you
How sensible your words!

With regards to the many feedbacks in this and related tickets, we should indeed revert to the default 200 response for the regular login page. For failed login attempts, a 401 response may make sense.

[fabianbur]

I applied commit 29e7c16 and it worked excellent.

Roundcube 1.4 can now be used in Haproxy, no problem.

I had updated to version 4.1 rc1 since its launch. The truth is that I never thought it would take almost a year to get the stable version, I thought it would be a maximum of one month. But I could contribute by reporting some incidents and others that also affected me, this was the one that took the longest to attend, but in the end it was done in an impeccable way.
Thanks Aleksander Machniak and Thomas Brüderli. We owe you this excellent software.
Sorry for English, my language is Spanish.

[mas90]

Per https://tools.ietf.org/html/rfc7235#section-3.1 HTTP 401 has a very specific meaning which does not apply to Roundcube's authentication flow. HTTP 401 means that the browser should use HTTP authentication in order to proceed, which most configurations of Roundcube won't use.

RFC 7235: "The server generating a 401 response MUST send a WWW-Authenticate header field (Section 4.1) containing at least one challenge applicable to the target resource."

Because it doesn't do this, Roundcube is not conforming to the HTTP spec.

Perhaps HTTP 403 would be a more appropriate response for authentication failures.