I spend the weekend of April 4-6 at New England GiveCamp, a weekend hackathon that pairs tech and design people with charities in the Boston and New England region.
This year, I worked for Generations Inc., a Boston-based charity that pairs senior citizens as literacy tutors for children.
The process they used for accepting volunteer applications was time- and labor-intensive. Basically, they used the Job Manager WordPress plugin to accept applications, which went into their WordPress install as a custom post type.
Then, a staff member would have to re-enter all that information into Salesforce, which they use to track volunteers, clients and related assignments.
Since Salesforce is the endpoint for managing all of Generations Inc.’s relationships, they wanted a way to take online applications and put them directly into Salesforce. So that was my project for the weekend.
Part 3 in a series on working with WordPress XML-RPC in PHP.
To being coding our PHP-based solution for working with the WordPress XML-RPC API, we first need to create models for each of the kinds of data we’re going to leverage. The logical place to begin doing that is with posts, since most content in a typical WordPress install are posts.
A model in this context basically means creating a class. (If you’re not familiar with classes, see this primer.)
The class will bring together not only the post fields that we can manipulate through XML-RPC — some of which are complex — but also the methods (aka functions) that will allow us to easily modify the data in those post fields. This will include methods that prepare our data for sending to XML-RPC, and interpret the responses we get back from the API.
That’s what makes a data model: The data itself, or properties / post fields, and the means to manipulate that data via methods / functions.
Why bother with a model?
Part 2 in a series on WordPress XML-RPC
A significant amount of hue and cry in the WordPress world surrounds security, and not without some cause; a poorly implemented install is susceptible to attack, especially in earlier versions.
Such protests are amplified when it comes to XML-RPC, the SOAP service used by WordPress to allow outside access for content management.
This is largely nonsense. The fact that 9 out of 10 WordPress installs have a well-known admin url (/wp-admin), and probably two-thirds of such installs have a administrator login with the user name “admin”, is a far greater vulnerability than the presence of an XML-RPC server at a known URL.
Because hey, at least XML-RPC limits what can be done to a WordPress install, and structures how you interact with it. It’s the difference between letting your crazy uncle live in the basement, versus giving him the keys to the house: He might burn the place down, either way, but at least you know he won’t steal the silver or make a mess of the living room.
In short, making XML-RPC secure involves the same steps as making WordPress secure, and if you properly secure your WordPress site, you need not fear what XML-RPC might do.
In three previous posts, I discussed creating a single-use form nonce, a multiple-use form nonce and a time-limited form nonce.
In this post, I’ll describe creating a single-use, time-limited form nonce — that is, a token, unique to each form iteration, which can only be used one time. That will ensure not only that the form was created on our server, but also that it cannot be used a second time, and that the form was submitted in a timely fashion.
I’ll build upon my previous single-use nonce methodology, by adding an additional column to my MySQL table — which stores the time at which the nonce was created — and process the form by comparing that time to the time of the form’s submission.
Why might I want to do this? A clear case would be in ordering a commodity which is scarce, such as a concert ticket. I don’t want to allow the end user to hold a lock on that ticket forever — if he doesn’t order it quickly, I want to make it available to someone else who wants it. And I also don’t want to double-charge him if, for some reason, the form is submitted twice — such as with a refresh of the ordering page.
Previously I blogged on creating a single-use form nonce token and creating a multi-use nonce in PHP.
Advancing the subject, let’s now look at limiting the timeframe in which a form can be processed through the use of a nonce, or a one-time, unique key that ensures we generated the form on our server.
There are several reasons why you might want to limit the time available to fill out a form; for example, you have limited supplies of something you are selling and don’t want a single customer tying up that stock while he dithers on a purchase (witness TicketMaster); or you may have a results set that changes all the time, so you want the visitor to act quickly, before the records he requests get updated behind the scenes.
To accomplish our time limit, we’ll build on the multi-use form nonce example I previously provided, only this time we’ll change up our pattern a little. We’ll prepend and append some random characters to a Unix timestamp, then retrieve that timestamp and see if the form’s submission time falls within the time limit we’ve set.
In a future post, I’ll describe storing this timestamp in a database, in order to work with our previous, single-use token example.