SimChris

FYI, as of January 1, and still today as of 9:50am PST Jan 2, 2015, getting 500 server error trying to access: https://www.cubecart.com/ http://www.cubecart.com/

Hi, Al thanks for all the feedback. Always know my feedback has always ever been intended to better the product, vs being one of the whiny complaining folk you sometimes run into around such forums. :-) We are using AIM. We have no expensive cost for the PCI-DSS compliance as it's included in our merchant services contract now, and First Data covers that cost for us now. Since we've been in business, have a merchant account for 20 years, have our own servers, etc., why pay to host a payment system elsewhere which we cannot control security on. Prefer to do it in house. Our ecom systems have not been hacked EVER, although numerous attempts since 1996 ;-) Paranoia mode = on! For CubeCart ... My main "wish list" for security would be the ability to always capture IP (yes, we know it can be forged) on any account setup, and be able to query that against an internal blacklist, to stop some folks from creating further fake accounts to test the system, either as spam account, to see how far they can get without using credit cards, see what kind of email replies they get to assess mail and php replies, etc. So, fake customer sets up dummy account; IP 1.2.3.4 fake customer sets up dummy account; IP 1.2.3.5 fake customer tries fraud; IP 2.3.4.5 blacklist 1.2.3.4, 1.2.3.5 blacklist 2.3.4.5 fake customer tries setup; IP = blacklist ; warning message not allowed due to system abuse - goodbye! Account NOT written to dbase and deleted, NO email sent to FAKE client, but logged as bad IP attempt. We have something similar for those who try to login to our WordPress sites, by guessing username/passwords. After 3 attempts, the IP is blocked for 4 hours; further attempts from same IP, blocked for 2,000 hours (!). Same idea. Nothing too horribly complex, just a "check new customer setup IP against internal black list" step. This assumes no guest checkout. Thanks for all the great work. Has it really been 5 years ? Happy holidays!

I am having the same issue as of today (I did not check sales as of yesterday, as it's a holiday here). On main dashboard 2014 sales graph gone; text right side says 2013 and 2015. The legend shows "Sales Statistics: 2013 - 2015" Only one graph, in red, blue graph line zero horizontal line full year. PHP Version 5.4.22; CC 5.2.13 php time is 2014-12-29 19:16:41. ------ (edited) THE FIX ... post #7 - changing first bit of code to second bit of code WORKED. Thanks! Forum saves the day again!! Happy Holidays. :-)

As I said we're leaning to another system altogether for next year, which either had these types of features built-in, or one time fee vs ongoing added costs (E.g., Authorize.net's system is good, but not very cost effective for our small number of orders, albeit some with big ticket dollar value). Just bringing this up that the built-in tools were not useful in blocking the issue we were having. It might not impact others, although I can see it being huge issue for those with downloadable content without "operator approval" for downloads (e.g., "instant download"). In any case for those of us in the USA, this might be some food for thought for additional CC6 features as selling point for the increasingly security conscious. Thanks again for all the feedback :_)

Additional costs -- it's not free. What did they quote you for the monthly fee? Hi, Ian thanks for sharing. I'd never heard of that plugin, and I did look around for one (guess they need to do some advertising!). I will look into that since we generally do less than 200 orders a month. This was never intended to be a security feature. Um, then what is the point of having a feature to allow or disallow countries for each gateway, exactly?

