A lot has been written about WordPress over the years with a lot of the literature describing how flexible it is as a CMS and how you can, with a little know-how and a little work, turn it into whatever you want it to be. Much of this flexibility comes from the ability to register custom post types, where you can create “post types” of any kind within the WordPress CMS. For example, if I were using WordPress to run a company website I could create a “staff” post type, where every entry that I create would contain custom fields for the name of the staff member, their picture, their e-mail, and links to social media profiles. The same thing goes for just about any other post type you could think of: image galleries, sliders, portfolios, etc.
And if there is some functionality that you need that happens to be lacking in the native installation of WordPress, chances are you’ll be able to find something close to what you need in one of the tens of thousands of plugins that exist out on the web. By combining these 2 features (along with a host of others) WordPress is an immensely flexible content management system (CMS) and this is likely one of the reasons it has gained such popularity since it’s inception.
In what follows, we’re going to combine custom post types and WordPress plugin development and create a plugin that registers a custom “portfolio” post type and wraps all of the functionality for both the front and the back end within it. So we’re going to need to to create fields for the name of the portfolio item, fields for featured images, and fields for links to where the project is showcased. After we get through everything, this should give you a good roadmap to create any post type/plugin that you like. In fact, a lot of plugins do little more than register post types inside of some generic WordPress plugin scaffolding code. Because there is so much you can do with custom post types, this is often all you need.
Read More »
PHP,
web development,
WordPress,
WordPress pluginsNow we’re going to talk a bit about security. I wouldn’t say this is really my area of expertise so take what follows with a bucket of salt, but I’ve recently been looking a bit deeper into REST API security; authenticating users, verifying requests… things of that nature. There are a number of different methods or protocols a developer can use to secure a REST API and all of them have strengths and weaknesses. One of the challenges that you face when handling REST API security is the fact that it is a principle of REST architecture to remain stateless where the server does not maintain any record of whether or not a user is authenticated/authorized (i.e. logged in via sessions). So in order to determine who is sending the request (and whether they are authorized to access a particular resource) on the server side, all of the information needed to handle this has to contained within the request coming from the client.
In other sections, some common methods of handling REST API authorization and authentication were discussed. Basic HTTP Authentication was discussed here and OAuth using Google as a provider was discussed here. In what follows, we’re going to look at another implementation that can also be a pretty good solution to securing REST APIs: HMAC. What is HMAC? No, it’s not a new burger that McDonalds is rolling out. HMAC stands for “hash-based message authentication code.” Like the name suggests, this means we’re going to be sending a hash (a jumble of letters and numbers) back and forth between the client and server and the system is going to be able to figure out (hopefully) if the request is coming from someone we trust or if it is coming from one of less than noble character.
There are some great articles that have been written on HMAC. Notably…
As is discussed in the articles above, the general idea behind HMAC is this… A client and a server know a secret key. This secret key is never sent over the wire. It is only used in combination with other pieces of data that *are* sent over the wire. That way, when we use our secret key and any other data transferred — say, a public key identifying the user (in the form of a header or a cookie), the message body, the current timestamp or anything else we want to use — and we run that data through an encryption algorithm such as SHA-1… we can create the same hash on both the client and the server! That’s how we know the request is valid. Only a client with the secret key would be able to reproduce the same hash it ends up sending to the server.
Read More »
API,
HMAC,
JavaScript,
OAuth,
PHP,
Slim FrameworkPosted by Ian on June 14, 2013 in
PHPWhen it comes to securing your REST API — authenticating and authorizing users — the situation is a bit interesting because the principle of an API being truly RESTful is that things remain stateless on the server side with each request. What that means is that the server isn’t really supposed to keep track of state in the form of sessions or anything else. To be truly RESTful all of the information that the web application needs to properly handle each request should be contained in the request itself.
If you wanted to, you could just cheat and handle everything using sessions. But according to the Internet, if you do this many kittens will die. So in the interest of at least trying to do things properly and saving the lives of millions of kittens, in the following bit we’re going to look at another one of the more common implementations for REST API authentication and authorization: Basic HTTP Authentication. We’ll be using the Slim Framework — a lightweight PHP REST API to demonstrate this, but the same principles apply if you’re using another framework or even another language.
To have user authentication within your app’s API and remain truly RESTful, it usually inevitably boils down to 2 choices: Basic HTTP Authentication and OAuth. OAuth was discussed previously in this article about using Google’s OAuth in order to access many different Google’s APIs. The developer docs at Twitter also have some good information on these two different forms of authentication.
Read More »
API,
OAuth,
PHP,
Slim Framework,
web developmentThere are lots of great resources out on the web for Backbone.js. You can find lots of different tutorials discussing Backbone.js Models, Backbone.js Collections and Backbone.js Views. Backbone.js is a favorite of the JavaScript community for building rich and well-organized client-side applications in JavaScript.
However, eventually there comes a point where all of this neat stuff you are doing on the client-side will have to be persisted by saving your data to a server somewhere. After you do this, you’ll of course need a way to retrieve it later. Otherwise, every time a user refreshes their browser or closes their browser and comes back to your page, anything that they’d done with your app previously will be gone.
If you’re doing any sort of retrieving and/or saving models from the database, you’ll likely be using the fetch, save, destroy, and/or sync methods (or similar implementations). As the documentation on these methods indicate, these methods send asynchronous GET, POST, PUT, and DELETE requests to a URL (usually the one specified in the urlRoot property on a model or a collection). What we need to do to hook Backbone up with a server so we can consume these requests is to use an API (Application Programming Interface). This API will provide us with server-sided code that can respond to the requests coming from Backbone. Which API we use doesn’t matter. Actually I think one of the great things about client sided JavaScript applications is that you can hook up to any server/API that you want. The important thing is that we know how to set up the API properly and write code to create the URLs Backbone is sending requests to and then handle those requests on the server side.
Read More »
API,
Backbone.js,
JavaScript,
Slim Framework,
web developmentOAuth has become an incredibly popular way to manage authentication and authorization for apps — mobile, desktop, and web. What is OAuth? Well according to the OAuth site OAuth is…
An open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications.
Well, to be honest that’s pretty general and might not exactly clear everything up if you’re new to OAuth. Don’t worry though. In what follows, we are going to show some really simple implementations in a couple of different languages that will hopefully help you get a better grasp on what OAuth is and whether or not it’s a good choice for you to use on your website or in your application.
Read More »
JavaScript,
OAuth,
PHP,
web development
