939021 - [UITest][API] Fix and improve mozPay tests

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia, defect)

Description

[Tom Jao [:mbrsl]]

mozPay test in UITest app is not working due to CSP and other problems.

Comment 1

[Tom Jao [:mbrsl]]

I found that it's actually not CSP problem.

When you pressed button, it shows somthing like "PAY_REQUEST_ERROR_NO_VALID_REQUEST_FOUND." It may be caused by the change of UITest app itself or the change of gecko.
mozPay seems to be rather complex that I don't know if there is a simple way to test it.

Ferjm, would you please take a look of it? It's under test_apps/uitest/API/pay.js, thank you.

Comment 2

[Tom Jao [:mbrsl]]

There're some small errors in pay.js and needed to be fixed. PAY_REQUEST_ERROR_NO_VALID_REQUEST_FOUND shows only after pay.js is fixed.

Comment 3

[Fernando Jiménez Moreno [:ferjm]]

The reason why you are getting a PAY_REQUEST_ERROR_NO_VALID_REQUEST_FOUND error is probably because none of the JWT that you are passing to mozPay contains a valid 'typ' value. Understanding valid as one of the registered payment providers via preferences. Check [1].

It seems that the mozPay test is a JWT with 'mock/payments/inapp/v1' as 'typ' value, so in order to make it work you need to have something like this in your preferences:

pref("dom.payment.provider.1.name", "payprovider");
pref("dom.payment.provider.1.description", "pay provider");
pref("dom.payment.provider.1.uri", "https://paymentprovideruri.com");
pref("dom.payment.provider.1.type", "mock/payments/inapp/v1");
pref("dom.payment.provider.1.requestMethod", "GET");

So given that, I think that it would be great if we could:
1. Set this preference by default in the eng builds to point to the chosen payment provider
2. (optional but desired) Run a local payment provider, so the tests can be run offline and independent of a remote server. Not sure if this is possible though.

[1] https://wiki.mozilla.org/WebAPI/WebPayment#Testing

Comment 4

[Tom Jao [:mbrsl]]

Attachment: https://github.com/mozilla-b2g/gaia/pull/14248

Fernando, would you please review the codes for me? Thank you.

I includes an additional library from https://github.com/michaelrhanson/jwt-js so that we can encode JWT much easier for testing purpose. For the payment preference, there's a payment-dev-prefs.js in gaia/build directory and we can use it for JWT generation.

Local payment provider sounds rather complicated so I filed a following bug 945132. Not sure if we can solve this problem.

Comment 5

[[e-mail]]

Comment on attachment 8340916 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/14248

I have no idea of mozPay API yet, may alive have better knowledge of it?

Comment 6

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 8340916 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/14248

I'm not sure if we could put the js file in the code base.

Comment 7

[Fernando Jiménez Moreno [:ferjm]]

Comment on attachment 8340916 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/14248

Sorry for the late review and thanks for this fix :).

I am not really convinced about adding the JWT library. IIRC we don't need to sign the JWT, which is the hardest part, cause the signature verification only happens in the server side. We only decode the JWT and check the payload part in the client. So the only thing that you need to do is to normalize and base 64 encode the payment request, which is quite straight forward. Check [1] to see the platform counter part that decodes the request.

[1] https://mxr.mozilla.org/mozilla-central/source/dom/payment/Payment.jsm#259

Comment 8

[Tom Jao [:mbrsl]]

So don't we have to pass the verification of payment provider? Without valid signature, gecko will submit the request without error (since the JWT format is correct.) However, the request will not be accepted by payment provider.

It seems that we can only embed the generated signed JWT in this test if we don't sign it dynamically. A JWT with long enough iat/exp time should work fine.

Comment 9

[Fernando Jiménez Moreno [:ferjm]]

The more I think about this the more I am convinced about the need of turning this into an offline test. We are mostly interested on testing the client side, but it would also be great to have a tool to do the whole mozPay + WebPay flow. So what I would really like to do here is:

1- Add Kumar's in-app pay test app [1] to the eng builds, which would allow us to test the whole mozPay + WebPay flow.

2- Turn this test into an offline one using a very simple and local payment provider similar to the one at [2]. The code for this one is at [3]. This would allow us to test the client side of mozPay in a better way as we control both sides, the client and the payment provider.

Feel free to assign this bug to me if you are not interested on doing these changes.

