Note to readers: RoundCube 0.7.1 uses the Iloha IMAP Library. RoundCube 0.7.2 does not, so this particular problem may already be fixed.
In the past I’ve had to enable PLAIN IMAP authentication because older versions of M$ Outlook didn’t support CRAM-MD5 authentication. This means that my IMAP server advertises CRAM-MD5 as well as PLAIN as possible authentication methods.
All my clients who wanted to login using PLAIN cannot login using CRAM-MD5 because their passwords have to be stored in a different format.
A problem occurs when you set RoundCube’s “imap_auth_type” to “check”, because it picks CRAM-MD5 over PLAIN every time. I don’t want this to happen because some of my clients cannot login using CRAM-MD5. Ideally RoundCube should be following RFC3501:
If an AUTHENTICATE command fails with a NO response, the client MAY try another authentication mechanism by issuing another AUTHENTICATE command. It MAY also attempt to authenticate by using the LOGIN command
…but RoundCube doesn’t. To temporarily fix the problem you should be able to set “imap_auth_type” to “plain” so that RoundCube always uses PLAIN to authenticate against the IMAP server. However, I found that this does not work in 0.7.1 because of the following problem:
RoundCube passes options to the iil_Connect function of the Iloha IMAP Library. The options object includes a property “auth_method”, meant to control the authentication method, but this is never used, because the iil_Connect method expects this property to be named “imap”.
Line 382 of /program/include/rcmail.php is where the options object is defined – I simply changed ‘auth_method’ to ‘imap’.
I’m writing this down because it too me an age to figure out a way of doing this. I have a website which Tomcat is happily serving. Areas of the site require a secure connection so I’m using Spring security to require particular URLs to be accessed over HTTPS. It means that when I access http://example.org:8080/webapp/login, it’ll bump me to https://example.org:8443/webapp/login. Note: Tomcat is setup with the SSL connector and a self signed .keystore see (http://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.html).
I have two vhosts setup in Apache, one for the http://example.org and one for https://example.org. They are both using mod_proxy to ProxyPass and ProxyPassReverse requests to the appropriate Tomcat URL’s. The problem comes when switching to HTTPS from HTTP and vice versa. Ideally I wanted some sort of ProxyPassReverse declaration in my config for http://example.org what would change HTTP headers (that Spring sets) for https://example.org:8443/webapp into https://example.org. Except ProxyPassReverse doesn’t work like that.
Now, I realise I could simply not use Spring to manage which parts of the site should be accessed over HTTPS and which should not…and just setup Apache to redirect as appropriate. I don’t want to do that though, because that makes the task of adding these restrictions a deploy time task, rather than a development time task. I don’t want to risk someone forgetting to add new restrictions when deploying the webapp and I’d much rather the developer added these restrictions when they were working on the task and really thinking about where and when they are needed.
So, how do I solve the problem so that the app can manage its secure-ness and I can setup Apache once and forget about it? The answer is to ProxyPassReverse onto a “special” URL, which when accessed will redirect to the HTTPS (or HTTP) site. For example, if the HTTP site needed to redirect to the HTTPS site, I’d add rules like so to perform the redirect:
# Proxy a request (from the server) to switch to https onto a special URL "/2https/"
ProxyPassReverse /2https/ https://example.org:8443/webapp/
# When a client requests a URL prefixed with "/2https" map it onto the secure site
RewriteRule ^/2https/(.*)$ https://example.org/$1 [R,L]
…and you’d add something similar to the secure site Apache config. As long as I don’t mount any pages at /2http or /2https I should be ok. Note a couple of things:
You’ll need “SSLProxyEngine on” and “RewriteEngine on” and obviously the appropriate Apache modules loaded for these commands.
Because of the redirect between HTTP <-> HTTPS you won’t be able to POST data between them directly (I’m not sure why you’d NEED to though)
Obviously you’ll need to setup Apache with an SSL certificate…but that is a different story
I should say a special thanks to this random site – from whence the idea actually came from. If anyone has any better ideas on how to do it I’d love to hear them. Please comment below.