Closed Bug 939021 Opened 6 years ago Closed 6 years ago

[UITest][API] Fix and improve mozPay tests

Categories

(Firefox OS Graveyard :: Gaia, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: tjao, Assigned: ferjm)

References

Details

Attachments

(1 file, 1 obsolete file)

v1
46 bytes, text/x-github-pull-request
ferjm
: review+
Details | Review
mozPay test in UITest app is not working due to CSP and other problems.
Assignee: nobody → tjao
Blocks: eng-mode, 874735
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.
Flags: needinfo?(ferjmoreno)
No longer blocks: 874735
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.
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
Flags: needinfo?(ferjmoreno)
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.
Attachment #8340916 - Flags: review?(gasolin)
Attachment #8340916 - Flags: review?(ferjmoreno)
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?
Attachment #8340916 - Flags: review?(gasolin) → review?(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.
Attachment #8340916 - Flags: review?(alive) → feedback+
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
Attachment #8340916 - Flags: review?(ferjmoreno)
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.
Flags: needinfo?(ferjmoreno)
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
Flags: needinfo?(ferjmoreno)
Summary: [UITest][API] Fix mozPay test → [UITest][API] Fix and improve mozPay tests
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.
Yes, we can probably add a pay provider with app:// URL
We'll need to enable the dom.payments.skipHTTPSCheck pref in eng builds or add an 'origin' field to the uitest app manifest.
(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.
Assignee: tjao → ferjmoreno
Attachment #8340916 - Attachment is obsolete: true
Duplicate of this bug: 945132
Attached file 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/
Attachment #8365048 - Flags: review?(zcampbell)
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.
Attachment #8365048 - Flags: review?(florin.strugariu)
(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.
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.
Depends on: 963582
Comment on attachment 8365048 [details] [review]
v1

Ok thanks ferjm, I'll leave it to you to get it merged now.
Attachment #8365048 - Flags: review?(zcampbell)
Attachment #8365048 - Flags: review?(florin.strugariu)
Comment on attachment 8365048 [details] [review]
v1

Thanks Zac.

Adding r=zac per comment 17
Attachment #8365048 - Flags: review+
https://github.com/mozilla-b2g/gaia/pull/15683
https://github.com/mozilla-b2g/gaia/pull/15771
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.