I get link errors otherwise.

I know CargoBay works well, but exactly how to use it is a bit obtuse from the limited documentation. As somebody figuring out IAP for the first time, it would be helpful to have some general idea about how to set up the various transaction queue observers, and what to do once called. I eventually ran across LXReceiptStore and pieced together enough to get a basic implementation of my own, but it would be much more helpful if CB were documented with intended use cases and helpful hints.
In the same thread, adding more comments to code would be helpful.

Otherwise, great work! This has really saved me quite a bit of time from having to do my own solution from scratch or tutorial.

Apple consistently says not to hit the Apple servers to verify receipts in their WWDC videos (see WWDC 2014 session 305 slide 197). However, there aren't any warnings against doing that in the code or in the readme / docs.

I am reading in the AFNetworking github page that it supports ARC.

I think it would be nice if CargoBay's AFNetworking submodule were updated to use ARC.

Can CargoBay be used for non-renewing subscriptions?
And does it help out with persisting purchases in iCloud like the Storekit guide suggests?
Any good tutorials on using CargoBay available?

Thank you very much!

-Svend

https://github.com/mattt/CargoBay/blob/master/CargoBay/CargoBay.m#L939

CargoBay/CargoBay.m:701:54:
warning: Sending '__strong id<SKProductsRequestDelegate>' to parameter of incompatible type 'CargoBayProductRequestDelegate *'

Hi @mattt,

I would like to propose a number of changes and would like to know about your thoughts of them.

These changes are based on issues I faced while doing In-App Purchase in the past. Mostly doing client side validation as any errors and fixes will have to go through the Apple Review Process. This issues can be very deterrent to the business and can generate a lot of unhappy paid customers.

• Smarter error handling of receipt verification
  • The status code returned may contains 21007 or 21008 which indicates that receipt is for production or sandbox server respectively. Apple will not catch this in the Review Process. (I have an app that got approved while it is validating against sandbox) My suggestion is the code should catch these hint and retry accordingly, rather than fail totally.
  • The status code 21006 may not be a considered a failure. (In the companion code below, Apple treat this as valid) It just an indication that the receipt have expired.
  • The status code 21004 should considered critical error and should throw an exception? The goal is to catch these early. But if someone reset the shared key (I think it is resettable) in production, this can be a major problem. (But I think its not worst than someone paid for something but the app keep telling them that the purchase is not valid)
  • In Auto-Renewable Subscriptions, it describe further the meaning of certain status code
• Fix In-App Purchase vulnerability (For iOS 5)
  • In-App Purchase Receipt Validation on iOS
  • Apple says that iOS 6 addresses this vulnerability, but would it be a better if the library also take care of it based on Apple recommendation?
  • [Pending discussion] In Apple solution, it stores the transaction IDs (In user defaults) and check against it.
  • [Currently broken] In Apple solution, it will need to link against the Security framework. (Was thinking of making it optional, similar to AFNetworking MobileSystemConfiguration and CoreServices)
• Supports verifying auto-renewable subscription receipt.
  • Needs a way to stores shared secret or extends the interface to support verifying receipt in addition to shared secret.

I planning to see if I can do my part in helping with these improvements.

A lot of the code will be based on the companion file that come with In-App Purchase Receipt Validation on iOS.

It would be great that CargoBay support AFNetworking 3.0. Any though about it?

I think there is a memory leak from SecTrustCopyPublicKey in the CBCheckReceiptSecurity function on line 551 of CargoBay.m - the receiptSigningKey var is never CFRelease'd. If the release is added to the _out label the receiptSigningKey will likely need to be declared and set to NULL at the beginning of the function before the require statements.

Command /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang failed with exit code 1

i.m getting this error

I keep getting this error when I do a receipt check:

Error 3840 The operation couldn’t be completed. (Cocoa error 3840.)

As I understand it, it could be something with the AF request - http://stackoverflow.com/questions/19720890/cocoa-error-3840-when-post-request-with-afnetworking-2.

Any ideas?

Hi Mattt or anyone else,

How do I use the local receipt verification for transactions? I noticed the 'setTransactionIDUniquenessVerificationWithBlock' function, and noticed it says this without this call no uniqueness verification is perfomed. I'm not an ObjC dev, so any examples or help on how to use the local verification functionality would be much appreciated. I was looking in the CargoBayTests.m file, but am not entirely sure if the verifyTransaction calls will use local verification or not.

Thanks for any help!

Verify receipt not working on Yosemite. Routine never calls back.

One thing that cargobay lacks is the ability to verify if one particular inapp was purchased, I mean, checking it by the productID.