Well... the issue was with CubeCart specifically, where if I have American Samoa blocked in the CC5 panel for denied countries, the cart will still pass an order for ANY country over to Authorize.net regardless of the actual country the billing address happens to be, if USA is put in the country box on checkout - making the allowed/disallowed countries option meaningless for blocking unwanted customer groups as apparently intended. This happens prior to pushing to Authorize.net, and basically bypasses the behavior of not showing payment gateway option -- ANY country can post to authorize.net as long as United States is put in country box in CC checkout. So, blocking/allowed options in CC admin rendered meaningless. This was the point I was making. And yes, bsmither, as a company who was building ecom systems for clients as of Jan 1996, including Oprah Winfrey/Civitas, the No Fear clothing company (remember them?), etc. (pardon name dropping), and in business 31+ years we are very aware of how cards work and how ecommerce works. Our old cart system prior to 2010 allowed us to block IP ranges in the cart system to disallow those customers creating accounts by doing IP lookup, which CC doesn't support; nor does it allow for any velocity checks, such as one customer trying 20 different order attempts over and over for THE SAME ORDER; which is not normal. We don't use delivery addresses other than as required by the cart -- we only sell services, so shipping and tax related stuff generally not relevant to our use case. So checking for delivery address is meaningless in our context since ANY address could be entered when fraudster checking for working cards. While we can use the advanced fraud detection suite as a paid option, it's not inexpensive, and being able to do basic IP check/deny for account creation and velocity check would be great addition to CC. e.g., 1) IP range for Ukraine blocked; on account creation check originating IP and if blacklisted, deny account creation or any purchase attempt before going to payment gateway(s). 2) order velocity check ... 5 or more failed order attempts with any mix of credit cards, all returning decline; stop order process and more order from pending to failed fraud review, etc. I would think these kinds of options would be important for anybody wanting to sell downloadable content, but in our case completed checkout allows client to move on into our project submission system, which somebody who was a bad hat could take down by overloading the form handler for that, disallowing good customers from turning in work. So, we need to do as much as possible to pre-screen and block the bad hats. Which we do before any work is performed, obviously. The issue has come up through 1) customer used 45+ cards on ONE pending order in CC5, until one worked, and got order confirmation, passed through to our project platform. Not good. Country on blocked list, but not relevant due to the stolen cards being U.S. based for billing/delivery addresses. No IP check capability to block origination of hacker/fraudster using system at all. We have now blocked Ukraine entirely from our server. 2) fraudster from another country (.de) using stolen card, with blocked country billing/delivery address, bypassed the block list for countries in CC for authorize.net by cleverly just changing country to United States vs American Samoa. CC5 let that go through, got 2 declines, and then I happened to see it purely by chance checking on a good customer payment. Since we're in the news business, and main site has been online 15+ years, we have very high visibility in search, and so we do end up being targets for various things. For 2015 I am evaluating other carts and security solutions because of this kind of security issue. I am only bringing all of this to your attention for possible future solutions in CC6, possible plugin developers who may want to extend CC5/6 with some kind of security black list and velocity check, etc. Example of some of the options folks are coming up with for other carts like the Woo folk: http://aelia.co/shop/blacklister-for-woocommerce/ Key Features of Blacklister plugin •Allows to blacklist email addresses, using exact matches or regular expressions. •Allows to blacklist IP addresses, using exact matches or IP ranges. •Customisable error messages to notify the user why their checkout process was halted. Also for Woo http://www.woothemes.com/products/woocommerce-anti-fraud/ These are just some of the examples of solutions for open source stuff, but the big commercial store systems are also building stuff like this in to fight the kinds of abuse which are only going to increase more and more. Love you guys at CC ... almost 5 years now. However, the above kind of stuff needs to be "baked in" for our needs in the future. Peace out, and happy holidays to all! :-)

Hi, folks ran into a minor issue today, whereby somebody placing a fake order from Germany (.de), with a stolen card with billing address of American Samoa, was able to bypass the CC gateway setting by simply putting American Samoa as the state, and then U.S. as the country, and it pushed through to Authorize.net 2x before I caught it. Adding an IP check to CC is going to be a mandatory addition to CC6 for us to keep using it as sadly it's too easy for people with stolen cards to use CC to "test" whether cards validate or not; a huge issue with all the hacked sites the past year. Right now there is basically no way to stop somebody from testing cards, by tricking the country setting to bypass the "don't allow from countries" setting in CC, and Authorize.net doesn't check "country" for AVS, only address, zip, security code, and card number. Basically ecom systems need to be more and more "locked down" with controls to block and/or blacklist IPs to stop abuse of the system. Yes, we can manually block IPs at server level, but it doesn't stop somebody from running a series of cards as happened to us on Nov 30th or so, when Ukraine hakcers were running 50+ cards against our store, using stolen American/US cards, when we're closed at night or weekends (when evil doers in other time zones are awake and we're sleeping). PLEASE consider IP blocking option/blacklist, and possible "lock out" option for more than 5 order attempts.

Hi folks we've had this happen couple of times over past few years with CC, which appears to be a little bit of a target for this activity since there is no option built in to block account signup/carts based on IP lookup (CC is not the only cart so 'afflicted' but many other cart systems have a way to block this behavior; even my WordPress installs have a way to block this with plugin). Today we had a Ukraine outfit running over 100 stolen MasterCard numbers to help determine which ones were "usable" ... and they did find one. Luckily we sell services, not downloads or anything else, so I double check all orders personally out of paranoia. Nothing they can do on our system once they "make it through" with valid card pass. We had to manually block their IP range via the server side firewall, for this entire range in the Ukraine: 77.52.0.0/18 This kind of thing typically seems to happen around holidays (happened 2 years ago at this time), and all the stolen cards are MasterCard numbers. Thought I'd share this with anybody else who generally runs in "paranoia" mode this time of the year. Happy Holidays!

