Most read posts this month



Nov 4th 2009 × CubeCart 4 security vulnerability: is your store at risk?

Whilst reading on XSS attacks today, I found this recently reported exploit in CubeCart 4 that can gain an attacker full administrative access to the store.

Not only that, it can help them dump your entire store DB – products, cats, users, orders, the works. Anyway, you get the idea. “CubeCart responded and informed their customers about this vulnerability” – as technical advisor for a site that runs on CC4, I can testify to the fact that the site owners were not informed of any such. Nice.


Jun 9th 2009 × CubeCart problems: no shopping bakset and login functionality for some users

There’s yet another one of these problems that are inherently weaved deep into CubeCart that you just wouldn’t know about… It displays different versions of pages to search engines and to humans, namely–it disables the shopping basket and checkout functionality as well as the login and registration.

First of all, needs to be said that troubleshooting this and finding the reason for users being unable to purchase off a CubeCart site is an absolute nightmare. When a customer says they use ‘bog standard’ IE8 and report their ‘add to basket’ button doing nothing whatsoever, one tends to think ‘has the javascript handler gone wrong?’. You go on a wild goose chase, trying to reproduce the problem and failing despite of installing various javascript exception tracking modules, looking through logs and quizzing puzzled shoppers. All the while, you can’t help but wonder about the possible extent of the problem, how many users get this? And then – you catch a break by accidentally discovering customers unable to purchase also lack the login/register links – time to start connecting the dots…

From session.inc.php, which controls the login / register links in CubeCart:
if (!$cc_session->user_is_search_engine() || $config['sef'] == false)

The template does not get shown to search engines? That makes sense… having different versions of pages shown to users and to spiders is not only a bad practice (google really don’t appreciate “cloaking” techniques), there is just NO need for it whatsoever. In order to prevent spiders from indexing pages that are deemed irrelevant to e-commerce and spill page rank / relevance, they could have been disallowed from within the robots.txt file. A rel=”nofollow” could have been applied to links to such pages… but what have the clever folks at CubeCart done instead?

They created a boolean method into the sessions class that decides if the user is a bot or not, user_is_search_engine(). It does so by comparing the contents of a file called spiders.txt, filled with “known” extracts from the user agent strings of various spiders from around the web, against the user agent string of the visitor. To be fair, the original idea for this kind of testing comes from OS Commerce…

The problem is when a legitimate customer is being discarded from using the site’s e-commerce because their user agent string is customised in a ‘bad’ way. How does that work? The original CubeCart spiders.txt file has lines that reject things like:

‘googlebot’ but also just ‘google’,
‘msnbot’ but also just ‘msn’

And so forth… multiply by x number of toolbars and custom strings CubeCart may never know about and you have a HUGE problem. For instance, users with Google Desktop get their user agent string set to Mozilla/5.0 (compatible; Google Desktop) so they promptly get rejected. Luckily, that’s not a very popular application but the “MSN” string and the absolutely COUNTLESS numbers of people that have got a user agent string like this one: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; Sky Broadband; GTB6; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; InfoPath.2; .NET CLR 3.5.21022; MSN OptimizedIE8;ENGB) presents a VERY real problem. MSN optimized IE8? Not on my shop site, mate.
edit: check your spiders.txt version, if it predates august 2008, you are affected.

I have been looking at the user sessions table and have thus far found over 3000 genuine users that have been rejected by CubeCart’s loose user agent matching routine. That’s a lot of business to lose and the store owners are understandably upset. It’s not free software and at a testing time like the credit crunch we’re enjoying, having your own store work against you is far from ideal. The real frustration comes from the fact that people had reported an intermittent loss of shopping cart functionality on the CubeCart forums and on their bug / ticketing system. Reported and dismissed – apparently, too difficult to trace or unsupported due to store being customised. Every programmer makes mistakes, but being unable to rectify them and failing to provide support to your paying customers – it’s just bad business. I am sorry to say, CubeCart has failed to impress once again…

The fix to the CubeCart user agent problem:

1. apply nofollow to the links for login, register and checkout
2. empty the contents of spiders.txt in your cubecart root folder (don’t delete it)
or
2. change user_is_search_engine() to always return false.

To test if your store is affected, use FireFox and check this post on how to change your user agent string, set it to the one I put as an example above and visit your shopsite, then try to add a product to your basket.

update: I am being told that this problem is no longer to be found in current releases of cubecart. Well done, the team :) Now, how many existing customers on versions pre-dating august 2008 have been notified?


