Last Comment Bug 707994 - Implement navigator.mozApps.verifyReceipt
: Implement navigator.mozApps.verifyReceipt
Status: RESOLVED WONTFIX
:
Product: Core
Classification: Components
Component: DOM (show other bugs)
: unspecified
: x86 Mac OS X
: P1 normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Andrew Overholt [:overholt]
Mentors:
: 710289 (view as bug list)
Depends on: 701409 709288
Blocks: 746465
  Show dependency treegraph
 
Reported: 2011-12-06 10:39 PST by Anant Narayanan [:anant]
Modified: 2013-04-04 13:53 PDT (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Anant Narayanan [:anant] 2011-12-06 10:39:12 PST
Currently verifyReceipt is implemented, but only for the native-shell: https://github.com/mozilla/openwebapps/blob/develop/addons/jetpack/data/native-install/XUL/content/window.js#L142

This code should be shared across all the other mozApps implementations, which are currently the add-on and HTML5 shim.
Comment 1 Anant Narayanan [:anant] 2011-12-15 15:53:27 PST
*** Bug 710289 has been marked as a duplicate of this bug. ***
Comment 2 Jason Smith [:jsmith] 2012-04-09 17:32:32 PDT
Did this feature get implemented? What's the status on this?
Comment 3 [:fabrice] Fabrice Desré 2012-04-09 17:37:56 PDT
(In reply to Jason Smith from comment #2)
> Did this feature get implemented? What's the status on this?

It's not implemented on m-c.
Comment 4 Ian Bicking (:ianb) 2012-04-10 08:11:54 PDT
There's an open design question here: do we still want to implement verifyReceipt?
Comment 5 Jason Smith [:jsmith] 2012-04-10 10:32:17 PDT
(In reply to Ian Bicking (:ianb) from comment #4)
> There's an open design question here: do we still want to implement
> verifyReceipt?

What benefits does our stakeholders using verifyReceipt get for it existing? What cost is lost for it not existing?

Clarification - Is verifyReceipt a convenience function to operate against marketplace's receipt validation service? Or it something else?
Comment 6 Ian Bicking (:ianb) 2012-04-10 11:01:21 PDT
For the most part, verifyReceipt could be implemented as a JS file, a kind of helper that we provide, but don't need to specifically include as part of the mozApps API.  That is, there's no special abilities we need, and no hard security advantage to providing it natively (though there might be some soft advantages).

I believe the actual verifyReceipt function was probably too complicated to be part of the mozApps API - it also included some options for various levels of app security.  We'd want to distill a smaller API from it, and allow supporting libraries cover app policies.
Comment 7 Anant Narayanan [:anant] 2012-04-10 11:11:05 PDT
Ian is right, there are no hard advantages to including it as part of the mozApps API (and is definitely not part of the spec). The original implementation in the add-on served two purposes:

- A vehicle to prototype apps that depended on receipt validation quickly
- Provide sample code to app developers who wanted to know what the "right" way to validate a receipt was

Most serious developers will want to do receipt verification themselves, but for some smaller scale apps the thinking was that verifyReceipt() would serve as a nice convenience function, when the app developer trusts the web run-time to a certain extent.
Comment 8 Jason Smith [:jsmith] 2012-05-30 21:35:34 PDT
Is this bug still valid, given that Ian is actively working on https://github.com/mozilla/receiptverifier to be integrated into mozmarket.js per bug 755006 and bug 758733?
Comment 9 Ian Bicking (:ianb) 2012-05-30 21:38:29 PDT
I believe the library supersedes this function.
Comment 10 Jason Smith [:jsmith] 2012-05-30 21:39:04 PDT
Okay. Resolving as a won't fix then.

Note You need to log in before you can comment on or make changes to this bug.