Just a quick post to announce that this blog is now using a new template. Clean, simple and elegant, it’s based on Cleanr but with several modifications I made. The previous template was too visually polluted and full of bugs, I’ve been thinking about changing it for quite a while. If you read the blog through its RSS feed, be sure to come visit and check out the new layout!

I also updated my post about VPN sharing on a Mac. A lot of common problems and great solutions were getting lost in the middle of the comments, so I grouped them in a Troubleshooting section.

Writing a WordPress plugin is quite simple. There are a few things you need to do to make it a sidebar widget (basically you just have to extend the WP_Widget class and implement a few functions) but nothing too complicated. I also took the opportunity to learn how to use AJAX inside a WP plugin, since I didn’t want to refresh the whole page when changing years in the calendar.

So there you go: today I’m publishing my first open source project, a WordPress plugin called Month Calendar. The source is available at GitHub, and the plugin is also published on WordPress Plugin Directory. It’s an important milestone to me, and it was a fun pet project. I learned a few things while making it, and now I feel ready to write a couple more complex plugins I’ve been planning. You can see the plugin working on the sidebar of this blog, if you’re curious.

Fun fact: the hardest part in the development process was to publish the plugin to the WordPress Directory, since I use Git and WP forces you to use a SVN repository. But after playing with Git’s SVN bridge for a while, I found an elegant solution. Since it’s not trivial as I thought it would be, I’ll write a blog post tomorrow detailing the whole process.

First, let me explain how my writing “routine” was planned: I would think about a topic and write a blog post in English first. Since I’m not perfectly fluent in English, it’s easier for me to translate something from English to Portuguese than the opposite. After the post was done, I’d then translate it to Portuguese and post both versions at the same time.

It seemed like a good plan, but it never worked. While writing, I kept thinking about how my text would look like after the translation, which made me go back and rewrite phrases all the time so they could look “right” in both languages. And even after all that effort, when I read my own translated posts in Portuguese, they felt wrong. I don’t know how to explain, but the thought process is different in each language, so a translation is never as good as a text originally written in Portuguese. Eventually, I simply lost interest in writing: just thinking about all the burden I had to go through for a simple blog post was enough for me to give up.

Now that we’re starting 2011 (New Year’s resolutions, you know the drill) I thought that trying to keep a schedule of one post per week could be a great challenge for me. But to achieve that, I’d have to change my methods somehow. So I decided to take a look at my blog statistics, and I noticed that 95% of all my traffic was going to the english version. I know that it has been several months since my last post, but while the Portuguese version had days with no traffic at all, the English version kept a steady number of visits every day (mostly thanks to google and my post about VPN sharing).

Long story short: the Portuguese version is gone. By trying to satisfy everyone, I ended up with a blog with no posts and a Portuguese version that never felt right (hence no visits). Not to mention that by keeping the Portuguese version I was going against my own belief: that if you’re a software developer, you should learn English, whether you like the language or not. I advocate that to all my developer friends here in Brazil, and yet I was providing a translation of my own posts to non-english speakers (I know it’s a controversial subject, but I’ll leave that for another post). So now this blog is English only, and hopefully it’ll actually be a blog again (with new posts, you know).

Sorry about the rant. Simply removing the Portuguese version without any explanation didn’t feel right.

(There’s a great analogy in this post about compromise and software development, but I’ll leave that as an exercise to you)

This is what OAuth does, it allows the you the User to grant access to your private resources on one site (which is called the Service Provider), to another site (called Consumer, not to be confused with you, the User). While OpenID is all about using a single identity to sign into many sites, OAuth is about giving access to your stuff without sharing your identity at all (or its secret parts).

Basically, OAuth is a way to authenticate to a webservice without having to store the user’s password, and in most cases without even having to ask the user for it. Twitter adopted OAuth for its API, and as of August 16th, it’ll be the only way to use the API. In this post I will explain how to use OAuth to authenticate with Twitter in Cocoa/Objective-C.

