Our app uses Non-Renewable Subscriptions to provide access to content for one year. The subscription receipt is stored on iCloud (when available) and in the device keychain. There is also a WS that is called on occasion to validate the receipt but does not record the transaction.
Our problem is if the users change their clock backwards (say set the date to 2010), our subscription does not expire after one year but now three years (2013-2010).
Our solution was to say that subscriptions with a duration of more than one year are fraudulent and the receipt is cleared and life goes on.
However, my boss now is complaining about users that set the clock to six months in the past (less than one year so ok, but the subscription lasts for 1.5 years instead of the valid one year).
Is there a better way to be dealing with device clock tampering or is it something we have to live with (as I believe)?
If your app gets content from a server then you could store a list of "device-identifiers" combined with an expiration date.
Being on your server the client-time will have no voice on when the subscription is expired or not.
As I said in my comment above, I would check the time with a trusted server instead of using the local time. Just as important, once a receipt expires, immediately delete it or mark it as expired so that they can't turn off network access and roll back the time in order to use it.
Related
Paypal documentation for PayPal Sync API (https://developer.paypal.com/docs/api/sync/v1/).
It gives some mysterious date, named "last_refreshed_datetime".
On the sandbox server it is usually in the past, once it was a few days in the past, now it is 2 hours in the past.
What does it mean? How often it refreshes?
I only know that if I create a transaction it will not be visible on PayPal Sync API until the refresh date will not be later than the transaction date. And I'm guessing it should be the transaction approval date that does not presented on this report. The transaction approval date is available on transaction object (https://developer.paypal.com/docs/api/subscriptions/v1/#definition-transaction), it is called "time".
time string
The date and time when the transaction was processed, in Internet date and time format.
Read only.
I have reached out to the product development team for the SYNC API and have gotten the following clarifications in regards to your questions:
If the "last_refreshed_datetime" (Time until which we have data available in our system) is smaller than the requested end date then, in the API response we show end date as "last_refreshed_datetime". As we only have data up until that point. In general there should be around 4-6hrs of delay.
From my own experience on sandbox, on different occasions it was 6.5, 2.5 hours and even 2 days behind.
In my app, I get Lync Presence of our employees through UCWA. It works fine, but I need to knock to Lync with reportMyActivity every 3-4 minute.
I don't need to get presence info at night when employees are not at work, so I stop reportingMyActivity at the end of the working day and resume at it's beginning. Then trying to extend presence subscription, and if I get 404, I create new presence subscription. But no presence updates after those manipulations.
Is it designed to work this way? How could I avoid reportingMyActivity at night?
If you don't do reportMyActivity your Application will be drained, because assumed inactive.
I think you only have two options then:
Keep doing reportMyActivity regurarly also at night, you'll just stop extending presence subscription. Very likely you'll have to manage access token expiration too, which is normally 8 hours valid
You let the App shut down, and a complete new token acquisition, Application creation, presence subscription flow will start next morning
Folks,
I am attempting to verify that auto-renew subscriptions are actually renewing in the sandbox environment. First, it appears that auto-renew subscriptions in sandbox are only valid for 5 minutes. Makes sense. I expect that if I wait for five minutes, then make another call to
https://sandbox.itunes.apple.com/verifyReceipt
With my receipt data, I should see the subscription renewed with an expiry date another five minutes out.
Unfortunately that is not the case. All I see is a response with latest_expired_receipt_info and a status of 21006, which means "This receipt is valid but the subscription has expired" according to the Apple docs.
Can anyone tell me if they are able to test auto-renew subscriptions end-to-end, including this renew component? Or do I have to launch this app and cross my fingers that prod will work as advertised?
Alternatively, is there some sort of client-side magic/API call I have to run prior to re-posting my data to the verifyReceipt URL?
There was some discussion on this topic here, but it's not clear to me if I can/should expect to be able to re-verify subscriptions entirely on the server side by posting to the verifyReceipt URL or if I have to do something on the client side too.
Thanks!
Copied from the Apple's Developer Forum, for those not willing to goto the forum...
Figured it out (but not thanks to the Apple docs):
1 month subscriptions auto-renew every 5 minutes. So far so good. They
auto-renew 5 times and then they stop, so after 25 minutes you'll get
the 21006 error. However even when repurchasing the same subscription
it will NOT auto-renew again on the same test account since it has
already auto-renewed 5 times. So if you want to test renewal and you
have been messing with these subscriptions for a while you need to
create a new itunes connect test user. This is very annoying honestly
and it would be a lot easier if we could just reset the entire
purchase history of a test user account. Also putting all in-app
test information in the Xcode documentation would be a lot better as
opposed to spreading it over Xcode docs/iTunes Connect doc/people
figuring stuff out themselves
Hope this helps.
This conversation in the Apple dev forums may shed some light on this issue for others who discover this post: https://devforums.apple.com/thread/105350?tstart=0
#Lata Sadhwani, App developer
For testing auto-renew subscriptions, the expiration time is 5 minutes
in sandbox (at least for the monthly subscriptions, not sure if this
is different for different periods). So when testing an auto-renew
subscription in sandbox, it should auto-renew every 5 mins and you
know they are working correctly.
But there is one problem. These subscriptions auto-renew only 5 times
(i.e. the purchase happens 6 times). After that you'll get an error
when verifying the receipt. So if you want to test after that, you
will need to test with another IAP test account (yes it is a pain
testing, especially if you have been doing this for quite some time!)
To check if a subscription has been cancelled or is valid, your
receipt verification code will need to parse the response from Apple
servers and they say you should verify each receipt. If the
subscription has expired or has been cancelled, the appropriate error
code will be returned (a non-zero status). If it has been renewed by a
user, the most current receipt is returned by the Apple servers.
Sorry for the millionth question about iTunes subscriptions, but I still have a few doubts.
Basically I'm implementing auto-renewable subscriptions in my app and I want to make sure I got it right. Here's a list of steps to take that I came up with:
whenever an user buys a subscription, send the receipt to the server to validate it
if the receipt is valid, save it on the database
on application load, ask the server if a receipt for this UDID exists (this is to figure out if the user has a valid subscription)
if so, check if a new item has been added on the store in a date range from the subscription start date to the expire date
if any, notify the user about those items in some way and mark them as freely downloadable
Are these steps correct? And if so, why does the Apple doc say:
In most cases, your iOS client application should not need to change. In fact, your client application is now made simpler, as you can use the same code to recover auto-renewable subscriptions as you do to recover nonconsumable products. This is described in “Restoring Transactions.”Your application receives a separate transaction for each period of time where the subscription was renewed; your application should verify each receipt separately.
To me it looks like this needs some code to handle all the various cases I mentioned, instead. Or I'm totally wrong about it. Am I?
Plus, how do I know about the subscription expiration date? I can't find a way to get this information anywhere. Am I supposed to save this on my own database?
Update:
I've figured out a few things since I posted this question. Feel free to correct me if I'm wrong.
First of all I guess I'm supposed to store the length of the subscription somewhere on my own database, because as stated on Apple's docs, you cannot retrieve it in any way through Apple's web services. In fact, each subscription length has a different product identifier, so you should have a way to convert a product identifier to a subscription length.
Also, Sylvian has posted details about his implementation of auto-renewable subscriptions, so at least I know my thinking wasn't too much flawed.
Now the only problem is this: how do I know that an user has a valid subscription? I could store this information on my server, yeah, but how do I associate an user with a completed transaction? Should I save the device's UDID?
Here is how we implemented In App Purchases and specifically the new auto-renewable products at my company.
The application transmits the transaction receipt to our webservice, we return OK to the application if we handled it correctly and Apple could verify it. In that case we updated the user account (i.e. the database) to say "yes he has paid and his subscription is valid till the receipt expiration date".
After the OK for this webservice, the application reloads the account info through another webservice, and see there is a valid subscription. That was it... Until auto-renewable products appeared.
We now had to implement some CRON jobs which runs every day: every day we make a list of passes which are supposed to expire, and we ask Apple if the original receipt is still valid: the magic thing is that in their answer, there is a field latest-receipt which embeds the latest receipt. If it is not the same as the one we have, we understand that the subscription has been renewed automatically, we store the latest receipt for the next cron check, and we update the user account to extend the expiration date.
Hope it helps.
I think I found a solution. It doesn't require an additional username/password and it seems to be working.
Note: If you think this is inappropriate, please explain why in the comments. Thanks.
Basically, whenever an user buys a subscription, I validate the receipt against my server and store the receipt data in the user defaults. Then, when the app is opened, or whenever I need to check if the subscription is still valid, I retrieve the previously saved receipt data from the user defaults and validate it against the server.
My webservice just returns whether the subscription is still valid or has expired, plus some other related information such as the subscription length. To do this, it just queries the iTunes server as usual, and checks if the status response is nonzero. 21006 means that the subscription has expired.
If your app has some user management i.e. you use username/password to use the app, then you have to maintain a server to record the purchase/validity of the currently logged in user. This is applicable for normal subscription and non-consumable purchase. But... if you use the new auto-renewable subscription, then it's NOT possible to maintain multiple user in that app, because : this kind of purchase can not be done multiple times within the subscription period using the same Apple ID from the same application and I found it really annoying and finding a better solution for this case i.e where I have multiple child account in the app but I want to use the same Apple-Id to purchase a auto-renewable subscription for each account. And I think I have to use the old subscription model. Any new thoughts ?
as far as I have understand it the apple server will contact you (or the customer with his iPhone) and tell "look here I have a valid purchase for you". Inside your App you read this message and unlock the regarding content for use. The next step is to tell the apple server that you have responded to the receipt and the apple server will not show the message again.
So with a renewable subscription you get for each period a new message. Correct me if I'm wrong, please.
I am successfully fetching Apple APNS feedback data via PHP. The structure that I am getting (after some processing) looks something like this:
timestamp
device token
My question is how to know which of the device tokens should I remove from my database and stop sending notifications to them.
Regardz,
Mladjo
The timestamp is the crucial element here. The timestamp sent by Apple indicates the last time the push service attempted to deliver a message to the device and found the app to be uninstalled. If the device has re-registered with your service since then there is no need to delete it.
Therefore, every single time your app loads and sends the token to your service, you should log the time in your data store. When you run feedback you should check the time from Apple and compare it to the time you last received an update from the app on the device. If the time Apple sends is newer then the time you received an updated then you should delete (or disable) the device. If the time from Apple is earlier then you do not need to delete it because the user has reinstalled the device since Apple last tried to deliver.
All devices given by feedback are 'failed' and should be removed. No feedback means no devices should be removed. It's covered over on the Apple Documentation:
Apple APN Documentation
neat explanation #argon, however I have another question about the timestamp.
Every time when an app enables push notification, the device token is sent to the server. Should I taken the timestamp from my server as to be persisted along with device token as didRegisterForRemoteNotificationsWithDeviceToken only gives deviceToken and not time. If my server runs in different timezone and APNS is running at different timezone, then the registration time stored( along with device token) cannot be compared with timestamp received from APNS feedback to check the sequence of register -> uninstall -> reregister.
I presume the APNS feedback timestamp is in UTC and the timestamp the server stores along with device token has to be converted to UTC before storing the ISO timestamp. This way both the timestamp will be in same timezone and diff check will be consistent.
please clarify
#fyasar,
So your recommendation is to store the device token against device id(or some key). When a feedback is received for a device token, remove that device token row from DB, right? If have understood right, that wouldn't work in scenario were a user installs app, uninstalls it and then installs it again all with in a short duration and the feedback service was queried only after all this happened. In this case, if timestamp in feedback is not considered, device token will be removed which is incorrect as user has again installed the app and reregistered for push notification.
My question is this, as suggested in apple doc and many blogs, on registration, when device token is persisted, timestamp has to be persisted along with it. What time zone's ISO time should be persisted or what is the time zone on which feedback service returns the timestamp.
A timestamp (as a four-byte time_t value) indicating when APNs
determined that the app no longer exists on the device. This value,
which is in network order, represents the seconds since 12:00 midnight
on January 1, 1970 UTC.
you can compare it with your table's last insert time and then remove the invalid token from db, In my case i am using mysql and php for sever side
$sql="SELECT insert_time from device_tokens ORDER BY insert_time DESC LIMIT 1";
it will return last updated time from db and then i just convert it into epoch timestamp by using
$sql1="SELECT UNIX_TIMESTAMP(' $timestamp')";
and finally i just compare it with apns feedback timestamp like this
if($inactive_Timestamp>$dbTime_stamp)
{
foreach ($apnsfeedback_tokens as $key => $value) {
# code...
$inactive_Token=$value['devtoken'];
$sql= "DELETE FROM device_tokens WHERE device_token='$inactive_Token'";
if ($conn->query($sql) === TRUE) {
echo "Record deleted successfully";
} else {
echo "Error deleting record: " . $conn->error;
}
You should store devices with their device token data, and then you can find these devices according to their device tokens. You might use device token for identifier each device. Than would be easy to find and change their statuses into your db.