With our move to production last week came a number of “interesting” challenges. One particularly fascinating artifact was that switching context between SSL and non-SSL would cause the connection to be dropped and therefore clicking on links under SSL would produce.. nothing.
It turns out that many “free” and open-source products or APIs will get you on SSL and charge you big bucks when you are most vulnerable – i.e. when you need SSL support (a.k.a moving into production). This is true of Google and also of IceFaces and several others.
Here’s the background for the situation we found ourselves in: we use Google’s “free” map API extensively throughout the website to provide information to our customers about distances to and from airports, airport information, directions, etc. and of course actually mapping the airports graphically on a map.
The free version of Google maps – as it turns out – does not work under SSL. That is, unless you have an extra $10,000 laying around that you are just eager to pass on to Google just for the privilege of being able to do Google maps through SSL. By the way, Google buries the price information about this deep within its site and even then it only offers prices in GBP – not in dollars.
This made IE completely unusable but worked reasonably well under other browsers, although not without problems. This had to be fixed.
Of course, we’re a startup and we have much better things to do with $10,000. But even if we weren’t – it is ludicrous that Google would charge that kind of dough just for SSL support. There is and cannot be any justification for that. The paid Google maps “Premier” is supposedly for sites that charge customers for access to maps (or where only paying customers can access maps). In our case it is completely free – both registered customer and non-registered customers can access maps and even registered customers are not charged for their membership. We have no need to be a “Premier” customer.
It also turns out that IceFaces’ ‘push-server’ does not support SSL out of the box – only the paid “enterprise” version does. The only way to find that out is on the forums as it is never mentioned in the actual product literature. I’ve complained about IceFaces here before, but unfortunately we still have to use them in various parts of our product-suite.
However, if we are not happy with “free” version, why on earth would we pay for the enterprise version?
The 1st part of our solution was to isolate the checkout page to use SSL (https) and have the pages that use Google maps run under regular http. We can do that since we use the Google API on pages that do not contain any sensitive information.
This would solve our Google maps problem.
It also means that we need to switch context between SSL for some “pages” and non-SSL for others.
This “context-switching” cause IceFaces to drop connections:
[..] com.icesoft.faces.webapp.http.core.RequestVerifier service
INFO: ‘POST’ request expected. Dropping connection…
My first reaction was to blame IceFaces for yet another bug.. – but it turns out to not be a bug. It’s just that IceFaces is such an intrusive API that you have to do a lot of extra administrative work to make it work through Apache SSL. Especially in our case since we use mod_rewrite extensively.
So here’s the setup:
In httpd.conf we have 2 virtual hosts one SSL (port 443) and the other not (port 80). We intercept calls to secure pages that go to the non-SSL virtual-host and mod_rewrite them to the secure host – and vice-versa for the context switching back.
You need to make all IceFaces resources switch contexts together with all the uris they are linked to. Otherwise, IceFaces will not be able to find it’s /block/ content.
The best way to see what content IceFaces is trying to get is through a javascript debugger like FireBug.
In it you will see that resources such as
/push-server/block/receive-updated-views
cannot be found (error 404) or – if you do mod_rewrite redirects like we do – it will say something like:
“301 resource moved permanently”
This is your hint that during context switching you are redirecting away IceFaces resources. So in httpd.conf you need to add the following RewriteCond’s for the SSL virtual-host:
RewriteCond %{REQUEST_URI} !^/<uri-path/to/secure/resource1>$
RewriteCond %{REQUEST_URI} !^/<uri-path/to/secure/resource2>$
[…etc. secure resources..]
RewriteCond %{REQUEST_URI} !^/push-server/block/receive-updated-views$
RewriteCond %{REQUEST_URI} !^/<uri-path>/block/send-receive-updates$
RewriteCond %{REQUEST_URI} !^/<uri-path>/block/ping$
Then add the same configuration with reverse logic in the non-SSL host. i.e the above example checks that the resource “IS NOT” (!) and has an “AND” relationship between RewriteCond’s; whereas the non-SSL host checks that the resource “IS” and has an “OR” relationship between RewriteCond’s.
We hope this helps others who are stuck in the same situation, but especially it will help others fight back against deceptive practices by some supposedly “free” and “open-source” companies that try to milk you when you’re most vulnerable.
Gad Barnea – CEO- FlyMiwok, Inc.
Comments on this entry are closed.