ios - In-App Purchase Receipt Validation Contradiction -

apple offers 2 documents receipt validation, apparently contradictory statements.

in "verifying store receipts":

note: on ios, contents , format of store receipt private , subject change. your application should not attempt parse receipt data directly.

yet, in "in-app purchase receipt validation on ios" sample code provided in store receipt parsed , verified, part of "mitigation strategy" security vulnerability:

// check validity of receipt.  if checks out ensure transaction // haven't seen before , decode , save purchaseinfo receipt later receipt validation. - (bool)istransactionanditsreceiptvalid:(skpaymenttransaction *)transaction {     if (!(transaction && transaction.transactionreceipt && [transaction.transactionreceipt length] > 0))     {         // transaction not valid.         return no;     }      // pull purchase-info out of transaction receipt, decode it, , save later     // can cross checked verifyreceipt.     nsdictionary *receiptdict       = [self dictionaryfromplistdata:transaction.transactionreceipt];     nsstring *transactionpurchaseinfo = [receiptdict objectforkey:@"purchase-info"];     nsstring *decodedpurchaseinfo   = [self decodebase64:transactionpurchaseinfo length:nil];     nsdictionary *purchaseinfodict  = [self dictionaryfromplistdata:[decodedpurchaseinfo datausingencoding:nsutf8stringencoding]];      nsstring *transactionid         = [purchaseinfodict objectforkey:@"transaction-id"];     nsstring *purchasedatestring    = [purchaseinfodict objectforkey:@"purchase-date"];     nsstring *signature             = [receiptdict objectforkey:@"signature"];      // convert string date     nsdateformatter *dateformat = [[nsdateformatter alloc] init];     [dateformat setdateformat:@"yyyy-mm-dd hh:mm:ss z"];      nsdate *purchasedate = [dateformat datefromstring:[purchasedatestring stringbyreplacingoccurrencesofstring:@"etc/" withstring:@""]];       if (![self istransactionidunique:transactionid])     {         // we've seen transaction before.         // had [transactionsreceiptstoragedictionary objectforkey:transactionid]         // got purchaseinfodict         return no;     }      // check authenticity of receipt response/signature etc.      bool result = checkreceiptsecurity(transactionpurchaseinfo, signature,                                        (__bridge cfdateref)(purchasedate));      if (!result)     {         return no;     }      // ensure transaction legit     if (![self dotransactiondetailsmatchpurchaseinfo:transaction withpurchaseinfo:purchaseinfodict])     {         return no;     }      // make note of fact we've seen transaction id     [self savetransactionid:transactionid];      // save transaction receipt's purchaseinfo in transactionsreceiptstoragedictionary.     [transactionsreceiptstoragedictionary setobject:purchaseinfodict forkey:transactionid];      return yes; } 

if understand correctly, if verify receipt app stop working when apple decides change format of receipt.

and if don't verify receipt, i'm not following apple's "mitigation strategy" , app vulnerable attacks.

damned if do, damned if don't. there i'm missing?

they heavily recommend use own server intermediary validation, allow clear , secure passage app store versions of ios. that's best route not damned either way.

if must perform validation directly device app store, utilise mitigation strategy only when application run on 5.1.x , below. ios6 , above, use recommended means provided.

whilst case shouldn't parse receipt directly, discovered vulnerability put apple between rock , hard place in how address this, , decided application developers implement check. means when user updates application, receipts secured again (irrespective of ios version), thereby providing better fix coverage. side effect, means have break how should (but apple have give permission so).

i agree documentation isn't wholly clear on this, , clarified bit more (you should give them feedback documentation pages @ bottom). apple have published mitigation strategy, , state should used on ios 5.1.x , below address vulnerability. onus on them if change format/contents of iap receipts.