Oct 19th 2008 × CubeCart: a ticking timebomb that goes off 1 second at a time

There are certainly some positive things that can be said about CubeCart, a low-end budget entry choice for an e-commerce platform. It’s certainly capable of doing the rudimentary functions it’s supposed to do: lets you add products into categories and lets customers look at them (even buy some!). It also supports a number of popular payment gateways / merchant accounts. Not rocket science.

My gripe with it starts at the price tag: $179.95. You don’t get a lot for your money that you can’t get for free elsewhere (eg OS Commerce, Magento, BossCart JV, VirtueMart, Mambo… to name but a few). In fact, you get nothing.

Irregardless, let’s assume–you are a self styled web 2.0 start-up that wants a piece of the pie, but with limited or no technical knowledge, scant time and resources. And a tight budget (those VC must be sleeping). You have splashed cash on cubeCart and have spent considerable time skinning the shop and populating it with your product range. It’s time to look at the business logic behind your shopping process, the SEO, the landing pages, the sizing and shipping options… And to discover that most of these trivial functions are available as paid-for (as in, you have to pay afresh) ‘community’ add-ons. Should you decide to display products based on brand/manufacturer, that’s also a commercial add-on. You get the picture? It’s a scam. By this time you’re well over your budget and behind schedule so you figure, stopping now means it’s all gone to waste. But perhaps you should, because CubeCart is certainly full of nasty surprises. Read on…

I had the dubious “pleasure” of supporting and improving a CubeCart 4.2.0 shop. Having had to implement and skin a ton of buggy or not totally adequate plugins that were purchased, I discovered another negative side to all of this: the CubeCart modders tend to base64 encode all of their work. That’s right, you can get shipping by country and you can pay for it but by god, you can’t change it. Which would have been ok if any of those fine developers actually had a clue and understood how an e-commerce business operates. Experience has taught me one thing: e-commerce is not what about what a programmer thinks it should be. you don’t just measure the strength of your platform by the number of product attributes or skins you can apply. It is also about making the shop owner’s job as easy and as organised as possible. What does that mean?

For instance… viewing orders into the main admin window or even as popups into a new window is cumbersome and difficult to do especially if you get more than, er… 1 a day. Imagine 40 orders waiting to be shipped, your couriers arriving in 30 mins, your phone ringing off-the-hook, new orders coming in, RMAs arriving and replacements needing to going out… and how do you manage this? Certainly not by looking at the CubeCart orders list, unless you have the memory of an elephant and can remember the contents of each order just by glancing at its order ID or customer name. Of course, you can just click into an order and then see the items contained within, go to your warehouse, find the item, pack it, get back to the PC, print the invoice, login to your couriers’ site, print the label, affix label to box and set aside for pickup. 39 more to go, go back to the orders screen and see if you remember where you were…

Nevermind, all of this can be fixed eventually by a consultant like myself a process that makes the original prudent investment of $179.95 seem like a very pleasant memory indeed! But the problems do not stop there… For example, after a while of the store being operational, the shop owners are bound to notice certain… trends. Like, why do people phone in and report that somewhere between clicking add to basket and going to checkout screen, their basket gets lost (something also reported on the forums). Intermittently. As you fix this sessions PHP error, you think… we’re ready for the big time, everything is sorted… Wrong again. CubeCart has more surprises in-store for you (great pun, if i say so myself). Over time, the speed of display of your product pages starts to increase. A lot…

Now, I use 24mb ADSL by be.there in London – pretty fast. I used to get the whole page (with all images) for something like 0.8 – 1.3 secs. Imagine my surprise when the delay between a link click and the start of page rendition (the ‘waiting for response’ phase) was over 4 seconds on its own! With nothing else changed to the best of my knowledge, my first reaction was to look at the MySQL database. I scanned it, profiled it, analysed it – to no avail. Deleted various search histories and session data entries, added some indexes… still nothing. Upgraded the MySQL version to 5.0.58 – no change (other than Fedora Core’s YUM removing Zend and MySQL support out of php.ini and Plesk refusing to work and pop3 passwords being rejected). Once I managed to fix all of that and turned by attentions back onto the website, the evidence still sides with my original suspicion: a database-related delay. It was time to do some query profiling… I found and modified the CubeCart DB class and added a timer and an echo wrapper around all mysql_query() calls. And there it was, waiting for me at the bottom of the page:

