Ich habe einige sehr seltsame Probleme mit der base64-Codierung von iOS7-Quittungen festgestellt.
Im Moment (Xcode5 / iOS7) gibt es zwei Methoden, um eine Quittung für einen In-App-Kauf zu erhalten:
[SKPaymentTransaction transactionReceipt]
Meine App verkauft Website-basierte Dienste mit einem Kreditsystem, das die Bestätigung des Serverempfangs erforderlich macht. Die App verkauft auch herunterladbare Erweiterungen. Also eine Mischung aus Verbrauchsmaterialien und Nicht-Verbrauchsmaterialien. Die Nicht-Verbrauchsmaterialien werden von Apple heruntergeladen, sodass keine Überprüfung erforderlich ist. Bei den Verbrauchsmaterialien handelt es sich um Credits, die für den Kauf von Dienstleistungen auf der Website verwendet werden.
Wenn iOS7 & amp; XCode5 gestartet Ich habe meine App aktualisiert, hatte aber Probleme mit dem neuen gebündelten Beleg, der sich unter appStoreReceiptURL befindet. Mit dem neuen Stil, alle Belege gebündelt, hat mein Server diesen Fehler von Apples verifyReceipt Sandbox
zurückbekommen %Vor%Ich gab auf, nachdem ich Beiträge auf stackoverflow gesehen hatte, die sagten, dass andere das gleiche Problem hatten und dass die Meinung zu der Zeit war, dass es ein Fehler war oder Feature hinzugefügt wurde, auf Seiten von Apple. Ich habe jedoch Probleme bei der Verwendung der alten veralteten Methode gesehen, die mich gezwungen hat, es erneut zu versuchen. Nach vielem Debuggen und Suchen habe ich endlich etwas herausgefunden, was schief gelaufen ist - und es funktioniert, aber auf eine sehr hässliche Art und Weise, von der ich nicht überzeugt bin, mit ihr zu leben.
Ich hätte gedacht, dass die codierte Ausgabe von NSData (einfacher Byte-Puffer) sich nicht sehr unterscheiden würde. Hier ist der komische Teil, den ich sehe.
Die ursprünglichen veralteten Einzelbelege können entweder als 64-Zeichen-Zeilen mit \ r \ n am Ende oder ohne base64 codiert werden. Apple Verification Server ist es egal. Es ist so oder so glücklich.
Für das neue Quittungsbündel wird es nur funktionieren, wenn 2 Dinge erledigt sind. Zunächst darf die base64-Codierung keine Zeilenumbrüche enthalten. Ich stelle fest, dass Apple seinen eigenen base64-Encoder in iOS7 hinzugefügt hat. Dies ist, was ich verwende, um eine codierte Ausgabe zu erhalten, die für beide Belegarten funktioniert.
%Vor%Die zweite Sache, die getan werden muss, ist das Suchen und Ersetzen aller Leerzeichen aus dem empfangenen codierten Quittungsbündel auf dem Server. d. h.
%Vor%Ich bemerkte zufällig, dass dies ein Unterschied zwischen den Quittungen war, die von meinem Server empfangen wurden. Warum ich nicht weiß? Ich verwende AFNetworking-1.3.2's JSONRequestOperationWithRequest
%Vor%Chris Prince behauptet, dass es mit AFNetworking 2 in seiner Antwort auf diese Frage
Warum könnten diese beiden NSData-Quittungen Codierungs- / Decodierungsprobleme verursachen, wie ich sie sehe? Ich war so detailliert und klar, wie ich hier sein kann, um anderen zu helfen, da ich sehe, dass viele Leute die gleichen Schmerzen hier fühlen, mit dieser neuen Empfangsmethode, die Apple eingeführt hat.
Die Antwort ergab sich aus
%Vor%entgeht nicht allen Sonderzeichen wie: /? # [] @! $ & amp; '() * +,; = usw. Der neue Beleg, den Apple bereitstellt, enthält, sobald er base64-codiert ist, Zeichen, die es zu entkommen gilt, aber nicht durch den obigen iOS-lib-Escape-Kodierer entkoppelt werden. Als ich mich umsah, fand ich hier einen, der gut funktioniert. Siehe unten für den Arbeitscode. (Der Server muss den Empfangscode jetzt nicht mehr analysieren und kann ihn direkt aus $ _POST heraus verwenden)
%Vor%Tags und Links objective-c base64 in-app-purchase ios7