Testing sandbox purchases with production magrocket server

[rogerdcarvalho]

Hi there,

I'm getting ready to submit my update build to apple for approval, but when i purchase a sub or an issue, the buy button doesnt change to download in the test build. The production build works fine. Is this due to magrocket not being in 'development mode'? Will my binary not be rejected if i cant test purchases in sandbox?

[nin9creative]

What version of MagRocket are you using? The released 1.0 version?

There was a fix added to later API builds that would revert to the Sandbox API when a Production call failed on Apple's side - mostly to not run into this issue. The Baker Cloud Console (CE) version should have resolved this problem. If you are running MagRocket, the best bet would be to look into the API Repository (Master) and do a DIFF against your version. Don't pull ALL the changes in as there were other things modified as well to work with newer backend code - however you should be able to see some if statements and whatnot surrounding errors coming from the verifyReceipt call to Apple. You'll see that there is error handling to revert to the Sandbox and try again.

[rogerdcarvalho]

I think I'm using 1.0.1... Was the change added after that?

[nin9creative]

Well, the 1.0.1 API had that Sandbox fix...  Hmmm.

Are there any errors or messages logged in the MagRocket SYSTEM LOG table?

Andrew

---

From: rogerdcarvalho notifications@github.com To: bakerframework/baker baker@noreply.github.com Cc: Andrew andrew@nin9creative.com Sent: Wednesday, December 18, 2013 12:44 PM Subject: Re: [baker] Testing sandbox purchases with production magrocket server (#65)

I think I'm using 1.0.1... Was the change added after that? — Reply to this email directly or view it on GitHub.

[rogerdcarvalho]

Turns out the changes you'd commented for verify receipt sandbox were not in my version. I added those. Now when I subscribe it does accept the subscription and says 'subscribed', however the products still don't go from 'buy' to 'purchased'. Error in magrocket log is 'Undefined property: stdClass::$purchase_date_pst'

[nin9creative]

That sometimes seems to happen on occasion - seems that sometimes the Apple receipt call doesn't fail, but it doesn't return a valid full response.  I've never been able to pinpoint that exact problem and reproduce it.

---

From: rogerdcarvalho notifications@github.com To: bakerframework/baker baker@noreply.github.com Cc: Andrew andrew@nin9creative.com Sent: Wednesday, December 18, 2013 5:54 PM Subject: Re: [baker] Testing sandbox purchases with production magrocket server (#65)

It says Undefined property: stdClass::$receipt multiple times? — Reply to this email directly or view it on GitHub.

[rogerdcarvalho]

Applying the 3 changes you proposed here - https://github.com/Simbul/baker/issues/1007 caused the $purchase_date_pst error I raised above, but worse, it broke production. When I tried to purchase an item in production, the button also didn't change from 'buy' to 'download'. I therefore reverted to my original index.php. What do you recommend? Apple will definitely not accept my update like this.

[rogerdcarvalho]

OK, so I decided to do a fresh install of Baker Cloud Console (CE) alongside my existing magrocket install. I installed both the app and the api in separate subdomains from the production version I have running on magrocket. I then pointed my development app to the new api subdomain.

When testing DB connectivity of the new cloud console I got an error. Investigating the php, I discovered the error had to do with the 'logAnalyticMetric(AnalyticType::ApiInteraction,1,NULL,$app_id,$user_id)' call, this didn't work for whatever reason. Commenting that out gave me a success message.

Testing the app worked when I am in sandbox mode. Then switching to production mode, the app still seems to function as expected. Now I've got two choices:

1. I submit the app as is, assuming Apple will accept it. As soon as they do, I point my new subdomain to the old magrocket production install.
2. I import all existing purchases, receipts and subscriptions from the old DB to the new DB. I then point my production subdomain to the new baker cloud install and allow the existing production app to use this new backend. I can then submit the app pointing to the same subdomain, and there is no difference between my old and new app. What I worry about is how stable the new baker cloud backend is. Is there a risk of a receipt/purchase or subscription not functioning correctly if I attempt this migration? What's with this new analytics code, if it didn't run successful in the 'checkconnectivity' test, how stable is it going to run when all my production transactions are going to run through it?

Please advise on what would be the best way to move forward. I'd like to thank you any way for your continued support and for the great job you've done on developing this whole back end. Really stellar work.

[nin9creative]

In looking at it, that logAnalyticMetric shouldn't be in the /checkinstall method...

The $user_id and $app_id aren't present there. I don't know how I missed that when testing, however it doesn't throw an error on my test install of the app http://apice.thebakercloud.com/checkinstall/

That codebase is the same as the released version. Regardless, that call can be commented out of the /checkinstall method.

As for the stability of the CE app. It should be fine. I know of a few folks that are running it in Production, and have been for a while. It's basically the latest MagRocket main branch with the rebranded look and feel for the CE product.

I'm still curious as to why the current MagRocket install you have doesn't work - it should.

In any case, you should be able to do as you state in your second point. The Analytics bit in the /checkinstall is a bug. Perhaps just do some testing in Sandbox mode to see if the Analytics metrics are being logged ok, and if there are any errors logged in the SYSTEM LOG. If you move the data as you suggest for the various tracking tables - you should be ok I think.

[nin9creative]

I just pushed a change to the CE API master that removed the logAnalytic call from the /checkinstall method

[rogerdcarvalho]

Thanks, your other analytics code seems to run fine in development (at least the table gets populated). I do get errors in the log again around 'Undefined property: stdClass::$purchase_date_pst' if I switch the backend to production instead of sandbox, but the app does keep the 'purchased' flag for the issues. I'm going to test some more later today with other test accounts and devices.

I'll give the migrating to production a go. I've got Google Analytics running on my production app, so I'll just try to see if I can find a timeslot when there is minimal to no activity in my app by my existing users and test if production functions correctly as well. Thanks again, pretty impressed with the improvements you've made to the backend, now being able to allow subscribers to download back-issues as well (my existing magrocket install didn't have that).

[rogerdcarvalho]

I was wrong. It still doesn't work. With a fresh build and fresh test account, the buy button doesn't change to download after subscribing. Log says 'Undefined property: stdClass::$purchase_date_pst'.

It only works when I put the server in development mode, so this means that whenever I want to do a future update, I'll face the same problem. Even with a fresh baker cloud console install, the sandbox fallback in production mode doesn't seem to work?

[rogerdcarvalho]

Performing some tracing in your php code now, the sandbox fallback approach definitely doesn't work. The verifyreceipt method is never called with $sandbox_override as true if you perform a purchase in a development build. iTunes does however return the errorcode 21007 when you try verifyreceipt on production, so there must be something missed in whatever is in between that error code and where it is supposed to call verifyreceipt again with the override.

[nin9creative]

The error code 21007 means that a Sandbox receipt was called against the Production API.  That is the scenario that should occur.  The API would be going against the Production Apple Verify Receipt service, but sending it an actual receipt from the Sandbox environment.

---

From: rogerdcarvalho notifications@github.com To: bakerframework/baker baker@noreply.github.com Cc: Andrew andrew@nin9creative.com Sent: Thursday, December 19, 2013 3:01 PM Subject: Re: [baker] Testing sandbox purchases with production magrocket server (#65)

Performing some tracing in your php code now, the sandbox fallback approach definitely doesn't work. The verifyreceipt method is never called with $sandbox_override as true if you perform a purchase in a development build. iTunes does however return the errorcode 21007 when you try verifyreceipt on production, so there must be something missed in whatever is in between that error code and where it is supposed to invoke verifyreceipt again with the override. — Reply to this email directly or view it on GitHub.

[rogerdcarvalho]

yes i've traced it a bit further but still lost. The if (!isset($data->status) || ($data->status != 0 && $data->status != 21006)) you have right after the code is received works, but it never gets to the following lines. Thus when you catch the exception, the error code is not 21007 and you never re-call the verifyreceipt method. Subsequently, you try to enter the flawed data into the database, causing the purchase date error. What I don't get yet is why the subsequent code doesnt execute as expected

[rogerdcarvalho]

I think the fault is that you try '$product_id = $data->receipt->product_id;' right after itunes returns the 21007 error. I don't think that's feasible, as there isn't a product_id in the receipt?

[rogerdcarvalho]

So when I comment out this '$product_id = $data->receipt->product_id;' right after itunes gives you the 21007 error, your routine seems to continue as intended, but still leads to the button not changing from buy to download... really frustrating!

[nin9creative]

I'll be honest with you. The whole Newsstand/Receipt handling process is frustrating. Why Apple has made this so difficult in the first place is beyond me. But I digress... I will admit, this bit may not have been tested and exercised fully to catch all issues.

I don't know what the $product_id bit is in there for. That is definitely not even needed at that point. I was able to trace that bit back in the MagRocket API to this commit. https://github.com/nin9creative/magrocket-api/commit/52d46b1420974471e8f038c0b10781ee5f488a56

However it may have been a bug from the beginning of time.

Anyway, that needs to be fixed (removing that line).

So what happens, does the data get added correctly to the PURCHASES table? Does the receipt get logged in the RECEIPTS table?

[rogerdcarvalho]

yeah thats the weird thing. It gets logged correctly in the receipts table and then you continue to Marking single issue as purchased. After that it checks again and something goes wrong.

[rogerdcarvalho]

aaah i think i've got it. I disabled iTunes caching for the publication while troubleshooting. When I turn caching back to 12 hours it (seems to) work again.... Will continue on testing

[rogerdcarvalho]

YES! I tested with 2 different accounts, both single purchases and subscriptions and it seems to continue to work! Indeed, why Apple wanted to frustrate developers like this is beyond me as well. But I think this one can be closed now!

Solution is to remove the '$product_id = $data->receipt->product_id;' right after 'if (!isset($data->status) || ($data->status != 0 && $data->status != 21006))' within 'function verifyReceipt($receipt, $app_id, $user_id, $sandbox_override = FALSE)' in index.php of the latest master of the Baker Cloud API.

Now let's hope nothing else breaks when I move this to production.....

[AndrewAZ]

I just downloaded the backend framework today off of the baker website. Will I have to modify the code in the message above, or has it been fixed in the last 2 months?

[nin9creative]

This was fixed in this Bug Fix commit. https://github.com/bakerframework/bakercloud-ce-api/commit/0cca9aa4cad44a35ce598c98ed97f8fd1782c364

It is tagged as part of the 1.1.1 API release, which is the same one that is linked to off of the Baker website.

However you'll need to check when you downloaded the file...  If it was recent then you probably have the right one.  If it's a few months old, then probably not.

If you open the API index.php file you should see a version number at the top (around line 36).

Andrew

---

From: AndrewAZ notifications@github.com To: bakerframework/baker baker@noreply.github.com Cc: Andrew andrew@nin9creative.com Sent: Sunday, February 16, 2014 9:21 PM Subject: Re: [baker] Testing sandbox purchases with production magrocket server (#65)

I just downloaded the backend framework today off of the baker website. Will I have to modify the code in the message above, or has it been fixed in the last 2 months? — Reply to this email directly or view it on GitHub.