Closed
Bug 862588
Opened 11 years ago
Closed 11 years ago
No longer require apps to use HTTPS for in-app payments
Categories
(Marketplace Graveyard :: Payments/Refunds, defect, P3)
Tracking
(Not tracked)
RESOLVED
FIXED
2013-08-13
People
(Reporter: kumar, Assigned: kumar)
References
Details
(Whiteboard: [qa-])
To make a developer's life easier, no longer require HTTPS for in-app payments. See this thread for rationale: https://groups.google.com/d/msg/mozilla.dev.webapps/4cSWLJ-3Ahs/L5C5gjFUqikJ Summary: - SSL certs can be bought cheaply in the US/Europe - However, certs might be prohibitively expensive in some economies (like emerging markets) - SSL is *not* required to make in-app payments secure - SSL will probably make replay attacks harder if the app is susceptible to such As part of this feature, let's add these things to the docs: - a big red warning urging developers to use HTTPS if possible - an explanation of replay attacks and how to protect an app against replays
Assignee | ||
Updated•11 years ago
|
Blocks: marketplace-payments
Priority: -- → P3
Updated•11 years ago
|
Comment 1•11 years ago
|
||
Okay, I'm confused. Is the work in this bug client-side in the mozPay level, gaia system level, and/or marketplace level?
Assignee | ||
Comment 2•11 years ago
|
||
It's entirely at the marketplace level; it does not impact the client in any way. Is it ok to block bug 775802 for our tracking purposes?
Comment 3•11 years ago
|
||
(In reply to Kumar McMillan [:kumar] from comment #2) > It's entirely at the marketplace level; it does not impact the client in any > way. Is it ok to block bug 775802 for our tracking purposes? Yes, that makes sense.
Assignee | ||
Updated•11 years ago
|
Assignee: nobody → kumar.mcmillan
Comment 4•11 years ago
|
||
I think it is important to note in the implementation of this that no PII is allowed to be sent over a non-HTTPS connection, which means that in general the marketplace <-> app developer server communication cannot contain PII.
Assignee | ||
Comment 5•11 years ago
|
||
what is PII?
Comment 6•11 years ago
|
||
(In reply to Kumar McMillan [:kumar] from comment #5) > what is PII? Personally identifiable information: people's names, email addresses, social security numbers, addresses, phone numbers, other unique identifiers mapped to a person.
Assignee | ||
Comment 7•11 years ago
|
||
Ah, good point. Mozilla would never send this information but a developer might transmit this information unknowningly in the productData JWT field. I'll add a warning in the docs to urge developers not to send PII.
Assignee | ||
Updated•11 years ago
|
Target Milestone: --- → 2013-07-25
Assignee | ||
Updated•11 years ago
|
Target Milestone: 2013-07-25 → 2013-08-01
Assignee | ||
Updated•11 years ago
|
Target Milestone: 2013-08-01 → 2013-08-08
Assignee | ||
Updated•11 years ago
|
Target Milestone: 2013-08-06 → 2013-08-13
Assignee | ||
Comment 8•11 years ago
|
||
This fix has landed: https://github.com/mozilla/webpay/commit/638d50138cc42d951f615c83a146bce103c8c8bb The documentation has a scary callout about the risks of using HTTP postbacks: https://developer.mozilla.org/en-US/docs/Web/Apps/Publishing/In-app_payments#Use_HTTPS_postback.2Fchargeback_URLs
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Comment 9•11 years ago
|
||
Please add STR here or mark it with [qa-] if no QA is needed.
Flags: needinfo?
Assignee | ||
Comment 10•11 years ago
|
||
STR would be: - set up an app to do in-app payments per https://developer.mozilla.org/en-US/docs/Web/Apps/Publishing/In-app_payments - configure the app with an HTTP postback - make a non-simulated payment which means setting up a fake bank account in dev/stage These steps are non-trivial so if you want to make it as [qa-] then I'll leave it up to you. Here's an example app that you could work from: https://github.com/kumar303/inapp-pay-test
Flags: needinfo?
Comment 11•11 years ago
|
||
I'm not sure how to make a non-simulated payment using the app you provided. I'll mark it as [qa-]
Whiteboard: [qa-]
You need to log in
before you can comment on or make changes to this bug.
Description
•