Choosing the authentication method

Twitter offers us three ways to authenticate using OAuth. The first, mostly for web applications, is to send a callback URL with your request, so after the user authorizes your application he gets redirected to the callback URL, and your app can proceed from that. The second, directed to desktop and mobile applications, is to use out-of-band authentication: after authorization, Twitter provides the user with a PIN code that he can type in your app to proceed. And the third one is to send the user’s login and password via xAuth. Although it may seem easier to use the last option, Twitter considers it the least desired way (as the user still has to type his password in your app), and to use it you need to directly ask Twitter for permission, sending details about your app and why you want to use it to api@twitter.com. In this guide we’ll use out-of-band/PIN code authentication, since this method doesn’t require you to set up a callback URL or ask Twitter for permission.

Getting started

First things first: if you haven’t done yet, go to Twitter Application Platform and register your app to use OAuth (yes, you can register a test application, no need for approval). After registering, write down the Consumer key and the Consumer secret for your app, as you’ll need them in a moment.

In this sample project, I’m using OAuthConsumer to handle OAuth requests. There are two versions available, this one I linked to was modified to handle Twitter’s PIN code. Be warned that there’s a bug on its code: in line 214 of OAMutableURLRequest.m, it should read:

if (token.verifier != nil && ![token.verifier isEqualToString:@""]) {

I will eventually submit this fix to the author, but right now you can just change it yourself or use the version bundled with my code sample that you can download at the end of this post. It took me hours to figure that out.

Update: thanks to Raphael Caixeta, I noticed I linked to the wrong version of OAuthConsumer (there are several different forks). He kindly created a ZIP file with the correct version, and you can download it here.

Twitter’s OAuth authentication (using a PIN code) is a three step process. First you ask for a Request Token, then you redirect the user to a webpage so he can authorize your app and get the PIN code, and finally you ask for an Access Token. After that you just have to use that Access Token to sign every request you make.

Request Token

Less talk, more code. Here we go:

OAConsumer *consumer = [[OAConsumer alloc] initWithKey:@"CONSUMER_KEY"
                                                secret:@"CONSUMER_SECRET"];
 
OADataFetcher *fetcher = [[OADataFetcher alloc] init];
 
NSURL *url = [NSURL URLWithString:@"https://api.twitter.com/oauth/request_token"];
 
OAMutableURLRequest *request = [[OAMutableURLRequest alloc] initWithURL:url
                                                               consumer:consumer
                                                                  token:nil
                                                                  realm:nil
                                                      signatureProvider:nil];
 
[request setHTTPMethod:@"POST"];
 
[fetcher fetchDataWithRequest:request 
                     delegate:self
            didFinishSelector:@selector(requestTokenTicket:didFinishWithData:)
              didFailSelector:@selector(requestTokenTicket:didFailWithError:)];

First, we create an OAConsumer object, using the consumer key and secret Twitter gave us (don’t forget to replace CONSUMER_KEY and CONSUMER_SECRET with the ones you got earlier). Then we create an OAMutableURLRequest using this consumer and Twitter’s Request Token URL. We set the request to use HTTP POST and finally use an OADataFetcher to submit it. This call uses two delegate methods for success and fail. Here’s the code for the success method:

- (void) requestTokenTicket:(OAServiceTicket *)ticket didFinishWithData:(NSData *)data
{
    if (ticket.didSucceed)
    {
        NSString *responseBody = [[NSString alloc] initWithData:data 
                                                       encoding:NSUTF8StringEncoding];
 
        accessToken = [[OAToken alloc] initWithHTTPResponseBody:responseBody];
 
        NSString *address = [NSString stringWithFormat:
                             @"https://api.twitter.com/oauth/authorize?oauth_token=%@",
                             accessToken.key];
 
        NSURL *url = [NSURL URLWithString:address];
        [[NSWorkspace sharedWorkspace] openURL:url];
    }
}

We get the response body and use the initWithHTTPResponseBody method from OAToken to create our Request Token. Then we use the token key and redirect the user to a Twitter page where he can authorize our app and get the PIN code. This is what the user will see:

After authorizing, Twitter will give the user a PIN code (7 digits) that he should write or copy. We’ll use this PIN code in the next step.

Access Token

To get the Access Token the code is pretty similar:

OAConsumer *consumer = [[OAConsumer alloc] initWithKey:@"CONSUMER_KEY"
                                                secret:@"CONSUMER_SECRET"];
 
OADataFetcher *fetcher = [[OADataFetcher alloc] init];
 
NSURL *url = [NSURL URLWithString:@"https://api.twitter.com/oauth/access_token"];
 
[accessToken setVerifier:@"PIN_CODE"];
 
OAMutableURLRequest *request = [[OAMutableURLRequest alloc] initWithURL:url
                                                               consumer:consumer
                                                                  token:accessToken
                                                                  realm:nil
                                                      signatureProvider:nil];
 
[request setHTTPMethod:@"POST"];
 
[fetcher fetchDataWithRequest:request 
                     delegate:self
            didFinishSelector:@selector(accessTokenTicket:didFinishWithData:)
              didFailSelector:@selector(accessTokenTicket:didFailWithError:)];

Now we use the PIN code as the verifier in our token. Then, in our request, we send the token we got earlier (now including the PIN code). Everything else is pretty much the same. Here’s the new success delegate method:

- (void) accessTokenTicket:(OAServiceTicket *)ticket didFinishWithData:(NSData *)data
{
    if (ticket.didSucceed)
    {
        NSString *responseBody = [[NSString alloc] initWithData:data 
                                                       encoding:NSUTF8StringEncoding];
 
        accessToken = [[OAToken alloc] initWithHTTPResponseBody:responseBody];
    }
}

Easy, right? We just get the response body and recreate our token using the new data. This new token is everything we need to sign our requests from now on. As long as you keep this token, you should never have to authorize your app again. The OAToken class even provides you with methods to store and retrieve this token, so you can keep it after closing your app and starting again.

Now you can go ahead and use any Twitter API method you want. Here’s an example to request the user’s home timeline:

OAConsumer *consumer = [[OAConsumer alloc] initWithKey:@"CONSUMER_KEY"
                                                secret:@"CONSUMER_SECRET"];
 
OADataFetcher *fetcher = [[OADataFetcher alloc] init];
 
NSURL *url = [NSURL URLWithString:@"http://api.twitter.com/1/statuses/home_timeline.xml"];
 
OAMutableURLRequest *request = [[OAMutableURLRequest alloc] initWithURL:url
                                                               consumer:consumer
                                                                  token:accessToken
                                                                  realm:nil
                                                      signatureProvider:nil];
 
[fetcher fetchDataWithRequest:request 
                     delegate:self
            didFinishSelector:@selector(apiTicket:didFinishWithData:)
              didFailSelector:@selector(apiTicket:didFailWithError:)];

Sample Project

As you probably noticed, this post contains only code directly related to what I’m trying to explain. If you want the whole thing (including my modified OAuthConsumer) I’ve created a sample project including all the methods I used here and a very basic interface with some buttons you can use to call each method (and fields for consumer key, consumer secret and the PIN code).

The sample project requires Mac OS X 10.5 (Leopard).

First of all, sorry for the lack of posts, I’ve been kinda busy lately. I finally updated my development machine to Snow Leopard (I was on Leopard 10.5.7) and I took the opportunity to sort and organize all my backups, documents and stuff. I’m still not really done with my backup procedures, but at least I’m covered in case of a crash (after the capacitors incident, I decided to take my backups more seriously).

Anyway, one of the things I always wanted (and finally had time) to do was to setup my own OpenVPN server. In case you don’t know, VPN stands for “Virtual Private Network”, and it’s a way to have your own secure network no matter where you are. Whenever you’re at a cafe or an hotel and want to make sure no one can take a peek on what you’re doing (yes, it’s pretty easy to do that) you need a VPN. Having a VPN server can also help you circumvent geoblocking, if that’s what you’re up to.

I decided to write this article to share the experience I had configuring my own VPN, specially when I wanted to share the connection with other devices in my network. If that’s what you want to do, read on and I’ll try to explain what I did and how I did it.

The Server

If you want to have your own VPN, the first thing you need is an OpenVPN server. You have two options: using your own server or using an OpenVPN service provider. The whole process of setting up the server is out of the scope of this article, but if you have a Linux server you can find some great guides on Linode’s Library. By the way, Linode is a great VPS provider (I highly recommend it – this server is located there), so if you want to have your own server there you can use my referral code.

Another option is to use a VPN service provider. There are both free and paid VPN services, and if all you want is to have a VPN without bothering with server setup, this is the easiest way. Here’s a list of some VPN service providers (prices range from $0 to $15 per month, depending on the speed/bandwidth you need).

The Client

Okay, so you have your server, now you need a client to connect to your VPN. I’ll help you setup Tunnelblick on Mac OS X. Since I never used any VPN client on Windows I can’t help you there, but if you’re stuck on Windows I recommend using OpenVPN GUI.

The first time you open Tunnelblick after installing it will ask for your password. It’s ok, it needs your password to secure your keys and configuration files (and that’s very important, since anyone with access to your keys can connect to your VPN server). After that, it will ask if you want to create a sample configuration file. I suppose you already have your config file and keys (that’s part of the server setup) so let’s just ask for it to open the configuration folder, so we can put our files there. If you don’t have a config file from your server, you can let Tunnelblick create one for you. Close the program after that.

Copy your configuration and certificates to the configuration folder. Usually you’ll need to copy 4 files: client.conf, ca.crt, <yourclient>.crt and <yourclient>.key. Rename client.conf to the name you want to use to identify your server (i.e. MyServer.conf), open it in your favorite text editor and check if it already has at least the following lines (leave the rest untouched):

remote <your server address> <your server port>
ca ca.crt
cert <yourclient>.crt
key <yourclient>.key

Save your files and launch Tunnelblick again. It will add a black tunnel icon to your menu bar. That’s where it’ll sit when it’s running, so you can quickly connect to your OpenVPN server whenever you want to. If you click on its icon, you’ll see an option to connect to your server, with the same name you used in your config file. But before you connect, let’s check your current external IP address first: enter this site, look for your IP address and write it down.

Ready to connect? Click on the tunnel icon and select Connect ‘YourServer’. It’ll try to connect to your VPN server (if it asks for your password again there’s nothing wrong, it’s securing the files you changed. It won’t ask every time). The menu icon will animate while it’s connecting, and if it connected successfully the icon will change to an open tunnel. Click on the menu icon again and the first line should read Tunnelblick: 1 connection active. Go back to this site and check your IP again. If it changed then congratulations, you’re already using your VPN connection and all your traffic is going through a secure connection.

If something went wrong and your VPN connection is not working, open Tunnelblick menu again and select Details. It will show you a very detailed log file, so you can check for errors and warnings there. And if you are connected to the VPN server but your IP address didn’t change, the problem is probably in the server: it needs to be configured to forward all VPN traffic and to be the default gateway on the client. All these options are covered in the Linode’s guide I mentioned earlier. Sure, if you’re using a VPN service provider you can also contact their support.

Sharing Your VPN Connection

So now you are connected to your server and your connection is securely being routed thought the VPN (go ahead and try Hulu, I’ll wait. I know you want to). But what if you want to use the same VPN in other devices in your network? Sure you can configure Tunnelblick in more than one Mac, but some devices like an iPhone or a XBOX 360 don’t have OpenVPN clients. What can you do about that?

The solution I found is simple: you can share the VPN connection in your Mac and then use your Mac as a gateway for your other devices. The problem is that the OSX’s native Internet Sharing doesn’t seem to play nice with OpenVPN. I really tried to use it in every way possible, but it didn’t work. So I spent some time researching how Internet Sharing works under the hood and I found a solution that is not so simple, but once configured works perfectly.

Open your favorite text editor and create a new file. Paste the following lines on it:

#!/bin/sh
 
natd -interface tun0
ipfw -f flush
ipfw add divert natd ip from any to any via tun0
ipfw add pass all from any to any
sysctl -w net.inet.ip.forwarding=1

Save it with a name like natvpn.sh. Right click the file in Finder, select Get Info and under Permissions mark Execute. Close the Get Info window.

Now what the hell was that all about? Let me break it down to you. We’re using some native commands to allow your Mac to act like a gateway and forward all the packets to the VPN connection. This is very similar to what OSX’s Internet Sharing does for you. The name tun0 is the default interface name Tunnelblick will use for your VPN connection, and you can confirm that by opening Terminal and typing ifconfig while connected to your VPN.

Open Terminal. If you’re not connected to your VPN, connect now. Go to the directory you saved your file (if you saved it in your home folder, you’re already there) and type:

sudo ./natvpn.sh

You’ll need to replace natvpn.sh with the name you saved your file. It’ll ask for your password, type it and you’ll see something similar to this:

Flushed all rules.
00100 divert 8668 ip from any to any via tun0
00200 allow ip from any to any
net.inet.ip.forwarding: 0 -> 1

It worked: your Mac is already a gateway! Now all you have to do is go to the device you want to use with the VPN connection and, under its network settings, change the default gateway to your Mac’s IP address. In most devices, to change the default gateway you’ll also need to configure it to use Static IP (my iPhone needed, for example). Just copy the same IP address, subnet mask and DNS server it’s currently using and change only the gateway to your Mac’s IP address. Oh, and if you don’t know your Mac’s IP address go to Preferences, open Network and select your network connection. In the right panel it’ll show your IP address under Status.

Test your device by going to the same site again and it should show you the server’s IP address. Congratulations, enjoy your new secure VPN connection!

Conclusion

As you can see, setting up a VPN connection is pretty simple. Sharing it might be a little more complicated, but now that it’s configured all you have to do is open Terminal and type sudo ./natvpn.sh while connected to the VPN everytime you want to share it. It’s not automatic, but it works pretty well. And of course, if all you want is to use the VPN on your Mac, then you only have to connect using Tunnelblick and you’re done.

This guide assumes you have at least a little experience using the terminal. If you don’t, you may find yourself a little lost in some parts, especially if you want to share your VPN connection. If that’s the case, feel free to leave a comment below and I promise I’ll try to help you!

Troubleshooting

The method I described above doesn’t work together with OSX Internet Sharing. So check if you have it enabled (under Preferences, go to Sharing) and disable it.

If you can’t find the option in Finder to make the script executable, you can also do it in Terminal. Just type chmod +x natvpn.sh.

Be sure to save the script in TextEdit (or your preferred editor) as a plain text file, not as rich text. You can check this by typing cat natvpn.sh in Terminal. If you see garbage instead of the script, the file was saved as rich text.

If you get the error “Address already in use” from natd when running the script, it’s because you already have natd running, and only one instance can be active. Check if you didn’t leave OSX Internet Sharing enabled (you have to disable it) or try to run the following code in the Terminal to see what app is running it:

ps aux | grep natd

When configuring your client device (the one which will be using your Mac’s connection) set the DNS servers to external addresses. You can use, for example, Google DNS (IPs 8.8.8.8 and 8.8.4.4) (thanks Damian).

If you’re using a PPTP VPN interface (OSX VPN Client) instead of OpenVPN you need to do a few additional steps. First, add a line IPFORWARDING=-YES- in the file /etc/hostconfig, then change the natd -interface tun0 line in the script with (thanks Zantiss):

natd -same_ports -use_sockets -unregistered_only -dynamic -interface ppp0 -clamp_mss

There are some reports of speed issues when using a PPTP VPN, but I don’t have access to a PPTP VPN so I can’t confirm it.

If your VPN server doesn’t register itself as your default gateway, you can override this in your client configuration file. Just add the line redirect-gateway def1 to the file (thanks Jon).

If you want to turn VPN sharing off, create another script called natvpnoff.sh (or something similar) and put the following lines inside it (thanks Yohann):

#!/bin/sh
killall natd
ipfw -f flush
sysctl -w net.inet.ip.forwarding=0

After saving, run the script with sudo natvpnoff.sh. You could also reboot your machine to disable VPN sharing, since none of the changes in the script is permanent.

Yesterday I was working when my computer froze. “Well, sometimes it happens”, I thought, so I tried rebooting it. It appeared to start normally, then nothing. Mac OS just froze at the login screen, and trying to boot Windows gave me a BSOD. I managed to boot OSX in safe mode and everything appeared to be working: my hard drives were OK, apps were running, no errors. So I turned off the computer and tried to turn it on again 10 minutes later. This is what I saw:

Well, maybe my monitor is out of tune.

“So it must be something with the video card”, I thought. I opened my computer case, popped the video card out, and started inspecting it. Soon enough I found the culprit:

Yep. Three beautifully blown up capacitors.

At first I panicked. This is my work computer, it had to be working again ASAP. I started searching online for a new video card, but since I live in a (kinda) small city, video cards are not only really expensive here, they’re also hard to find. But I had no option: I needed it working, so I was convinced to get a new video card first thing in the morning on the next day.

A couple of minutes later I tried to google “blown up capacitor” just to see what kind of results I’d get, and I noticed this is quite common. These capacitors are pretty bad quality and are prone to explode, specially in the video card I have (it’s a XFX Geforce 8600GT): the ones that blew up sit right in front of the cooler’s air escape, so the cooler is pretty much blowing hot air on them all the time (what a great design, huh?)

I found some people saying that they’re pretty easy (and cheap) to replace, so I decided to give it a try. What the heck, the card was already dead anyway. So I woke up this morning, went to a local electronics store and bought three capacitors to replace them. I tried to do it myself, but my soldering iron was not good enough for the job (I could fry the card), so I ended up going to one of these places where they fix TVs and stuff and asked them to replace the capacitors for me. After a few minutes they gave me my card back with the new capacitors:

Now we’re talking.

Guess what? I put the card back into the computer and everything is working again! I could not believe it: I did decide to try replacing the capacitors, but I was pretty much expecting nothing, already prepared to spend more than $250 in a new video card. So I ran a few tests and it all seemed to be ok. I worked all day on the computer and it’s perfect, as if nothing happened.

Total cost to repair the video card: about $3 for the capacitors, and about $2 for the guy who soldered them for me. And, of course, the satisfaction of knowing that what seemed like a stupid idea did actually work.

Now just try to imagine how many video cards that could be fixed with five bucks and a few minutes of work end up in the garbage…

Back? Great. I created this blog (and by “created” I mean the subdomain and the template) in August 2009, but I never really started it until now. Usually I’m just too critical about myself and I always think that everything I write is not “good enough” to publish. But then I realized that I’ll never get to a point where I consider my posts to be “good enough” if I don’t start writing. So I decided to start posting anyway, hoping that I’ll get better with time.

My plan is to start with at least one post a week. If I manage to do that for a while, then I can start writing more. It has been almost a year since I started my company and I really regret not documenting all the ups and downs I’ve been through. Well, there’s nothing I can do about the past, but I can start writing right now. And that’s exactly what I’m doing!