Closed Bug 705814 Opened 11 years ago Closed 11 years ago

Alter receipt to include store data


( Graveyard :: API, defect, P2)



(Not tracked)



(Reporter: andy+bugzilla, Assigned: andy+bugzilla)



Receipts need to be altered so we can include arbitrary store data. Use case: developer A has app on domain, they then lose the domain, developer B puts an app on the same domain, legitimately. Currently this would mean all receipts from for developer A work for developer B.

For AMO, this would be just a matter of including our pk in the app to distinguish them.


Currently the product field is:

	product: "",

But we could change this to a JSON object structure for example:

	product: {
		name: "",
		productid: "grumpybadgers-first-generation",
		storedata: "123"

	product: {
		name: "",
		productid: "grumpybadgers-second-generation",
		storedata: "678"

Productid would be a field that's shown to the end user so they can distinguish between the two apps.

Storedata would be a field where the store could put whatever information they want in that's relevant to the store. For AMO we'd just stuck our uid in there.

This would provide enough information for us to get receipts verified correctly.
This sounds reasonable to me; when you say "end user" you mean it would be used by the consuming application, yes?

The expected recovery flow for Grumpy Badgers 2 could then be:

* Pull receipt from local storage
* Inspect product/productid
* Notice that the string is wrong
* Trigger a reinstall/repurchase flow

Anant, any thoughts on the verify function flow?
I remember at one point we spoke about something that would be shown by the consuming application to the end user to indicate that something has changed. But looking at this now I'm unclear what the use case is.
Assignee: nobody → amckay
(In reply to Michael Hanson from comment #1)
> Anant, any thoughts on the verify function flow?

Assuming that productid is provided by the app developer at the time of submission to the store, we should also add the same field to the manifest. Then, when verifyReceipt() is called, we can check to see if the productid in the receipt matches the one found in the manifest for that application.

This essentially means that an app is now uniquely identified by a combination of the origin and the productid. Thoughts?
So... that's possible, but I had thought that it might make sense to have more than one productID for a given app.  I had thought we could use it for free, basic, and premium editions, for example.
Priority: -- → P3
Target Milestone: 6.3.3 → 6.3.4
In that case we could allow an array of productIDs in a manifest. I think the main point is to have it live somewhere outside of (and in addition to) the receipt for it to be actually useful to the app developer; and the manifest seems like a good fit.
Priority: P3 → --
Target Milestone: 6.3.4 → 6.3.3
Priority: -- → P3
Target Milestone: 6.3.3 → 6.3.4
Show the productID in the receipt be just a string then and have seperate receipts for free, basic, premium etc.
Ugh that has an incoherent comment. Let's try again. 

The productID in each receipt should be a string, with a seperate receipt for free, basic, premium etc.
Target Milestone: 6.3.4 → 6.3.8
Priority: P3 → P2
Blocks: 710074
No longer blocks: 690899

No changes to the manifest at this time.
Closed: 11 years ago
Resolution: --- → FIXED
Product: → Graveyard
You need to log in before you can comment on or make changes to this bug.