I'm converting an app from iOS6 to iOS7. Before I used the deprecated transactionReceipt method so now I'm trying the recommended methods to retrieve the receipt, and then encode in base 64:
NSData *working = [NSData dataWithContentsOfURL:[[NSBundle mainBundle] appStoreReceiptURL]];
// Tried 64 or 76 chars/line and LF or CR line endings
NSString *receipt = [working base64EncodedStringWithOptions:kNilOptions];
The above is the only change in the code. Below is how I validate it, no changes:
dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
dispatch_async(queue,
^{
NSMutableString *url = [NSMutableString string];
[url appendFormat:@"%@", WEB_SERVICE];
[url appendFormat:@"receipt=%@", receipt];
NSStringEncoding encoding;
NSError *error = [NSError new];
NSURL *URL = [NSURL URLWithString:url];
NSString *json = [NSString stringWithContentsOfURL:URL usedEncoding:&encoding error:&error];
// check json and error
// ... code omitted
}
On the server side, this is the PHP code I use to verify the receipt, no change other than trying the sandbox for any error:
// Encode as JSON
$json = json_encode(array('receipt-data' => $receipt));
// Try production first, if it doesn't work, then try the sandbox
$working = postJSONToURL('https://buy.itunes.apple.com/verifyReceipt', $json, false);
error_log('production - '.print_r($working, true));
if (@$working['status'] !== 0) // === 21007)
$working = postJSONToURL('https://sandbox.itunes.apple.com/verifyReceipt', $json, true);
error_log('sandbox - '.print_r($working, true));
This is the error log output:
production - Array\n(\n [status] => 21002\n [exception] => java.lang.IllegalArgumentException\n)\n
sandbox - Array\n(\n [status] => 21002\n [exception] => java.lang.IllegalArgumentException\n)\n
It looks like I'm throwing all kinds of exceptions over at Apple!
Again the only difference is how the receipt is retrieved and encoded. Has anyone encountered this problem and fixed it?
Thanks for reading.
/YR
As requested, code for PostJSONToURL:
function postJSONToURL($url, $json, $disableSSLVerify = false)
{
$resource = curl_init($url);
curl_setopt($resource, CURLOPT_CUSTOMREQUEST, 'POST');
curl_setopt($resource, CURLOPT_POSTFIELDS, $json);
curl_setopt($resource, CURLOPT_RETURNTRANSFER, true);
curl_setopt($resource, CURLOPT_HTTPHEADER, array(
'Content-Type: application/json',
'Content-Length: '.strlen($json)));
curl_setopt($resource, CURLOPT_HEADER, 0);
if ($disableSSLVerify)
{
curl_setopt($resource, CURLOPT_SSL_VERIFYHOST, 0);
curl_setopt($resource, CURLOPT_SSL_VERIFYPEER, 0);
}
//curl_setopt($resource, CURLOPT_VERBOSE, true);
//curl_setopt($resource, CURLOPT_STDERR, $fp = fopen('/tmp/curl_output'.rand(1000, 9999).'.txt', 'w'));
$contents = json_decode(curl_exec($resource), true);
if (!$contents)
$contents = array();
curl_close($resource);
//fclose($fp);
return $contents;
}
New details after some experimenting, have determined that sending the existing data as base 64 encoded is likely encroaching on some internal limit. If it exceeds some internal limit, the data isn't even sent, it fails locally on the device, below that, it is sent. Columns are: data format, size of encoded data, whether it reached the server:
raw receipt data 5K N/A
base64 no options 6.66K yes
base64 76 chars/line 6.75K no
base64 64 chars/line 6.77K no
hex coded 10K no
Note that the difference between successfully sending and not sending is less than 100 bytes.
I've had this problem and looked everywhere, including on Apple's development forums. Apple will give a couple of stock replies, and that's it. I think it's a bug on Apple's side. Validation locally on the device will work, so try to convert to that. If you absolutely must use server side validation, only transactionReceipt seems to work right now.
The function is just deprecated, not banned, so I would just use it and hope Apple approves of the app. In fact, it's what I just did, fingers crossed, waiting for approval.
You can turn off the warning in Xcode by bracketing your code like this:
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wdeprecated-declarations"
// code using transactionReceipt
#pragma clang diagnostic pop
I am having success with iOS7 receipts, obtained from the app bundle using:
NSURL *receiptURL = [[NSBundle mainBundle] performSelector:@selector(appStoreReceiptURL)];
receipt = [NSData dataWithContentsOfURL:receiptURL];
The response, to my server, from Apple's server to the iOS7 style receipt differs greatly from that to the previous receipt style. Here's an example validated receipt:
{"status":0,
"environment":"Sandbox",
"receipt":
{"receipt_type":"ProductionSandbox",
"adam_id":0,
"bundle_id":"<snip>",
"application_version":"1.0",
"download_id":0,
"request_date":"2013-11-12 01:43:06 Etc\/GMT",
"request_date_ms":"1384220586352",
"request_date_pst":"2013-11-11 17:43:06 America\/Los_Angeles",
"in_app":[
{"quantity":"1",
"product_id":"<snip>",
"transaction_id":"1000000092978110",
"original_transaction_id":"1000000092978110",
"purchase_date":"2013-11-12 01:36:49 Etc\/GMT",
"purchase_date_ms":"1384220209000",
"purchase_date_pst":"2013-11-11 17:36:49 America\/Los_Angeles",
"original_purchase_date":"2013-11-12 01:36:49 Etc\/GMT",
"original_purchase_date_ms":"1384220209000",
"original_purchase_date_pst":"2013-11-11 17:36:49 America\/Los_Angeles",
"is_trial_period":"false"}
]
}
}
The pretty-printed indentation was for my benefit, not strictly speaking as given by Apple.
Here is the guts of my client side:
NSMutableDictionary *parameters = [NSMutableDictionary dictionary];
[parameters addEntriesFromDictionary:[credentials dictionary]];
// receipt is an object of my own making, but base64String just returns an
// NSString representation of the receipt data.
parameters[PURCHASE_RECEIPT] = [receipt base64String];
NSURLRequest *request =
[[AFHTTPRequestSerializer serializer]
requestWithMethod:@"POST"
URLString:urlString
parameters:parameters];
AFHTTPRequestOperation *operation =
[[AFHTTPRequestOperation alloc]
initWithRequest:request];
operation.responseSerializer = [AFJSONResponseSerializer serializer];
<snip>
[operation start];
And here is the guts of what I'm using on the server side where the URL is either the production or sandbox verification server:
// Some code from http://stackoverflow.com/questions/5647461/how-do-i-send-a-post-request-with-php
private static function validateReceipt($receiptData, $URL) {
// Connect to Apple server and validate.
$data = json_encode(array("receipt-data" => $receiptData));
// use key 'http' even if you send the request to https://...
// This: 'content' => http_build_query($data),
// seems to generate an error (21002)
$options = array(
'http' => array(
'header' => "Content-type: application/x-www-form-urlencoded",
'method' => 'POST',
'content' => $data
),
);
$context = stream_context_create($options);
$result = file_get_contents($URL, false, $context);
//Utils::writeToLog("done validateReceipt: " . $result);
// See http://php.net/manual/en/function.file-get-contents.php
// for the use of === comparison.
if ($result === FALSE) {
return NULL;
} else {
// Decode the result as an associative array.
return json_decode($result, true);
}
}
I'm having success with this code with both iOS6 and iOS7 style receipts.
I had the same symptoms: error 21002 (java.lang.IllegalArgumentException) while validating io7 style receipts from my own server.
It turned out there were two problems:
My receipt data was bad. Somehow while passing the data to my server it ended up with a bunch of "\r\n" characters in the base64 encoded receipt data. (I stripped these out with some search and replace code).
If you are using auto-renewing subscriptions then you must pass in two parameters in the JSON payload to verifyReceipt: "receipt-data" but also "password" which should be your shared secret from itunes connect.
Once I fixed those two things my verifyReceipt http requests worked as expected.
来源：https://stackoverflow.com/questions/19222845/ios7-receipts-not-validating-at-sandbox-error-21002-java-lang-illegalargume