Closed
Bug 705814
Opened 13 years ago
Closed 13 years ago
Alter receipt to include store data
Categories
(addons.mozilla.org Graveyard :: API, defect, P2)
addons.mozilla.org Graveyard
API
Tracking
(Not tracked)
RESOLVED
FIXED
6.3.8
People
(Reporter: andy+bugzilla, Assigned: andy+bugzilla)
References
Details
Receipts need to be altered so we can include arbitrary store data. Use case: developer A has app on domain x.com, 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.
Proposal:
Currently the product field is:
product: "https://grumpybadgers.com",
But we could change this to a JSON object structure for example:
product: {
name: "https://grumpybadgers.com",
productid: "grumpybadgers-first-generation",
storedata: "123"
},
product: {
name: "https://grumpybadgers.com",
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.
Comment 1•13 years ago
|
||
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?
Assignee | ||
Comment 2•13 years ago
|
||
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 | ||
Updated•13 years ago
|
Assignee: nobody → amckay
Comment 3•13 years ago
|
||
(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?
Comment 4•13 years ago
|
||
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.
Updated•13 years ago
|
Priority: -- → P3
Updated•13 years ago
|
Target Milestone: 6.3.3 → 6.3.4
Comment 5•13 years ago
|
||
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
Updated•13 years ago
|
Priority: -- → P3
Target Milestone: 6.3.3 → 6.3.4
Assignee | ||
Comment 6•13 years ago
|
||
Show the productID in the receipt be just a string then and have seperate receipts for free, basic, premium etc.
Assignee | ||
Comment 7•13 years ago
|
||
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.
Updated•13 years ago
|
Target Milestone: 6.3.4 → 6.3.8
Updated•13 years ago
|
Priority: P3 → P2
Assignee | ||
Comment 8•13 years ago
|
||
https://github.com/mozilla/zamboni/commit/82c954
No changes to the manifest at this time.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Updated•9 years ago
|
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•