SELECT DISTINCT O.productId, I.name, I.image, I.price, I.sale_price FROM CubeCart_order_inv AS O, CubeCart_inventory AS I
WHERE I.productId = O.productId AND O.cart_order_id IN
(SELECT DISTINCT cart_order_id FROM CubeCart_order_inv WHERE productId = 274)
AND O.productId <> 274 LIMIT 3

3 rows in set (3.74 sec). Nice. Nicer still… site does not even use the ‘customers who bought this also bought’ feature! What’s happened? Well, over the last 6 months, the orders and orders inventory tables have grown to something over 2500 records – which has caused this nasty nested query that returns 3 measly product IDs (that may not even be relevant for an up-sell here) to bomb the server.

This begs the question: haven’t the CubeCart development crew done any testing on their system? Or hasn’t anyone that’s used CubeCart before gotten to 2000+ orders? Small wonder…

How many more red herrings are there waiting to be discovered in CubeCart, we’ll never know. Just a word of advice: do not pick this for your platform, even if given half a choice!


Sep 15th 2008 × Ecommerce platforms: BossCart JV

As I am pushing on in my quest to find a perfect free e-commerce platform that has great SEO, ease of product, brand, stock and category management with industrial strength order management. Not an easy task, to be sure… The latest package I’d like to talk about today is BossCart JV by BossCart

What I had presumed to be a lightweight version of their bespoke commercial product is actually quite different. For starters, it uses mootools (1.11) and the “commercial” cart is under jQuery but let’s not draw any conclusions on the strength of the frameworks based upon this just yet, heh :) . It also seems to lack one very important facet of trading: brands/manufacturers (this has been left for the ‘full’ version once again). Other than that, first impressions as a user: it appears to have been coded within the spirit of Web 2.0 in mind – search tags, lightbox imaging, product ratings, the chunky yet slick looks…

Since this IS fragged.org, we write about what we don’t like first and assume the rest is fine or dismiss it as boring… With that in mind, let’s pop the bonnet and see if this baby can organically give good SERPs. n.b. you can always fix the css/theme so this is very superficial

I picked http://jv-cart.bosscart.com/golf-iron-supplier as the page to disect first.

I always wondered what JV stood for and some light got shed here:

<img src="http://jv-cart.bosscart.com/components/com_virtuemart/shop_image/product/0a2d9237bb75f96c09db6f5d91de7287.jpg"  width="135" border="0" alt="Titleist Pro V1 Premium Refinished Golf Balls" style="float:left"/>

Seems that at least in part, the jv-bosscart are based on Joomla / Virtuemart. This explains a lot – mootools 1.11 and not 1.2, for starters (Joomla have yet to move over).

The URL is SEO friendly enough, although the title does not appear to be even remotely relevant. We find this:

<meta name="description" content="" />
<meta name="keywords" content="sample Boss Cart JV golf shop,http://jv-cart.bosscart.com" />

It may seem like a little thing to simply go and set it manually – but the last e-commerce site i worked on had 1200 products and 50+ categories. Today’s e-commerce software needs to try and back the site owners up and fill in wherever possible…

The default theme seems to have a topbar and a side menu element floated to the left, with the body of the page that follows. Obvious disadvantage of that is that repetitive text (categories, site pages, header bits) will always precede the real important page headings and body texts that will determine the page relevance.

The page also appears to be using a mix of css-driven-design and tables, as well as plenty of inline css.

Also stuff that you can clean up as you customise it. Links not having title tags is yet another hindrance that will need fixing.

The first real page-relevant bit of code in the source is at line 228 (a bit too far down for my tastes). The most important dynamic content, keywords, heading tags, descriptions – they should be as close to the top of the page as possible and without too much markup. This may be a semantic view but it works.

The questions here is, are there good enough framework templates to get you started re-skinning the default one?

How effective is the organic SEO out of the box? I decided to search on google for the products in the test shop – obviously w/o any proactive marketing as examples: Bay Hill Plasma irons comes as no. 1, Bay Hill Irons as the 4-th site down. This may be due to the number of inbound links to the BossCart site but it’s also no fluke. The product descriptions are explicit and help matters also. Titleist Golf Balls comes up also on page 2.

The provisonal verdict for BossCart JV: There are a lot of areas that need work – messages here and there, visual glitches, optimisations and other bits. We’ve not looked at the admin interface yet — but it has potential. I would say, as an out-of-the-box free solution, it probably does more for a startup business than oS Commerce or CubeCart.

I will post updates here as soon as I find more about it.