I had a long weekend to myself this week and thought that I should use it wisely. Probably preparing for my new job, but nope, I decided to finally recode iTunesTweet. For those readers who have no idea what I’m talking about, check this post I made.
The biggest improvement to the re-write is the oAuth implementation, which of course is the subject of this post. Why? Well because I wanted to discuss the different ways that the technology can be used (in regards to connecting with Twitter) and why I chose one over the other.
I also discussed this topic at Stack Overflow and asked for professional opinions on the subject. They completely agreed with the methods I shall now talk about. If you want to see the topic, click here.
What is oAuth?
The first question to such a post is; what is oAuth? What is this awesome new technology that websites such as Twitter, LinkedIn and Google are using?
oAuth stands for Open Authorization. It’s an open standard which allows users to share data between their system and a server without having to enter their username or password to the 3rd party website. This means that no personal data is stored by the website/application, only tokens which allow the site to contact the service for basic details.
These tokens work only for the user they’re generated by and the specific services and requested resources.
Why does iTunesTweet use oAuth?
In Version 1, iTunesTweet stored both username and password in the registry, so that it could call Twitter’s REST API to update status, follow iTunesTweet et cetera. Although encrypted, it’s still open to vulnerabilities. And that’s something we don’t want, right!
iTunesTweet V2 now uses oAuth to secure data being sent and received between itself and Twitter.
If you are so concerned about users security, why did it take so long?
A very good question if I may so myself! The problem with oAuth is that it uses some extremely complex data processes, which is irritably hard to implement into a scripting language such as that, of which iTunesTweet is created in.
At the same time of wanting to keep users secure, I did not want to provide them with a crap implementation of something which should be securing their data. I’m not going to release something I know comes with a bogus claim.
Why not stick with basic REST API calls?
Not only do they pose as a security threat but Twitter is shutting down the API too. The announcement can be read here. For those awaiting the day, check out this awesome Twitter API Countdown death clock.
So you’re using the application interface for Twitter’s oAuth security?
Simple answer? No. Extremely boring and possibly long answer?
As I said previously, it is irritably hard to implement oAuth into the language I’m using. This alone would give a lot of developers the notion to swap to a capable language, heck, I even started to myself using C#.
The reason that I decided to leave the new implementation behind and go back to my original base was that I realized that iTunesTweet is literally an addon to iTunes. Although not an official one, it does access iTunes API and as such, adds functionality that is missing. After realizing this, I wanted to keep iTunesTweet small, like addons should be. Although AutoIt is relatively slow compared to C# for example, it also gives me a much better base set of functions which make it easier to hook into the API. Not only that, but with some special compilation rules and packers I can keep the size down, even with the 6 (at current count) resources it includes.
So you used the web access for a desktop application? Correct. If you’re asking why or not, you’re going to get the answer. It’s simply because the web authorization method is much easier to implement. Thanks to the creators of EpiTwitter/EpioAuth, I’m able to host the web files and make secure connections to them between my application and the files.
The application interface requires us to store a number and post it back and do this and that and reverse and encode and blah blah blah. It’s long and difficult. Why beat around the bush? I can simply send the users secure tokens to the web application that I host, and Twitter does the rest. Even if the data is hacked, they can’t do anything with it, since the files I host do all the formatting work anyway.
So you’re using a web interface for a desktop application?
Exactly! A lot of applications do it too, why should iTunesTweet be any different?
How do you get the users to authorize the application then?
Simple, I provide a good (and I use that term lightly since it’s going to be changed for the final version) little interface in the form of an IE window (without the Chrome etc) and ask them to click a link. The link takes them to the Twitter page, they enter their details, it re-directs back to my site and I ask them to close the window.
Do you collect any data during this process?
Yes, a couple of things are collected, which later make iTunesTweet run:
- Twitter oAuth token
- oAuth token from username
- oAuth secret token from password
- Twitter username (this is deleted as soon as the iTunesTweet account is followed)
- Twitter picture – this is only during beta, it was originally going to be used for updating the users status themselves
And that’s it. Nothing harmful, usernames are publically available anyway, and since it’s deleted within 2 minutes, it causes no harm.
So there.
I proved absolutely nothing except that in some circumstances it is better to use tools available to you because it makes your job easier and provides the same functionality just in a different model. Perhaps we’ll see some other desktop applications which use web resources like iTunesTweet does?
Continue Reading
Recent Comments