How to automatically redirect the WordPress login and admin pages from HTTP to HTTPS

Posted on November 16th, 2011 webmaster No comments          Print

I always get worried every time I have to login to a website over a non-SSL enabled connection.  When my blog didn’t support SSL (before I migrated from a shared host to my own VPS) and I had to work on it at a coffee shop, I would sometimes change my password when I get home, which of course is still not that secure as my blog is hosted outside my local network which I have no control over.

A computer with a network card (wired or wireless) that supports promiscuous mode can easily sniff out packets coming in and out of other devices on the same local network the computer belongs to using tools like Wireshark.  So if you’re using a public wireless access point, for example, other computers connected to that same wireless access point could see the data you’re sending and receiving over the network.

Even if the login form hashes the password first (using one-way hashing algorithms such as MD5 or SHA-1), most users probably have passwords that aren’t that strong/complex, allowing the attacker to brute-force the hashed passwords in a reasonable amount of time.  Advancement in GPU technology and tools like IGHashGPU make cracking passwords much, much faster.

There are also tools like Firesheep for Firefox which allows attackers to impersonate you by hijacking your session cookies since its content can be retrieved in plain text over an unencrypted connection.

Automatically redirecting all WordPress pages that send out authentication-related information from HTTP to HTTPS could prevent these types of attacks.

If you have full control over your WordPress installation, this is very easy to do.  Just edit the wp-config.php file in the root directory of your WordPress installation and add the highlighted line below before /* That’s all, stop editing! Happy blogging. */.

define('WP_DEBUG', false);

/**
* Force SSL on login and admin pages.
*/
define('FORCE_SSL_ADMIN', true);

/* That's all, stop editing! Happy blogging. */

/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
        define('ABSPATH', dirname(__FILE__) . '/');

More information can be found here: http://codex.wordpress.org/Administration_Over_SSL

If you don’t have full control over your WordPress installation (such as in a shared hosting environment), you can give this plugin a try: http://wordpress.org/extend/plugins/wordpress-https/

Migrating WordPress from a shared hosting environment to a virtual private server

Posted on November 9th, 2011 webmaster 3 comments          Print

I was migrating this WordPress blog early this morning from Bluehost to a dedicated Rackspace Cloud Server that I’m already using for a web application I’m writing.  It was almost painless! Just ran into a few minor post-migration issues.

The reason I’m migrating is mainly because I want more control, like being able to use my own self-signed SSL certificate without paying extra, for example.  I figured since I’m getting very low traffic it really wouldn’t cost me anything extra to host it on Rackspace.

For example, according to Bluehost, my monthly bandwidth transfer is roughly 2.3GB.  I’m not sure if that’s for both inbound and outbound.  Either way, Rackspace only charges 18 cents/GB for outbound bandwidth (inbound is free).  So even if I’m using 3GB a month, it’s only an extra 54 cents to my monthly cost.  Rackspace’s connection is also way faster.

The migration steps are pretty straighforward, basically:

1. Install PHP, MySQL, Apache.
2. Install WordPress.
3. Restore the database.
4. Copy over your themes, uploads, plugins, and other directories that a plugin might be using (in my case I had an extra “gallery” directory for the NextGEN Gallery plugin that I’m using to store my pictures).
5. Restart Apache.

Here are the issues I ran into after migration and their solutions:

Read the rest of this entry »

GWT, Django, and JSON (with padding)

Posted on August 8th, 2011 webmaster No comments          Print

A couple of months ago I was working on a project where I needed to retrieve data in JSON format from a web service written in Python (using the Django web framework) under GWT.  The data is then loaded into GXT/Ext GWT grids and charts.

After looking at a GXT example of loading JSON data to a grid, I thought this would be pretty straightforward, but of course I was wrong.  Since the Django app is on a different server and domain/subdomain, I learned something called “same origin policy“, preventing our two applications to communicate with each other.

Fortunately, there’s an easy workaround to this using “JSON with padding” or JSONP.  Here’s one way to get this working:

GWT side:

1.  The JsonpRequestBuilder object has been added in GWT 2.0 making these types of cross site requests easier to implement.  Here’s a very well written post showing how to do this (yes, I’m lazy and he obviously knows a lot more about these than I do ).

Now, when you make a request to the web service on the Django side, it will automatically append the callback function in the request and the request may look something like this:

GET /get_gpu_stats/?callback=__gwt__jsonp__.I18.onSuccess HTTP/1.1

Django side:

1.  In your Django view, one way to handle this is to inspect the request and see if there’s a parameter called “callback” and change the response so it looks like a function (this is the “padding” part) instead of a regular JSON response.  You can do something like this (forgot where I found this example from):

def get_gpu_stats(request):
    .
    .
    .
    gpu_stats = {'gpu_stats': data}
    response = simplejson.dumps(gpu_stats)

    # Return as JSONP if the callback parameter is specified.
    callback = request.GET.get('callback')
    if callback:
        response = '%s(%s)' % (callback, response)
    return HttpResponse(response, mimetype='application/json')

Yup, that’s it, they should now be able to exchange data!