Be sure to check your Google Webmaster account for crawl errors, indexing issues, warnings, etc. Be sure to submit valid site map to Google Webmaster Tools. Be sure you have told them whether you are doing an http or https site, and preference for www. vs non www in front of domain name. Be sure to check if you have dedicated IP that your reverse IP lookups are all correct (various tools online allow you to type IP and it will show pointing at your domain). These have been the most common things to check with Google "oddities".

Sometimes the only way to do that in Vector, is to view the page with Chrome's inspector (F12) and then find the CSS class you want to change; then in the main template put the CSS class override into the head area and you might have to put an !important element for the class setting. Likely need to put this "inline style" element as last thing in the head after their dynamic call to the index.php page so that it is read last. I did this for something, but I forget what. Other option, edit the style CSS file being loaded by the theme (such as the .less files) to replace the actual CSS for the classes you want to change. Since theme likely won't ever be updated, you can get away with hacking the CSS style sheets without fear you would need to change them back later. Not as elegant as doing something from the "control panel" ... but welcome to hacking CSS :-) We're moving away from Vector, sadly, due to the fact it won't work with mod_SPDY and the company is pretty much dead, so likely no future use with CC6. (Sigh.)

Sometimes they look for vulnerabilities in the software being used to send email, such as comment forms; sometimes they want to know the email path from your system. Super annoying.

Claudia you should always be logging in to your admin with https anyway. To be honest, I used to not do that, but now I do. If you use a bookmark like I did, just go there, add the s in the browser window, make NEW bookmark, and your admin will be https next time you use the new bookmark.

Memcached is caching system running above your domain at root server level, accessed via the memcache php extension. Some systems use APC for caching vs memcached (as ours does), and this does speed everything up. We are using APC above the domain, then the normal CC caching for local caching issues. But we have small ecom install. That likely doesn't help, but thought I'd share while poking about to see about the new update today :-)

It's possible the DNS A name or C name records are messed up on the server for your domain, where on many modern servers where there is a shared IP address, one domain is always the "primary" domain for any shared IP. When DNS fails for any other domain, it can sometimes load that default/primary domain (sometimes first one setup for the IP). You can often test this by simply typing in the IP address for your domain and see what comes up. It can also be an issue with domain hijacking of DNS, or bad DNS entry at your domain registrar, where the domain should be pointed at correct name servers for your hosting co., and then DNS entry (A NAME record) on the host server points your domain name at the shared (or dedicated depending on plan), IP address. If any of those elements are borked, you won't get correct site typing in your domain. If you cloned your install from another site, there will be leftover coding from that other site, obviously, and the rewrite rules in your htaccess file might point there; or if it had been hacked or corrupted. Sometimes if the host has a disk failure, and they do a backup overnight, the might mess something up - and normally they should tell you of that. Not very common anymore with modern RAID setups, where a bad drive can be swapped without impacting the full dataset. Not sure that helps. But maybe some extra food for thought.

Nope. CC5 still taking orders.

@DIRTY Well - in theory - you shouldn't have to change anything in your store files, as ecom systems are designed to run "all pages as https" provided you set it up that way to begin with; my store has been https from inception because we take orders and push to authorize.net via AIM method. So, typically all you should need to do is get SSL cert installed, then update your CubeCart settings for the store to be located at https://yousitevs http://yoursite. Note the "SSL" tab in your CC5 admin control panel store settings > SSL tab You shouldn't have to do much more than that to start with.

Good choice since Google *has* said they want to see entire sites https, not just the ecom systems. Which is why we're doing that to 20,000 pages of content from one site over 15 years. Issue with https vs http in "speed" has to do with your Google PageSpeed Insights score, which might drop one point (or more) depending on how your server does in serving https pages vs http pages. Since we have some complex pages we're adding mod_SPDY (which will be built into future version of Apache anyway) now to help "speed up" all https pages so they load as fast as http, and we use mod_pagespeed to optimize delivery of static elements. Those are advanced topics, but most hosts will have these as built-in offerings within the next 24 months or not be very good hosting companies. Right now, as long as you switch to https and watch out for the "gotchas" it looks like you're already on top of, then you're well on the right track. Hope that helps somebody :-) (FYI, I managed a web hosting company from 1996-2005; started building ecom sites in '96, and did projects for Oprah Winfrey/Civitas, and No Fear clothing, etc.).

The only issues I have had with SSL on the whole site, meaning outside of the CubeCart folder has been with mod_SPDY. The issues with running https on your entire site have to do with a) runs slower due to encryption you have to update canonical links c) you have to update all image links d) you have to load all js/css as https e) you have to load any external elements, including CDN, over https On some installs of Apache, CentOS, et al, there is a known issue with a redirect loop when you do a "force transport SSL" of the domain at the server level, but that only impacts some setups and also the issue with mod_SPDY. So, no issue with doing local htaccess 301 redirects as per my example, provided you update Google with your new https vs http page layout. "Forced" means in most cases a "required" connection; meaning disallowing http connections. Generally "forced" means an http connection is NOT allowed at all. Whereas simply changing your structure to serve https pages, doing redirects for inbound links to old http pages (e.g., from social media links), and updating site maps, canonical links, etc., have no issues. There are some gotchas on "some" shared hosting setups with shared IPs for having SSL certificates, but your host would have warned you about that with your account contract. So, if you follow best practices with installing your SSL Cert, updating all your links, and all the stuff mentioned, it's a non issue, just an adjustment period. I just updated 10,000 pages of content today. Missed the subscribe to daily summary via Feedburner link which was still http. IE11 said page secure. Chrome gave me warning that the form link to Feedburner should be secure also. Duh. Fixed! Now passed all https/SSL checks. Did that help?

