Archive by Author

Social Media

16 Jun

Are you on the cutting edge of Social Media interaction ?  Got a Facebook page for your business ?  Always Tweeting about your products ?

Social Media is a great way to interact with your customers and give your products more exposure.  Here at FreeWebstore, we’ve got your back with a few handy features that you might not be aware of.

Facebook Storefront

Our Facebook Storefront app allows you to publish your Product catalog directly to your Facebook Business Page using our simple app.  Once you’ve added the app, your products will be integrated into a tab on the page, and can be viewed by customers looking at your business via your Facebook presence.  We’ll automatically keep them up to date for you too.

Products can be Recommended by Facebook users, exposing your products to their Friends list and helping to get the word out.  Obviously there’s also a link to the store page included, so they can purchase the product directly too !

Facebook - Create A Page

If you already have your Facebook page set up, then it’s just a case of activating the feed, visiting our App Page, choosing which page to add the App to, and entering your unique Shopkeeper ID which can be found in the top right of the “Marketing > Social Media > Facebook Storefront” section in your FreeWebstore Control Panel along with a full set of detailed instructions.

FreeWebstore Facebook Tab App

As always, if you get yourself in a muddle, our friendly Support Team are here to help – just drop us a Ticket and we’ll get right back to you (usually within a couple of hours) !

Posting To Twitter and Other Social Media Platforms

Twitter is a wonderful way to keep your customers up to date on new developments with your business, as well as letting them know about your fantastic new products.  When you save a product in your FreeWebstore Control Panel, you’ll get the option to Tweet about it (with a link to the product page) as well as post it to Google+ and Facebook, creating a buzz and letting your Followers know as soon as you’ve got something new in your store.  It’s also a great opportunity for them to ask questions about the product and interact with you, which undoubtedly leads to more sales !

TwitterFacebookGoogle+YouTubePinterest

Social Icons

We’ve also recently launched our Social Icons feature on newer designs, which provides a simple way for you to easily link to your various Social Profiles from your store.  You can read more about Social Icons here.

Edge Caching and Content Distribution Networks

13 Nov

Where is my store hosted, and will it perform quickly for customers in country XYZ ?

Our support team get asked that question a lot, and the answer to the first part is that stores are hosted in the UK (at the moment)  The answer to the second part isn’t quite so simple, but the great news is that we’ve ensured that it will perform quickly for customers all over the world.  Lets take a look at how we’ve managed to achieve this.

Latency is a problem as old as the internet itself.  The internet has no international boundaries as far as your customers are concerned, so where do you choose to host your site ?  Thankfully, there are some pretty cool solutions to this problem, and at FreeWebstore we’re using a global Content Distribution Network (CDN) to ensure that your customers can access your content on a server hosted as near to them as possible.  Here’s a brief overview of how it works;

A client accesses your store using their browser, which grabs all of the elements necessary to render that page in their browser.  These elements are generally the following;

  1. HTML
  2. Images
  3. CSS
  4. Javascript

There can be more, but let’s focus on these for now.  Usually the way these things are setup, all of the above elements are on the same server, in the same country, in the same location.  This works fine if you’re near to that location, but what if you’re on the other side of the world ?  Surely that’s going to be slow, as the data has further to travel, with more routers and switches to pass through until it gets to it’s destination.  This is true, and the solution we’ve deployed is to cache all of the high bandwidth, static elements of your store really close to your customers, so that they only have to make those long round trips for small, dynamic elements.  In most cases, this means that elements 2, 3 and 4 of the list above are being grabbed from servers in the same country as the client.  In a lot of cases, they’ll even be in the same region.

So those big images, that CSS that doesn’t really change all that much, and all of those lovely JavaScript widgets you’ve installed on your store load in a snap.  All the browser has to do then is grab the relatively small chunks of HTML, that our systems have dynamically generated and put it all back together, resulting in a very snappy experience all round.

There is essentially a global network of servers that we use, in locations almost everywhere you can think of.  When the browser in a country requests a particular file, it’s automatically routed to it’s closest server location.  If that server doesn’t have the file yet, then it puts a request in back to our origin servers, gets the file from there, and keeps hold of it.  The next time somebody from a similar location requests the same file, from the same server, it already has it and gives it to them at lightning speed.  If you know how the cache or “Temporary Internet Files” in your browser works, it’s a bit like that … on a global scale !

Hang on a sec, you said it keeps it for a while.  What if I want to change that file ?

That’s a very good point.  One of the downsides of such a system, is that cached files, while providing great performance, can get out of date.  We do cache files for a long time so that we can focus on performance, but they will eventually expire, even if it takes a week, and the cache will grab the latest version from the origin.

Luckily, this is pretty easy to work around using versions in file names.  With an image, for example, if you want to change it, you just upload it with a different file name.  If you then update the links to the old image and change them to the new image name, the cache doesn’t know anything about this new file, so it will come back to the origin to get it and boom !  It’s updated, and cached for the next user who wants it.  As far as CSS and JavaScript goes, we take care of most of that for you, but it works in a similar fashion.  Whenever you make a tweak to your store via your FreeWebstore Control Panel, we will automatically re-version the file for you, so that the caches come back for the latest files and your brilliant new design change, widget or small tweak will be shown to your customers instantly.

DDoS Attack

17 Sep

As many of you may have noticed, we’ve recently been experiencing issues which have resulted in some downtime for some of our customers.  In the spirit of clarity and disclosure, this post is a brief analysis of what happened, what we did to try to fix the problem, and what you can do to help protect your stores from this kind of attack in future.  We’ll try not to get too technical, but that’s kind of inevitable with this sort of thing.

