All posts by Stephen Darlington

The ‘D’ in ‘DVCS’

Last week, GitHub was the victim of a days long denial of service attack that meant that it wasn’t available reliably despite the hard work of their team.

What surprised me was the number of people on Twitter complaining that they couldn’t work. I was surprised because one of the key things about Git (the tool rather than the website) is that it is distributed, that is there is no centralised server in the way that there is with, say, Subversion. Clearly there are things you can’t do without GitHub – most obviously downloading new repositories – but almost everything else can be done peer-to-peer. The rest of this post explains how.

First, a couple of disclaimers. I’m not a Git expert and I’m not a server admin. There certainly are other ways of doing this. Some may even be more secure or easier in your environment. What I like about this approach is that it works on pretty much any machine that has git installed.

Step one: set up a Git server.

“Woah, now,” you’re thinking, “I don’t have all day!”

Turns out it’s just two commands:

touch > .git/git-daemon-export-ok
git daemon

(Assuming you’re in the folder that’s at the root of the repository you want to export.)

Then on your other PC you can enter the following command to pull or push:

git pull git://othermachine/Users/stephend/temp/

You could even clone a repo to a local server, run a git server on it and use it as a temporary ’central’ repository.

If there’s a downside it’s that it’s difficult to recommend pushing to a repository using this method because there’s no authentication. However, as a quick and dirty way of pulling commits between any two machines with git installed it’s pretty reliable.

(If you know git you’re probably thinking “Why not ssh?” The short version is that it’s often locked down in corporate machines and is usually not available on Windows machines. But if you can use it you probably should.)

Moving an app from Paid to Free

I’ve seen quite a few people saying that it isn’t possible to move an iOS app from paid to being free with an in-app purchase to unlock the full functionality. Fortunately they’re wrong.

“Traditionally” I would have had to remove version one from sale and offer a completely new app, which would have meant that existing users would have to pay again to get the same functionality. Or I’d have to support two apps. Or I’d keep the same app in the store and all existing users would get downgraded to the free version. None of these solutions seemed fair to existing users.

What I wanted was for people who had bought version one to get the full, unlocked version and for new users to be promoted for the paid upgrade.

Since iOS 7 came out in 2013 that it entirely possible. I’ll explain how it’s done here. This isn’t just some theoretical “I’ve seen the documentation” claim – I’ve done it with one of my own apps, Rootn Tootn.

The really short answer: take a look at the session 308 video from WWDC 2013. That’s the only information from Apple that explains how to do it. They have documented the API calls that are required but the actual process is left as an exercise for the interested student. And there are quite a few steps if you want to do it properly.

Firstly you need to get the app receipt. Before iOS 7 this only made sense for IAP but now they are available for all purchases and come in the same format as receipts from the Mac App Store.

Receipts have a number of useful features. In the past they have been used to validate purchase, and they can still be used for this. What’s interesting with the new receipts is that they include both the original purchase and the version number of that original purchase. This means that we can decide whether a user gets the paid functionally by looking for either an in app purchase or a purchase date before a particular time or, more likely, before a particular version.

When you download an app you should get a receipt automatically but you can also use the SKReceiptRefreshRequest class to force one to be generated. (This is also useful during development where, obviously, there is no receipt.)

Once the refresh has completed, you use [NSBundle appStoreReceiptURL:] to access the receipt.

Once you have the receipt the bad news starts.

It’s not in a user friendly format. And Apple do not provide any APIs to read it. Check out Apple’s documentation:

The outermost portion (labeled Receipt in the figure) is a PKCS #7 container, as defined by RFC 2315, with its payload encoded using ASN.1 (Abstract Syntax Notation One), as defined by ITU-T X.690. The payload is composed of a set of receipt attributes. Each receipt attribute contains a type, a version, and a value.

If security is important to you, you should probably write your own code to do this. ASN.1 is a standard format and it’s not that hard.

There are apps that generate the validation code, such as

Tighten Pro and Receigen. I can’t vouch for either of them but the reviews seems positive.

There are also Open Source projects that do the same thing. I’ve used RMStore; there’s also VerifyStoreReceiptiOS. The main disadvantage of these is that, as standard, open code it makes it easier for crackers to reverse engineer how you remember that a purchase has been made.

And there you have it. It is possible. It’s just a lot harder than you might imagine. Remember this when someone tells you that it can’t be done.

Double Trouble

One of the great things about WordPress is the community and the number of great plugins that can do amazing things with little effort.

But all that code, as any good developer will tell you, is a liability. How do you pick a plugin that not only meets your requirements now, but will both continue to do so? WordPress advances. APIs change. Plugins need love too.

Many moons ago I settled upon Flickr Gallery, a plugin that allows you to import Flickr images just by adding a short-code to posts. I thought there was value in keeping all my public photos in one place and, at that time, WordPress had poor media management facilities. The plugin seemed popular and well supported.

Flash forward to 2015 and, well, it doesn’t work. It hasn’t been updated for nearly five years and where I should see pictures I only see blanks.

But I’m a developer. How hard can it be to fix?

Groan! Have I ever said how much I hate web development?

Anyway… two hours later I find that there are not one but two problems. I find this after fixing the first problem in a server running on my local machine but find that it still doesn’t work here.

The first problem is that Flickr now requires SSL access to its API. In code terms, open phpFlickr.php and change the following lines:

 var $rest_endpoint = 'http://api.flickr.com/services/rest/';
 var $upload_endpoint = 'http://api.flickr.com/services/upload/';
 var $replace_endpoint = 'http://api.flickr.com/services/replace/';

To:

 var $rest_endpoint = 'https://api.flickr.com/services/rest/';
 var $upload_endpoint = 'https://api.flickr.com/services/upload/';
 var $replace_endpoint = 'https://api.flickr.com/services/replace/';

I found the cause of the second problem when I realised that none of the flickr code was getting called. It turns out that I have the Jetpack plugin and that also uses the “flickr” shortcode, though the syntax for using it is slightly different.

(I find it odd that there’s no error or warning flagging the conflict. This took far longer to track down than it needed to.)

I tried disabling that option in the Jetpack plugin but that didn’t work. In the end, I added the following code to flickr-gallery.php, just before the “add_shortcode(‘flickr’…” line:

if (shortcode_exists('flickr')) {
    remove_shortcode('flickr');
}

Very much cheating… but it does work.

I’m trying to figure out if there’s a way of distributing the change in a more user-friendly format.