Hi, you're welcome. I just happen to be doing this with our main website "right now." (Literally working on that today/Sat.). We have a 15 year old site, with CubeCart5, 2 wordpress installs, pre 2005 static content for news, post 2005 custom CMS, then static .shtml service and company info pages. It's been a barrel of monkeys to do this in "sections" to migrate things to https, but getting there. Ecom has always been https, but the "normal" pages have been fun to swap to new deal. And as long as your "canonical" links on all pages show htps// then you are effectively okay from the "duplicate content" penalty. Right now Google is being a bit loose on anything where sites have both http and https loading since up to 40% of major web portals are in midst of this conversion process "right now." So, I think there is likely a window until next Spring, where no major penalties for some minor stuff will be adverse. Glad I could help. :-) Next fun thing is ask your hosting company about mod_spdy to "speed up" all the https pages. quite cool tech where it basically serves up an https page as "one" connection, so there is just one gzip encrypted bundle, vs 20 elements, CSS, JS, etc. Does not work with the two third party skins (Vector and um I forgot), but all the normal skins work fine, and so should be fine with CC6. But luckily most web servers are now setup to optimize for https, so it isn't like 5+ years ago where normal page would take 2 sec and https wwould take 10. Now it's more like 1/2 sec to maybe 1 sec speed penalty at most depending on server. Anyway.... food for thought when it comes up.

Hi, Google has a nice document online regarding converting your site from http to https, and best steps to take; and most often best way for Google to learn about the change is to submit updated sitemap with https vs http URLs. If your shop setup doesn't build the XML sitemap properly you can also use external mapping tools like "Sitemap Creator" which we use for some sites which have mix of static/dynamic content. Make sure you have your sitemap updated in your Google Webmaster Tools account, and update your root URL in your account to show new URL as needed. Actually, I think it's the "change of address" tool: https://support.google.com/webmasters/answer/83106?hl=en With Apache servers, you can use this method for redirect I've pasted in. RewriteEngine On RewriteCond %{HTTPS} off RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L] And oops ... here is the Google doc I was mentioning: https://support.google.com/webmasters/answer/6073543?hl=en

Thanks to those who have offered to help us debug the issue. We have decided to abandon vector since the company is pretty much out of the picture who developed it, and likely won't work with CC6 which will have responsive features baked in. Not worth spending the time /effort to fix Vector since it uses proprietary ajax-based framework. For our purposes we're setting up temporary Woo store then will upgrade to CC6 when available from the CC5 store; running BOTH CC5 store and Woo store for Firefox users. Annoying but makes no sense to waste any more time/energy on a doomed skin/template system. Mod_SPDY will be built in to future version of Apache, so anything that doesn't work with mod_SPDY now, will definitely be useless in the near future. Thanks for the personal messages, however. :-) Thankfully CubeCart works with mod_SPDY just fine :-)

Hang in there :-) CC6 will be even better with a nicer built-in responsive "skin" template.

CubeCart has worked great for us since 2010 resulting in over 1.4 million dollars $US in revenue. It does work. And works well.

<LOL> okay.... see what happens when I work two weekends in a row..... wow. Thanks for pointing out I am going senile. Yes, the users/admins account settings in the CC admin panel Duh. Thanks ! Chris

Hi, seems like good time to change my superuser admin name and password for CC5, and wasn't sure if there is way to do that via a config file, admin, or if both must be done via phpmyadmin or similar? Reason: had a customer setup account (no IP as is common with hacker folk), and noticed his mobile phone number was the superuser account name for the CC5 store. Which is a bit troubling. (We are PCI-DSS certified, best practices, based on 20 years on the web, manage our own server, etc.). Didn't see this in the docs, but I've hit middle age now... so maybe it's me. ;-) Thanks for pointers on this, folks !