I got excited to see the podspec and readme for CargoBay included Mac OS X StoreKit support, but alas, 0.3.3 has a ton of compilation errors for a Mac target, most of which are due to iOS only API calls.

Do you plan on supporting OS X going forward, or is this really an iOS only tool?

Abstract

When AFNETWORKING_PIN_SSL_CERTIFICATES is defined in AFNetworking (like it is when using CocoaPods), CargoBay won't compile. This is because of the two methods setAuthenticationAgainstProtectionSpaceBlock and setAuthenticationChallengeBlock are in the other part of the ifdef.

Steps to reproduce:

• Create blank project.

• Create Podfile with

  platform :ios, '6.0'
  
  pod 'CargoBay'
  

• run pod install

• Observe the xcworkspace won't compile

Workaround

For those with similar problems until an update is posed - It's an easy enough work around to uncomment that define from the Pod file.

Hi Matt, I'm hoping you can clarify something around the use of the password field when using the verifyTransactionWithMethod: method. Apple recommends that a Server is used to combine the SharedSecret (password) with the receipt before calling Apple to verify it so that the secret is not embedded in the App. AFAICR this is specifically for auto-renewing subscriptions but might apply to other IAPs. CargoBay seems to be subverting that recommendation by combining the SharedSecret on the Client side, or is it doing something special that eliminates the need for a intermediate Server in the first place ?
Fergal

Recently I have found that my application is purchased fraudulently using the jailbreak. I wonder if CargoBay is secure against the jailbreak.

Thank you!

I'm getting this behavior on iOS 5: if the products request returns an empty array of products the application crashes.

I've tracked this down to CargoBay and in particular to one line of code in CargoBay.m, in the productsRequest:didReceiveResponse: method.

- (void)productsRequest:(SKProductsRequest *)request
     didReceiveResponse:(SKProductsResponse *)response
{
    if (_success) {
        _success(response.products, response.invalidProductIdentifiers);
    }

     // commenting the line below remove the crash
    //[[self class] unregisterDelegate:self];
}

Hope it helps and it's not a problem I created in my specific situation.

In the following method

- (void)verifyTransactionReceipt:(NSData *)transactionReceipt
                        password:(NSString *)passwordOrNil
                         success:(void (^)(NSDictionary *responseObject))success
                         failure:(void (^)(NSError *error))failure
{
    NSError *error = nil;
    NSDictionary *receiptDictionary = [NSPropertyListSerialization propertyListWithData:transactionReceipt options:NSPropertyListImmutable format:nil error:&error];
    if (!receiptDictionary) {
        if (failure) {
            failure(error);
        }
        return;
    }

    NSString *environment = [receiptDictionary objectForKey:@"environment"];
    NSURL *endpoint = [environment isEqual:@"Sandbox"] ? [NSURL URLWithString:kCargoBaySandboxReceiptVerificationURLString] : [NSURL URLWithString:kCargoBayProductionReceiptVerificationURLString];

    [self verifyTransactionWithMethod:@"POST" endpoint:endpoint receipt:transactionReceipt password:passwordOrNil success:success failure:failure];
}

https://github.com/mattt/CargoBay/blob/master/CargoBay/CargoBay.m#L779

is failing to parse receipt data obtained from appStoreReceiptURL

NSURL *appStoreReceiptURL = [[NSBundle mainBundle] appStoreReceiptURL];
NSData *receiptData = [[NSData alloc] initWithContentsOfURL:appStoreReceiptURL];

the error

Error Domain=NSCocoaErrorDomain Code=3840 "Unexpected character 0 at line 1" UserInfo={NSDebugDescription=Unexpected character 0 at line 1, kCFPropertyListOldStyleParsingError=Error Domain=NSCocoaErrorDomain Code=3840 "Conversion of string failed." UserInfo={NSDebugDescription=Conversion of string failed.}}

The receipt validation in CBValidatePurchaseInfoMatchesReceipt always checks the device uniqueIdentifier or identifierForVendor.

When restoring purchases from a different device with the same Apple ID this results in a CargoBayErrorPurchaseInfoDoesNotMatchReceipt error.

Maybe you're not supposed to check validation on restoring?

I'm not sure if doing anything wrong or something, but this code always executes the failure block:

        NSData *receData = [NSData dataWithContentsOfURL:[[NSBundle mainBundle] appStoreReceiptURL]];
        NSLog(@"%@", receData);
        [[CargoBay sharedManager] verifyTransactionReceipt:receData
                                                  password:nil
                                                   success:^(NSDictionary *responseObject) {
                                                       NSLog(@"Yam %@", responseObject);
                                                   }
                                                   failure:^(NSError *error) {
                                                       NSLog(@"error %@", error.localizedDescription);
                                                   }];

