902946 - CSP failure in receiptverifier.js

Status: RESOLVED FIXED

(Marketplace Graveyard :: Payments/Refunds, defect, P1)

Description

[Andrew Williamson [:eviljeff]]

fails CSP in privileged apps - https://github.com/mozilla/receiptverifier/blob/master/receiptverifier.js#L1068

new Function(...) is blocked for privileged apps.

Comment 1

[Andy McKay]

We should do this soon, its blocking a privileged app verifying receipts.

Comment 2

[Kumar McMillan [:kumar]]

good catch eviljeff. Hmm, this might simply be a documentation fix telling apps how to allow it.

Comment 3

[Kumar McMillan [:kumar]]

whoops, I was mixing up CSP with CORS. Apps cannot solve this. The lib just needs to stop doing 'new Function()' it seems. http://people.mozilla.org/~bsterne/content-security-policy/details.html

Comment 4

[Andy McKay]

The fact that receiptverifier has a templating engine and a few hundred lines of template generation code seems odd to me. I would imagine most apps would have their own way of doing templating and showing messages to users. The key part is the checking.

I'm going to split the lib into two parts, the checking part and the templating part, the templating part will be available as a demo, great for quick example testing, but not for real use. Or perhaps we can deprecate that.

Comment 5

[Andrew Williamson [:eviljeff]]

/agree 
- I think just returning the string for the app to display would be better (+ it would be more consistent in the app's own UX and easier to localise)

Comment 6

[Ian Bicking (:ianbicking)]

Part of the reasoning behind a complete UI is that these failures are kind of corner-cases, and I'm not sure if applications would handle them properly unless it's super-easy to do so.  But splitting it into two parts would certainly make sense – one that gives the app a code of sorts to indicate what kind of error there is (and the UI stuff is slightly higher level than the receipt validator itself) and then something that takes that puts up an appropriate blocking error message based on that.

Comment 7

[Andy McKay]

https://github.com/mozilla/receiptverifier/commit/99ecbbb09

Comment 8

[Ian Bicking (:ianbicking)]

Also the templating is not fancy, so replacing it with string replacement would be fine, e.g.:

  message = template.replace(/URL/g, quote(url));

Comment 9

[Andy McKay]

(In reply to Ian Bicking (:ianb) from comment #6)
> Part of the reasoning behind a complete UI is that these failures are kind
> of corner-cases, and I'm not sure if applications would handle them properly
> unless it's super-easy to do so.  

That's true, keeping it easy is an important part of adoption which is our biggest hurdle at the moment.