This part is about testing the Receipt Validation. At least partly: the success oriented approach. I.e. Only testing that the Receipt Validation works for a valid receipt. To perform a complete test, we would need a series of Receipts, each with a different error in it. But since the example code published in part6 is so simple, we just trust open SSL and the other tidbits to do their job.
How to get a receipt?
This is simple, but you must create a test user first. You will have to do that in iTunes Connect. In the module "Users and Roles" you will find a tab "Sandbox Testers". In there you can click the "plus" sign to add a tester. (This must be a different email address than your admin account!)
When done, enter Xcode and build your application. Make sure you use a developer certificate (perhaps confusingly this means that you should select signing identity "Mac App Store" for your target!)
The app does not have a receipt yet, so we have to fetch a receipt. To do this, we have to double click the App icon. Dive into the build directory from Xcode and find your App. Since the place of the build directory is configurable, I cannot tell you where it is. You can use the Xcode -> Preferences -> Locations -> Advanced panel to find out where it should be. When found, double click the app Icon. A window should appear asking you for your app store credentials. Use your test account (This is important!).
Next, the app should launch. If it does, congrats, the validation worked. If it did not, don't panic, simply get back into Xcode and set a break point at the start of the validation process. The previous steps have placed a certificate in your app bundle, and that certificate will remain there until you do something that removes it, like deleting the app. As long as you stick with Xcode the receipt will remain in place. Even when you create a new build.
Now, with the breakpoint in place step through the validation code until you spot the bug.
Fix it, rebuild, and test again. The receipt will be preserved during builds, so you don't have to fetch a new receipt every time.
Everything works?
OK, then now the real jobs starts: OBFUSCATE the validation code. Be as creative as you can and try to think like a hacker. How would you break your code? Then make sure you cannot. In part 9 of this series I have added some thoughts about obfuscation.
Obfuscation is a lot of work and it has to be done carefully, so that is why in part 8 I will show how I use Receigen to generate the obfuscation code for me :-)
2015-06-08: If you create a new version of the application, Xcode will still use the old receipt. When you then start the application you will get an error message: "... is damaged and can't be openend. Delete ... and download it again from the App Store.".
In this case, open up the App package by right-click on the Application icon, select "Show Package Contents" from the popup menu, navigate to the "Contents/_MASReceipt" and remove the "receipt" file. Then double click the icon again. Now you will be asked again for your test account credentials.
Happy coding...
Did this help?, then please help out a small independent.
If you decide that you want to make a small donation, you can do so by clicking this
link: a cup of coffee ($2) or use the popup on the right hand side for different amounts.
Payments will be processed by PayPal, receiver will be sales at balancingrock dot nl
Bitcoins will be gladly accepted at: 1GacSREBxPy1yskLMc9de2nofNv2SNdwqH
We don't get the world we wish for... we get the world we pay for.
No comments:
Post a Comment