The NSLog there does print a lot of data, so I can confirm that the receipt is not nil.

"Apps are not permitted to access the UDID and must not use the uniqueIdentifier method of UIDevice"

The rejection was ~5 mins after I submitted a binary. The issue is the second half of CBValidatePurchaseInfoMatchesReceiptForDevice

I'm not sure if I am being particularly dim. The README says there is a method:

[[CargoBay sharedManager] productsWithURLRequest:[NSURLRequest requestWithURL:URL]
success:^(NSArray *products, NSArray *invalidIdentifiers) {
  // ...
} failure:^(NSError *error) {
  // ...
}];

I can't find this method in the code.

unable to install version 2.0.1...

Installing CargoBay (2.0.1)
[!] Pod::Executable fetch origin tags/2.0.1 2>&1

fatal: Couldn't find remote ref tags/2.0.1

fatal: The remote end hung up unexpectedly

AFNetworking 1.3.2 removes the

define AFNETWORKING_PIN_SSL_CERTIFICATES and associated code for when it is undefined, which breaks Cargo Bay since it still expects it to be present.

I am testing in Sandbox and not sure if this is a known issue. I am able to purchase and verify the receipt, but when I try to restore and verify again I get this error on verifyTransaction:
Transaction ID (XXXXXXXXX) is not unique.

when i dbug my project getting this error. But given path is correct. please help me.

Can CargoBay be used for Auto-Renewable subscriptions? Am I right in thinking that there would need to be a server-side component with auto-renewable subscriptions, for receipt verification? There seems to be a lack of open source resources for this server component.

Only when I compile for the device I get two expected expression errors in line 511 and 514 pointing to the beginning of struct:

require(signatureLength > offsetof(struct CBSignatureBlob, _certificate), _out);
require(signatureLength - offsetof(struct CBSignatureBlob, _certificate) >= certificateLength, _out);

Sometimes they magically disappear when I compile again (no clean before), but the errors are always thrown when compiled on travis ci.

Xcode 5.0.2, iOS 7 only, not compiling for 64bit yet, CargoBay 2.0.2.

CargoBay's podspec for AFNetworking is not pinned to a version, so the new changes to AFNetworking, namely removing setAuthenticationAgainstProtectionSpaceBlock: and setAuthenticationChallengeBlock: in AFHTTPRequestOperation break CargoBay.

Can we pin the podspec to a specific version so that this won't happen in the future?

Hi! I've installed CarboBay 0.2.1 via CocoaPods and I'm getting 2 warnings in Pods target:

CargoBay/CargoBay.m:1038:11: warning: capturing 'self' strongly in this block is likely to lead to a retain cycle [-Warc-retain-cycles]
    [[self class] unregisterDelegate:weakSelf];
      ^~~~
