Developer payload argument for in-app billing?
I've picked this concept six ways from Sunday, and I feel like I can't find a direct answer to it. the google docs say this is not meant for security, but then a bunch of answers that I think imply otherwise, etc.
From the docs:
The fifth argument contains the "developer payload" string that you can use to send additional order information (this can be an empty string). If you provide a string value, Google Play will return the string along with the purchase response. Subsequently, when you make inquiries about this purchase, Google Play returns this string along with the purchase details.
Caveat: do not use developer's Payload field to check the security of the target. This field is not always available when performing tasks related to In-app Billing. For more information on security best practices, see the Security and Application Design Guide.
From the official google test project:
/** Verifies the developer payload of a purchase. */
boolean verifyDeveloperPayload(Purchase p) {
String payload = p.getDeveloperPayload();
/*
* TODO: verify that the developer payload of the purchase is correct. It will be
* the same one that you sent when initiating the purchase.
*
* WARNING: Locally generating a random string when starting a purchase and
* verifying it here might seem like a good approach, but this will fail in the
* case where the user purchases an item on one device and then uses your app on
* a different device, because on the other device you will not have access to the
* random string you originally generated.
*
* So a good developer payload has these characteristics:
*
* 1. If two different users purchase an item, the payload is different between them,
* so that one user purchase can't be replayed to another user.
*
* 2. The payload must be such that you can verify it even when the app wasn't the
* one who initiated the purchase flow (so that items purchased by the user on
* one device work on other devices owned by the user).
*
* Using your own server to store and verify developer payloads across app
* installations is recommended.
*/
return true;
}
I have no idea what this means. If I don't have my own server, should I just use an empty string? How should I differentiate between users and purchases and devices?
None of this is clear to me, and this code / official docs provide no real clarification, and most of the online answers are similarly sparse.
Could someone just describe this: what should I send as the utility argument of my design?
source to share
At least you have a security reason for generating a random string: two identical purchases with different versions of DeveloperPayload will always have different purchase and signature details.
String developerPayload = UUID.randomUUID().toString();
If you are not processing responses on your server, you have no reason to remember and test this line (see warning when testing Google).
source to share
The last note in google code seems to be helpful
Using your own server to store and validate developer payloads is recommended to use presets.
If you have a server, you might have an endpoint getRandomString
that the server creates and adds to the list of available random strings associated with a user account.
When a string is returned to the client, it can be used as a developer payload.
Then, when it comes to validating the purchase token on the server, you can grab the payload and check for a list of available random strings on the server.
However, I'm not sure if this adds any security per se. And I don't see how it helps "through app installs". Because for managed products, regardless of the app installation, you cannot buy multiple managed products. They must be consumed before they can be purchased again ...
You ended up solving your problem. I would be interested to know what you did at the end as I ran into the same problem, only I have a server end.
source to share