Speichern in App-Kaufeinnahmen in der Anwendung Keychain

Question

Ich habe noch nie im App-Kauf implementiert, also habe ich den Mkstorekit-Wrapper verwendet und habe eine Arbeitsumsetzung. Mkstorekit hält alle Quittungen in den UserDefaults .platin als BOOL, somit ist es für Piraten sehr einfach, die in App-Käufe in einem "rissigen" Zustand zu verteilen. Sobald der erste Kauf getroffen wird, kann das Bündel verteilt sein und der .plist kann neu erstellt werden, um IAP-Entriegelungen zu ermöglichen.

Ich möchte mkstorekit erweitern, um die in App-Kauf-Validierungsdaten in der iOS-Keychain zu erstellen. Gibt es einen Nachteil oder ein möglicher Grund dafür, dass dies für die Zahlung von Benutzern nicht fehlerhaft ist, oder einen anderen Grund, warum es eine völlig schlechte Idee ist, dies zu tun? Ich verstehe, dass die Piraterie unvermeidlich ist, und ich möchte definitiv nicht zahlende Nutzer entfremdet, aber ich fühle mich, dass die Userdefaults .plist zu einem einfachen Weg ist, um zu umgehen.

In meinem Szenario würde eine einfache Zeichenfolge, wenn der Kauf getroffen wird. Wenn das Binärer verteilt wird, sind nicht bereits freigegeben. Sicher, es wäre möglich, eine Problemumgehung zu finden, aber es würde etwas mehr Anstrengungen dauern und wissen, wie Sie die wahre / falsche Flagge finden, und veranlassen, dass er den richtigen Wert immer zurückgibt. Durch die Verschleierung konnte ich sogar etwas schwieriger machen, das nach unten zu verfolgen.

Vielen Dank für alle Ihre Erkenntnisse und ich schätze Antworten, die die obligatorische unvermeidliche Piraterie vermeiden, von ihnen antworten. Ich interessiere mich mehr für die technischen Vibrsinitäten dieser Lösung.

Answer 1

We do exactly that in our of our apps and it works great.It’s a free app that you can upgrade to a full version and we store the upgrade indicator in the keychain. The upgrade indicator is an arbitrary string that you choose, but for the purposes of the keychain it is treated as a password, i.e. the value for kSecValueData is encrypted in the keychain. A nice bonus about this approach is that if the user deletes the app and then later re-installs it, everything is re-enabled like magic because the keychain items are stored separately from the app. And it’s so little additional work over storing something in the user defaults that we decided it was worth it.

Here’s how to create the security item:

NSMutableDictionary* dict = [NSMutableDictionary dictionary];

[dict setObject: (id) kSecClassGenericPassword  forKey: (id) kSecClass];
[dict setObject: kYourUpgradeStateKey           forKey: (id) kSecAttrService];
[dict setObject: kYourUpgradeStateValue         forKey: (id) kSecValueData];

SecItemAdd ((CFDictionaryRef) dict, NULL);

Here’s how to find the security item to check its value:

NSMutableDictionary* query = [NSMutableDictionary dictionary];

[query setObject: (id) kSecClassGenericPassword forKey: (id) kSecClass];
[query setObject: kYourUpgradeStateKey          forKey: (id) kSecAttrService];
[query setObject: (id) kCFBooleanTrue           forKey: (id) kSecReturnData];

NSData* upgradeItemData = nil;
SecItemCopyMatching ( (CFDictionaryRef) query, (CFTypeRef*) &upgradeItemData );
if ( !upgradeItemData )
{
    // Disable feature
}
else
{
    NSString* s = [[[NSString alloc] 
                        initWithData: upgradeItemData 
                            encoding: NSUTF8StringEncoding] autorelease];

    if ( [s isEqualToString: kYourUpgradeStateValue] )
    {
        // Enable feature
    }
}

If upgradeItemData is nil, then the key doesn’t exist so you can assume the upgrade is not there or, what we do, is put in a value that means not upgraded.

Update

Added kSecReturnData (Thanks @Luis for pointing it out)

Code on GitHub (ARC variant)