CargoBay/CargoBay.m:1033:5: note: block will be retained by an object strongly retained by the captured object
    _success = [^(NSArray *products, NSArray *invalidIdentifiers) {
    ^~~~~~~~
CargoBay/CargoBay.m:1046:11: warning: capturing 'self' strongly in this block is likely to lead to a retain cycle [-Warc-retain-cycles]
    [[self class] unregisterDelegate:weakSelf];
      ^~~~
CargoBay/CargoBay.m:1041:5: note: block will be retained by an object strongly retained by the captured object
    _failure = [^(NSError *error) {
    ^~~~~~~~
2 warnings generated.

As I see, those warnings were already fixed in master. Could you please consider releasing a new version?

Thank you.

Hi,

I would like to create a podspec (of CocoaPods) for CargoBay. Could you create a tag version for better versioning, please?

I was just wondering if this already has support for the Ask To Buy functionality of iOS8?

Documentation: https://developer.apple.com/library/ios/technotes/tn2259/_index.html#//apple_ref/doc/uid/DTS40009578-CH1-UPDATE_YOUR_APP_FOR_ASK_TO_BUY

Looking through the CargoBay.m file, I didn't notice any reference to the SKPaymentTransactionStateDeferred which is what Apple says to use for this situation.

Thanks!

The transactionReceipt property in SKPaymentTransaction has been deprecated in iOS 7 and causes warnings in Xcode.

Is there any change to make when going form sandboxing to production? Or: How does CargoBay know which URL to use?

I have installed the pod 'CargoBay', '~> 0.3.3', and i'm allready using AFNetworking in the project. Does not compile after pod install.

readme.md should be updated with how to install with and without allready using AFNetworking pod.

I'm checking the receipt of a non-consumable item, but when CargoBay sends the receipt to Apple and get's a response back, the response status is always "CargoBayStatusReceiptValidButSubscriptionExpired".

As far as I know, you should only get such a status, when checking a subscription?

I don't know if this is how it's supposed to be or not?

Although iOS 9 is still in beta but I believe transactionReceipt will officially get retired in the final release and appStoreReceiptURL should be used for iOS >= 7. Otherwise lots of code that rely on CargoBay will fail in the IAP validation.

In...

-[CargoBay productsWithIdentifiers:success:^(NSArray *products,
    NSArray *invalidIdentifiers) failure:^(NSError *error)]

...I'm seeing the following crash:

[CargoBayProductRequestDelegate respondsToSelector:]: message sent to deallocated instance

From what I understand, -[SKProductsRequest _handleReply:] calls productsRequest:didReceiveResponse: on the delegate. The delegate calls the success block, unregisters itself with +[CargoBayProductRequestDelegate unregisterDelegate:] and is promptly destroyed (zombied).

I only started seeing this in the new [redacted] SDK, but it seems that core problem is the delegate object shouldn't destroy itself after running the success block. (The delegate has no way of knowing that the caller is completely finished.)

Not sure what the best solution/workaround here is. Thoughts?

I'm currently seeing the following build error when trying to build and run the example project:

clang: error: no such file or directory: '/Users/VA/Desktop/CargoBay-master/AFNetworking/AFNetworking/AFHTTPRequestOperationManager.m'
clang: error: no input files
Command /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang failed with exit code 1

I'm using cocoapods, and XCode 5.1

CargoBay/CargoBay.m:798:56: 'requestWithMethod:URLString:parameters:' is deprecated
on iOS 7.

I'm trying to verify receipts using Helios deployed on Heroku. When I do the verification request manually it works fine and returns the correct receipt data. When I do it using CargoBay though with verifyTransactionWithMethod:endpoint:receipt:password:success:failure I get 400 Bad Request and the error message Invalid parameter, receipt-data.

I'm using CargoBay 0.3.3, AFNetworking 1.3.1 and testing on iOS 7. Am I missing something or this is a bug?

I have an live app that have user complaining that they couldn't access their purchase anymore.

From my diagnostic, it seems that after the initial purchase, if the user attempts to restore the subscription, it will always failed. After much debugging, I finally figure out the culprit. Below is a copy of the commit message I had attached to commit 37f83c7.

Every (re-)installation generates a new unique identifier for vendor.
Every purchase and restoration receipt will be tag with this new unique identifier.
But the latest receipt info might have a unique identifier for vendor from another device, from a previous installation, etc.
So we should only check if the purchase info matches receipt for device for receipt we restored with this device.
We should not check for unique identifier for vendor in latest receipt info.
This has caused a critical bug where restoration will always fails.

This commit attempts to fixed this issue.

Because I have already any pull request open, this commit got merge into PR #21. I'm sorry about that. I'm in the process on extracting out the PR to another branch and send another pull request.

Sorry about that!

I'm using CargoBay in non-arc project. I have set flags in project settings to enable ARC

CargoBay.m:44:10: No previous prototype for function 'CBDateFromDateString'
CargoBay.m:60:12: No previous prototype for function 'CBBase64EncodedStringFromData'
CargoBay.m:89:10: No previous prototype for function 'CBDataFromBase64EncodedString'
CargoBay.m:143:6: No previous prototype for function 'CBValidateTrust'
CargoBay.m:171:6: No previous prototype for function 'CBValidatePurchaseInfoMatchesReceipt'
CargoBay.m:253:6: No previous prototype for function 'CBValidateTransactionMatchesPurchaseInfo'
CargoBay.m:380:6: No previous prototype for function 'CBCheckReceiptSecurity'

How to correctly fix warnings? Compile CargoBay as static library or it's ok to add static

static NSDate * CBDateFromDateString(NSString *string)

If AFNetworking 0.10.x is used, is CargoBay compatible with iOS 4.3?

@mattt I notice that CargoBay.m line 234, you use the

[[UIDevice currentDevice] uniqueIdentifier];

I wonder if it will cause the reject of app review?

Using the verifyTransaction example from the readme results in the failure block always being called due to receiving a content type of text/plain from the Apple receipt server.

This is the error I get in the failure block of verifyTransaction:

Error -1016 (Expected content type {(
"text/json",
"application/json",
"text/javascript"
)}, got text/plain)

Could the http client in CargoBay be made less strict so that it can accept a text/plain response? Seems like the json from Apple may be valid but doesn't have the correct header.

Only tested this in the Sandbox environment so maybe it's not an issue in production.