What Happened ?

Firstly, here’s what happened.  Some individual or entity decided to launch what’s called a Distributed Denial of Service (DDoS) attack against one of our IP addresses.  If you’re not sure what a DDoS attack is, the basic idea is to send a massive amount of traffic to an individual target, to put as much strain as possible on their equipment until it is unable to serve any legitimate requests to their site or service.  These are unfortunate incidents which are largely out of the target’s control.  All you can do is react to them.  We’ve experienced these before, but have usually been able to identify the intended target, drop the traffic aimed at that target temporarily, and you guys will have barely noticed that there was an issue, if at all.

This one was a little different though.  This particular type of attack is called a DNS Amplification Attack, where the attacker basically launches a large number of small requests at thousands of badly configured DNS servers, spoofing an IP address (in this case, ours) as the client that made the request.  The result is that the DNS servers send back a huge response to the supposed client, hence the “amplification” part.  The other thing about the attack was that it was aimed at an IP rather than a domain or host name, so we couldn’t filter out the traffic in any way.

As this attack start on the 11th September 2013, we believe it may have been part of a larger attack on financial institutions on the 9/11 anniversary.  We have no real way of knowing who it was targeted at though, it could have been Freewebstore or one of our customers.

How We Responded

To mitigate the attack, we first had to drop any traffic to the IP address that was getting attacked.  There was no way around this, we just couldn’t absorb it and keep things running.  We then started to move the services hosted on that IP to other addresses, and then point our DNS records over to that new address.  This managed to mitigate the attack for the majority of our customers, but there were some that had pointed their DNS records directly at the IP address that was getting attacked – we’ll talk about that shortly.

We were hoping that the attack would subside within a few hours, as they usually do, so when things died down we switched the traffic back on to the attacked IP.  This meant that all of the domains that were directly pointed at that IP started working again, and everybody is happy again right ?  If only things were that simple.  Unfortunately these attackers were very persistent, and more attacks followed in the next few days, so we had to drop the traffic to that IP again.

Unfortunately it’s impossible for us to determine which customers have their DNS configured to point straight at our IP, as a lot of it gets configured by the customers without the intervention of our support team.  As DNS can be quite confusing for non-techies, and the customers with their DNS configured this way should have been in the minority, we decided not to put out an alert to all customers as it would have just created confusion and possibly caused some customers to break working DNS records.  For the most part, we think this was the right call.

How Can I Protect Myself ?

The key to this is DNS.  There are several ways to point your domain name to your store.  The recommended way is to have your URL as http://www.mystorename.com which you configure by creating a DNS CNAME record for “www” and point that at “shop.freewebstore.org”.  The great thing about this is that we have control of the “shop.freewebstore.org” destination, so when the IP it was pointed at came under attack, we could change where that pointed to and all was well again.  The same applies for if you want http://store.mystorename.com or http://shop.mystorename.com, you just need to make sure that “store” or “shop” DNS record is a CNAME record pointed to “shop.freewebstore.org” and this will allow us to ensure that your store experiences the minimum amount of downtime during attacks such as these.

Now, it is desirable for some stores to use http://mystorename.com as their URL.  This is what the @ A record is for in our DNS guides, and that instruction was added due to popular demand.  The reason we didn’t initially include it in the instructions, effectively discouraging it, is because it locks those DNS records to a specific IP.  This @ record is called the Zone Apex or Naked Domain and the DNS “rules” specify that it has to be an A record, and an A record has to be an IP address.

While we understand it is desirable for this to work, we would not recommend that it is your default URL.  You should always ensure that your default URL is one with www’s or some other host name, and that it’s configured with a CNAME.  If your current URL for your store doesn’t use www’s, but you have a www host pointed with DNS, you can fix this by visiting the “Marketing > Domain Name” section of your Freewebstore Control Panel, and detaching, then re-attaching the domain.  This means that a minimal number of requests will fail if the IP changes, only for customers who have manually typed the URL in that way.

Another way to configure the Zone Apex is to use redirection or Web Forwarding in your DNS or Domain Provider’s Control Panel.  Now, we usually discourage using any kind of Web Forwarding, as sometimes it isn’t obvious whether the provider will use Stealth or Masking, which will break the basket system on your store.  If you use web forwarding with your domain, you’ll know if it uses stealth because whenever you change pages on your store, the URL in the address bar will not change at all.  If you’re sure that you can switch stealth off, then what you could do is set a web forwarding rule to forward any requests at http://mystorename.com to http://www.mystorename.com automatically.  This is what we essentially do when you point it at our IP, but at least if you configure it with your domain provider, you’re taking that IP out of the equation.  Just make sure that the URL changes to http://www.mystorename.com in the address bar when you visit the forwarded URL and you should be good to go.

If you would like assistance with configuring your DNS in this way, or would like for us check your settings, please get in touch with our Support Team via the Support section of your FreeWebstore Control Panel, or take a look at our Free DNS Configuration Service in the “Marketing > Domain Name” section.  Either way, our team will be more than happy to help.

What Happens Now ?

Right now, the attacks have died down in strength and longevity, but they are still ongoing.  We’re experimenting with switching the traffic back on, but may need to shut it off again at short notice.  If you’re still experiencing issues with your store, we’d encourage you to get in touch and let us help you to reconfigure things.  As always, we’ll take the opportunity to review our procedures and see if there’s anywhere we can improve.  Sometimes there are things that are just out of our control and can’t be prepared for, even Google has downtime.