21 Dec

Mixing Basic Authentication and custom API Authentication

Today I ran into a problem that cost me about two hours, so I thought I want to share this if there is someone googling for the same problem.

The situation

I have a self built admin form that uses a RESTful api to retrieve and store data. The endpoint would be something like http://www.myserver.com/api/book and it’s listening to the obvious methods GET, POST, PUT, DELETE. The form was using the  jQuery.ajax() method to send requests.

This was developed locally and it worked without a problem, as it should.

The problem

When I deployed this to my test server at http://test.myserver.com/api/book something was not working right. Whenever I tried to save a new book, it would show this little window saying “Authentication Required”.

 

password_prompt

The test server is protected by a simple Basic .htaccess authentication. So this was something I’m used to. Unfortunately, entering the username and password didn’t work. It kept asking for the authentication until I clicked cancel. Then it would show that I got a 401 status response (Unauthorized)

Google to the rescue. The things I googled for were:

  • jquery ajax with credentials
  • jquery http post request basic authentication
  • jquery post keeps asking for credentials

Nobody seemed to have the same problem. Some posts on Stackoverflow said you could set an option like this:

That made the Authentication window disappear. So Basic Authentication  seemed to work now. What I found then in Chrome’s Network tab was that the POST request was now returning a response with a status of 403 (Forbidden).

The reason why it sent that, was because my API methods to delete, update or create things require authentication. This is sent as an access token as you can see in the code above.

The cause of the problem

When using basic authentication, the client has to send an HTTP header like this:

But my code was already setting a header for my own API’s authorization mechanism. And that header was set by this line.

Now we have located the problem. I am setting the Authentication header two times. Once for the API and once for the server’s basie http authentication.

The solution

According to some more googling and stackoverflow, it is not allowed to have two authentication headers in the same request. I found somebody else’s answer on StackOverflow that actually had the same problem: http://stackoverflow.com/a/32350368/1838774

Luckily my API was still in an early development phase and not actively used by other applications. This means that I could take the easy route and change my API’s authentication mechanism to look for a custom header instead. I went for a specific one that hopefully nobody else is using.

So my ajax code now looks like this.

 

21 Jan

WordPress, the good parts

Ever since I started using WordPress as something different than just a blogging platform, there was a clear upside and a downside to it.

What I love about WordPress

It’s amazingly easy to manage your content. Mainly for two reasons.

  1. Firstly, the backend has proven itself over and over again. It can be learned by anyone in a few hours. Which makes it almost unnecessary to explain to even inexperienced users.
  2. And secondly, custom post types and taxonomies are a concept that is a bit hard to grasp in the beginning. But it allows for a lot of flexibility. Additionally to Posts and Pages, WordPress can be used to manage a lot more things. Products? Events? Movies? … Pets? You name it.

What I hate like a lot less about WordPress

  1. The template system and querying data is a mess. There is this magical thing called “The Loop” that sets up something like a context for your template. Then you can get things like “the_content()” which automatically prints it out to the frontend. This probably makes the learning curve a little bit less steep for newcomers. But for people who are used to work with MVC patterns and like the separation of data, logic and content, it is a nightmare.
  2. There’s no real business logic layer. If you want to build application like features into your website you have the choice of adding it either to your template, or putting it in a plugin.
  3. You want to add automatic unit tests for the code that you wrote for your application? Sorry, we don’t do that here.

Separating one from the other

With the last releases, WordPress has been adding a feature to it’s core that has transformed web development in the last decade or so. It now finally has it’s own API. Using this piece of technology, you can finally get the data out of WordPress and display it in any application you want. A mobile app, another website, anything with access to the internet can now show what you are managing in side your WordPress website.

This allowed the people at Bocoup to build an amazing project. They had to add content management to an existing web application. But instead of trying to create their own, they looked to the old but reliable and proven WordPress backend. Using the API they were then able to manage their content inside WordPress, but display it on their custom built web application. They even created an npm package to call WordPress API from node applications under https://github.com/kadamwhite/wordpress-rest-api. And it’s as easy as this:

 

Conclusion

I think this is the biggest step forward that WordPress has made in the recent years. The code architecture might still not be to everyone’s taste. The template engine is still the same. But the API is breaking up that monolithic piece of software that it was. Adding a lot of flexibility to it and ultimately paving the way for a brighter future. I am really excited to see what other applications for it are going to come out in the future. And I would love to build an application that makes full use of this.

Here is the whole presentation K. Adam White gave at Wordcamp San Francisco: