Category Archives: Web Programming

A Simple Guide to Installing OpenCart Manually on BlueHost

I recently had to install the appropriately named open source shopping cart OpenCart on a BlueHost shared web host account and figured it would be good to record the basic steps here in case I need to do it again or if someone else comes along and needs to do the same thing.

Note: All of these actions were performed from a Windows machine.

Part 1: Get OpenCart to the Server

This is pretty straightforward. You need to download the zip file of the latest version of OpenCart from the official website.

You should then create a private key through the cpanel interface to make connecting to your server easier. This is done by visiting the SSH Access section and managing keys. After you create a new key, authorize it and download a ppk format version to use with Putty and WinSCP.

Using a program called WinSCP (that is Windows Secure Copy), you copy the zip file to your server’s file system using the SFTP protocol.
In the Advanced Menu under SSH – Authentication, you can choose your key file for authentication.

Once you have the OpenCart zip file copied over to the server, you will need to SSH into it. A common tool for this on Windows is Putty. However if you are a little computer savy, since Windows 10 you have the option of installing a Bash shell such as you would use in a Linux environment and directly running the ssh command from there.

For now, I will assume you are using Putty.

Run Putty and put your server URL or IP address into the hostname box. In the list of options on the left, expand SSH and select Auth. This will allow you to choose your key file for authentication just like WinSCP. I would recommend saving this session for future use.

If you created your key with a password, which you should do, you will need to enter your username (provided by your webhost) and your key password.
Now you are in.

Navigate to the folder with the zipped OpenCart file and unzip it. This is as simple as running `unzip nameofopencartfile.zip`.

This will create a folder called “upload” and you need to copy all of the files in that folder to your public_html folder or the subfolder related to your url in the public_html folder.
`copy -r upload/* public_html/url_folder/`

Part 2: Setup

Now that we have all of the files on the server. We need to prepare a couple of things before we finish the installation.

First, we need to setup a database and user for OpenCart. Back in your cpanel interface, go to the MySQL database setup and create a new database for this installation. Then create a new database user and give it full privileges on the new database.

In your browser, visit your website URL and you should now see an OpenCart install screen at step 1 with a license agreement.

Accept the license agreement and move to the next step. You may need to rename a couple of config files in the OpenCart directory on your server at this point from config-something.php to config.php, one in the main folder and one in the admin folder.

Next you will input the database information you previously created. And finally you will create an admin user that will be used to manage the site.

That is the basic setup for an OpenCart install.

There may be a popup warning when you first visit the admin page to move the storage folder to a different location outside of public_html. It seems like the site will create a new folder for you automatically, but you may have to manually remove the original folder.

Keep getting wiser, stronger, and better.

Token Based Authentication Versus Session: A Simple Explanation

Recently I was tasked with implementing a token based authentication structure for an API. When I initially looked it up, using tokens seemed almost identical to using sessions the way it was described in several articles. It took me quite a bit of reading before I finally understood what was going on, and I never did find a satisfactory explanation of how tokens differ from sessions. So today, I am going to attempt to clear up these murky waters a bit.

Sessions, Your Old Friend

If you have done web programming for at least a little while, you have probably come across sessions. Sessions are what the server holds on to, which allows the user to keep using the site without signing in every time their browser makes a request to the server.

Think of it as a business like a gym that has restricted access. If the gym used sessions, they might make you pay (sign in with password) when you show up each time and put your name on a access sheet. If you left and came back, they would ask for your name then look up and check (think database) whether you are allowed access or not.

The members (users) need to know their name (session id), the gym (server) needs to hold onto information about whether or not its members have access (session). For our purposes this represents the browser cookie with the session id and the session on the server.

Tokens, New Kid in Town

Although I had used tokens before, I had never implemented them into anything so I did not now exactly how they worked. (The particular kind of token that I am working with is a JSON Web Token but that is not actually important.) Like sessions, tokens also allow you to access the server without signing in every time. Unlike them, the server does not have them. Your user does.

Ok back to our gym example. Say that you want to give people 24 hour access to your gym and don’t want to have employees working the front desk at 4 AM to give people access. You could install a card reader at the door and then give out keycards that your gym members could swipe or hold up to it that allows them access. Once they pay (sign in with password), you give them a card (token) that they can come back with and you don’t have to look up on the sheet (database) whether or not they have access.

In this case the gym members (users) have all the information about whether or not they have access in the form of their cards (tokens), and the gym (server) simply validates the card when the member wants access. As a bonus, the local pool (a different website) has a card reader and a program that allows anybody who is a gym member to go swimming there. Members simply need to bring their cards (tokens). This is like OAuth/OAuth2 and signing in to websites using Google/Facebook/Twitter.

A Model For Understanding

Hopefully this gym membership model helped you understand the difference between token based authentication and session based authentication. If you want to learn more about specific implementation details, checkout some of the links below. And if you like what you read, sign up for my email list.