Category Archives: Hosting

RoundCube 0.7.1 login failed

Posted on by
7 Replies

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’.

How to switch to/from HTTPS using Apache as a proxy to Tomcat

Posted on by
9 Replies

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.

Webalizer GroupAgent config – round 2

Posted on by
4 Replies

A helpful reader pointer out that Opera has borked it’s user agent string, which unfortunately means that webalizer can no longer distinguish between Opera 9 & Opera 10. It is a bit of a shame, but not something I can do anything about.

I also took out the “Version/4″ detection for Safari, because it is a little stinky – any browser could put “Version/” in their UA string (which happens to be exactly what Opera has done). So here is my updated webalizer GroupAgent config, for use with version 2.01 of webalizer (which is the Debian stable version):

GroupAgent      Firefox/3               Firefox 3
HideAgent       Firefox/3
GroupAgent      Firefox/2               Firefox 2
HideAgent       Firefox/2
GroupAgent      Firefox/1               Firefox 1
HideAgent       Firefox/1
GroupAgent      Firefox                 Firefox
HideAgent       Firefox
GroupAgent      Chrome/4                Chrome 4
HideAgent       Chrome/4
GroupAgent      Chrome/3                Chrome 3
HideAgent       Chrome/3
GroupAgent      Chrome/2                Chrome 2
HideAgent       Chrome/2
GroupAgent      Chrome/1                Chrome 1
HideAgent       Chrome/1
GroupAgent      Chrome/0                Chrome 0
HideAgent       Chrome/0
GroupAgent      Chrome                  Chrome
HideAgent       Chrome
GroupAgent      iPhone                  iPhone
HideAgent       iPhone
GroupAgent      Safari                  Safari
HideAgent       Safari
# Instead of using "Opera/10", Opera stuck with "Opera/9.80" and added "Version/10" to their UA
# string - this means we cannot distinguish between Opera 9 and 10 using this version of webalizer
GroupAgent      Opera/8                 Opera 8
HideAgent       Opera/8
GroupAgent      Opera/7                 Opera 7
HideAgent       Opera/7
GroupAgent      Opera/6                 Opera 6
HideAgent       Opera/6
GroupAgent      Opera/5                 Opera 5
HideAgent       Opera/5
GroupAgent      Opera                   Opera
HideAgent       Opera
# TODO: When Debian finally upgrade webalizer, use "MSIE x"
GroupAgent      8.0                     Internet Explorer 8
HideAgent       8.0
GroupAgent      7.0                     Internet Explorer 7
HideAgent       7.0
GroupAgent      6.0                     Internet Explorer 6
HideAgent       6.0
GroupAgent      MSIE                    Internet Explorer
HideAgent       MSIE

Webalizer GroupAgent config

Posted on by
7,124 Replies

I’ve wanted Webalizer to group the UA strings for the major players in the browser market for a while now, and finally sat down this evening to poke around with things.

I don’t believe in “grouping” everything, because it just means I end up with a massive “grouping” list to maintain, and I just know I won’t be able to do that. So I’m just concentrating on the browsers who hold most market share for the browser demographic my client’s site’s are attracting. Besides, browsers with a small market share (I’m taking like less than a couple of percent here) aren’t really worth grouping.

As a developer, I’m interested in what versions of browsers visitors are using, but not that interested…and not so interested that I want to confuse the clients who are going to view the stats for their site. So I’m grouping by major version number, making sure to define a “catchall” style group for version numbers above/below any of the groups I have defined. This means that any new browsers versions released before I get a chance to update the list are still grouped.

The only problem I ran into was trying to define a GroupAgent string for IE. I wanted to match MSIE 8, MSIE 7, MSIE 6, etc. but unfortunately space characters delimit the GroupAgent string. Which is a bit of a pain. I noticed that the sample config file on the webalizer site used quotes to surround the string and encompass the space, but that didn’t work for me. Perhaps because Debian stable is still using version 2.01.10 from 2002. Gotta love Debian. I’ll revisit if they ever update the package.

Anyway, that means that I’m using just version numbers to group IE. Which isn’t great as we could potentially get some false positives…but hopefully not many as we’re matching all the other big players beforehand.

GroupAgent	Firefox/3		Firefox 3
HideAgent	Firefox/3
GroupAgent	Firefox/2		Firefox 2
HideAgent	Firefox/2
GroupAgent	Firefox/1		Firefox 1
HideAgent	Firefox/1
GroupAgent	Firefox			Firefox
HideAgent	Firefox
GroupAgent	Chrome/4		Chrome 4
HideAgent	Chrome/4
GroupAgent	Chrome/3		Chrome 3
HideAgent	Chrome/3
GroupAgent	Chrome/2		Chrome 2
HideAgent	Chrome/2
GroupAgent	Chrome/1		Chrome 1
HideAgent	Chrome/1
GroupAgent	Chrome/0		Chrome 0
HideAgent	Chrome/0
GroupAgent	Chrome			Chrome
HideAgent	Chrome
GroupAgent	iPhone			iPhone
HideAgent	iPhone
GroupAgent	Version/4		Safari 4
HideAgent	Version/4
GroupAgent	Version/3		Safari 3
HideAgent	Version/3
GroupAgent	Safari			Safari
HideAgent	Safari
GroupAgent	Opera/10		Opera 10
HideAgent	Opera/10
GroupAgent	Opera/9			Opera 9
HideAgent	Opera/9
GroupAgent	Opera/8			Opera 8
HideAgent	Opera/8
GroupAgent	Opera/7			Opera 7
HideAgent	Opera/7
GroupAgent	Opera/6			Opera 6
HideAgent	Opera/6
GroupAgent	Opera/5			Opera 5
HideAgent	Opera/5
GroupAgent	Opera			Opera
HideAgent	Opera
# TODO: When Debian finally upgrade webalizer, use "MSIE x"
GroupAgent	8.0			Internet Explorer 8
HideAgent	8.0
GroupAgent	7.0			Internet Explorer 7
HideAgent	7.0
GroupAgent	6.0			Internet Explorer 6
HideAgent	6.0
GroupAgent	MSIE			Internet Explorer
HideAgent	MSIE