[1] https://github.com/kumar303/inapp-pay-test
[2] http://ferjm.github.io/simplepayprovider/page1.html
[3] https://github.com/ferjm/simplepayprovider/tree/gh-pages

Comment 10

[Kumar McMillan [:kumar]]

I agree that there should be an offline test of mozPay(). If we can specify a local pay provider in prefs with file://... or something then it should be possible.

Comment 11

[Fernando Jiménez Moreno [:ferjm]]

Yes, we can probably add a pay provider with app:// URL

Comment 12

[Fernando Jiménez Moreno [:ferjm]]

We'll need to enable the dom.payments.skipHTTPSCheck pref in eng builds or add an 'origin' field to the uitest app manifest.

Comment 13

[Tom Jao [:mbrsl]]

(In reply to Fernando Jiménez Moreno [:ferjm] (use needinfo instead of CC, please) from comment #9)
> Feel free to assign this bug to me if you are not interested on doing these
> changes.
Thank you, I'm rather unfamiliar with payment provider :(

(In reply to Fernando Jiménez Moreno [:ferjm] (use needinfo instead of CC, please) from comment #12)
> We'll need to enable the dom.payments.skipHTTPSCheck pref in eng builds or
> add an 'origin' field to the uitest app manifest.
As far as I know, the pref file for payment in eng builds is gaia/build/payment-dev-prefs.js and dom.payment.skipHTTPSCheck was set to true in this file.

Comment 15

[Fernando Jiménez Moreno [:ferjm]]

Attachment: v1

Finally it wasn't possible to use an installed payment provider. For some reason, the injection of the mozPaymentProvider API is not working properly with installed payment providers. So I just added appcache to the one at [1], so the tests can be run offline after the first run.

I've also added Kumar's in-app payments app as a external app to test the mozPay flow with the Marketplace payment provider.

[1] http://ferjm.github.io/gaia-mock-payment-provider/

Comment 16

[Fernando Jiménez Moreno [:ferjm]]

I will be adding silent SMS tests and service ID tests to https://github.com/ferjm/gaia-mock-payment-provider so we can test all the pieces of the mozPaymentProvider API.

Comment 17

[Zac C (:zac)]

(In reply to Fernando Jiménez Moreno [:ferjm] from comment #15)
> Created attachment 8365048 [details] [review]
> v1
> 
> Finally it wasn't possible to use an installed payment provider. For some
> reason, the injection of the mozPaymentProvider API is not working properly
> with installed payment providers. So I just added appcache to the one at
> [1], so the tests can be run offline after the first run.
> 
> I've also added Kumar's in-app payments app as a external app to test the
> mozPay flow with the Marketplace payment provider.
> 
> [1] http://ferjm.github.io/gaia-mock-payment-provider/

Hi Ferjm, I'm not 100% sure I'm the right person to r? this as I've been out of the loop on payment stuff for a while so I'm not sure what the success criteria are. I applied the patch anyway and had a fiddle around however I could not make a successful install after payment. However if this patch is only to add the apps/bits to the build then they are present and functional and r+.

It also is affected by https://bugzilla.mozilla.org/show_bug.cgi?id=963582 at the moment.

Comment 18

[Fernando Jiménez Moreno [:ferjm]]

Thanks Zac,

(In reply to Zac C (:zac) from comment #17) 
> Hi Ferjm, I'm not 100% sure I'm the right person to r? this as I've been out
> of the loop on payment stuff for a while so I'm not sure what the success
> criteria are. I applied the patch anyway and had a fiddle around however I
> could not make a successful install after payment. However if this patch is
> only to add the apps/bits to the build then they are present and functional
> and r+.
> 

You won't be able to install any app with Kumar's in-app pay test or the UI tests as the only flow that we are testing with these apps is the payment flow.

> It also is affected by https://bugzilla.mozilla.org/show_bug.cgi?id=963582
> at the moment.

I haven't tried to reproduce bug 963582, but yes, that should affect this bug.

Comment 19

[Zac C (:zac)]

Comment on attachment 8365048 [details] [review]
v1

Ok thanks ferjm, I'll leave it to you to get it merged now.

Comment 20

[Fernando Jiménez Moreno [:ferjm]]

Comment on attachment 8365048 [details] [review]
v1

Thanks Zac.

Adding r=zac per comment 17

Comment 21

[Fernando Jiménez Moreno [:ferjm]]

https://github.com/mozilla-b2g/gaia/pull/15683
https://github.com/mozilla-b2g/gaia/pull/15771