Changes

Page history
docs: Revising test checklist documentation authored by stephen's avatar stephen 
The test checklist documentation was a little shaggy, a little out of date, and a little out of order. Both it and its copy-paste-capable twin have been updated as per the current state of the site.
Show whitespace changes
Inline Side-by-side
service/donate.md
View page @ 9448238e
......@@ -31,57 +31,89 @@ and deploys a staging version at
<https://staging.donate-review.torproject.net/.
It's possible to fill in the donation form on this page, and use [Stripe test
credit card numbers][] for the payment information. When a donation is
credit card numbers] for the payment information. When a donation is
submitted on this form, it should be processed by the PHP middleware and
inserted into the [staging CiviCRM instance](https://staging.crm.torproject.org/). It should also be visible
in the "test" Stripe interface.
Note that it is _not_ possible to test _real_ credit card numbers on sites using
the "test" Stripe interface, just like it is not possible to use testing card
numbers on sites using the "real" Stripe interface.
[Stripe test credit card numbers]: https://stripe.com/docs/testing?testing-method=card-numbers#cards
### Crypto tests
The same is true for Paypal: A separate "sandbox" application is created for
testing purposes, and a test user is created and attached that application
for the sake of testing. Said user is able to make both one-time and recurring
transactions, and the states of those transactions are visible in the "sandbox"
Paypal interface. And as with Stripe, it is not possible to make transactions
with that fake user outside of that sandbox environment.
The authentication for that fake, sandboxed user should be available in the
password store. (TODO: Can someone with access confirm/phrase better?)
### NAIVE USER SITE TESTS
| # | What are we proving | Who's Testing? | Start when? | How are we proving it |
|---|------------------------------------------------------------------------------------|----------------|------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 1 | Transaction goes through and Sue confirms it | Al,Sue | ASAP | Al? makes a transaction, Sue confirms receipt |
| 2 | Post-transaction screen deemed acceptable (and if we have to make one, we make it) | Al, Stephen | ASAP (before sue's vacation) | Al? makes a transaction, livestreams or screenshots result |
| 3 | Ensure that QR codes behave as expected when scanned with wallet app | Al?, Stephen | ASAP | Someone with a wallet app should scan each QR code and ensure that the correct crypto address for the correct cryptocurrency is populated in the app, in whichever manner is expected - this should not require us to further ensure that the wallet app itself acts as intended, unless that is desired |
|----|------------------------------------------------------------|-----------------|-------------|---------------------------------------------------------------------------------------------------|
| 1 | Basic tire-kicking testing of non-donation pages and links | Tor staff (any) | 27 August | FAQ, Crypto page, header links, footer links; note any nonfunctional link(s) - WRITE INSTRUCTIONS |
| 2 | Ensure test-card transactions are successful - this is a site navigation / design test | Tor staff | 27 August | Make payment with test cards; take screenshot(s) of final result OR anything that looks out of place, noting OS and browser; record transactions in google sheet - MATT WRITES INSTRUCTIONS |
### Tor staff / naive user credit card tests
### Crypto tests
| # | What are we proving | Who's Testing? | Start when? | How are we proving it |
|-----|----------------------------------------------------------------------------------------------------|----------------|-------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 4 | Ensure gift card credit card transactions are successful - this is a site navigation / design test | Tor staff, | 27 August | Make payment with gift card; take screenshot(s) of final result OR anything that looks out of place, noting OS and browser; record transactions in google sheet - MATT WRITES INSTRUCTIONS |
| 5 | Test PayPal interface using naive users and dummy PayPal info | Tor staff | 27 August | take screenshots as above, noting OS and browser |
| 5.5 | Check these transactions against staging CiviCRM | Matt | 27 August | |
|---|------------------------------------------------------------------------------------|----------------|------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 3 | Ensure that QR codes behave as expected when scanned with wallet app | Al, Stephen | ASAP | Someone with a wallet app should scan each QR code and ensure that the correct crypto address for the correct cryptocurrency is populated in the app, in whichever manner is expected - this should not require us to further ensure that the wallet app itself acts as intended, unless that is desired |
| 4 | Post-transaction screen deemed acceptable (and if we have to make one, we make it) | Al, Stephen | ASAP (before sue's vacation) | Al? makes a transaction, livestreams or screenshots result |
| 5 | Sue confirms that transaction has gone through to Tor wallet | Al, Sue | ASAP | Al/Stephen make a transaction, Sue confirms receipt
### CiviCRM recording
### Mock transaction testing
| # | What are we proving | Who's Testing? | Start when? | How are we proving it |
|-----|-----------------------------------------------------------------------|----------------|-------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 6 | Ensure credit card one-time payments are tracked | Matt, Stephen | ~27 August | Make payment with for-testing CC# and conspicuous donor name, then check donation list in CiviCRM |
| 6.5 | Ensure credit card transaction against live card operates as expected | Matt, Stephen | ~27 August | **If changes don't need to be made to live settings to accomplish**: Make payment with ML's CC, check donation list in CiviCRM, check Stripe |
| 7 | Ensure credit card errors are not tracked | Matt, Stephen | ~27 August | Make payment with for-testing intentionally-error-throwing CC# (4000 0000 0000 0002) and ensure CiviCRM does not receive data. Ideally, ensure event is logged |
| 8 | Ensure Paypal one-time payments are tracked | Matt, Stephen | ~27 August | Make payment with Paypal account, then check donation list in CiviCRM |
| 8.5 | Ensure Paypal transaction against live account is tracked | Matt, Stephen | ~27 August | **If changes don't need to be made to live settings to accomplish**: Make payment with ML's account, check donation list in CiviCRM, check Paypal |
| 9 | Ensure Stripe webhooks catch behavior properly | Matt, Stephen | ~27 August | Use Stripe webhook testing tools to generate events and test output - may involve changing webhook endpoint in Stripe backend to donate-neo staging |
| 10 | Ensure Paypal webhooks catch behavior properly | Matt, Stephen | ~27 August | Use Paypal webhook testing tools to generate events and test output - may involve changing webhook endpoint in Paypal backend to donate-neo staging |
| 8 | Ensure Paypal one-time payments are tracked | Matt, Stephen | ~27 August | Make payment with for-testing Paypal account, then check donation list in CiviCRM |
| 9 | Ensure Stripe recurring payments are tracked | Matt, Stephen | ~27 August | Make payment with for-testing CC# and conspicuous donor name, then check donation list in CiviCRM (and ensure type is "recurring") |
| 10 | Ensure Paypal recurring payments are tracked | Matt, Stephen | ~27 August | Make payment with for-testing Paypal account, then check donation list in CiviCRM (and ensure type is "recurring") |
### Stripe clock testing
### GENERAL SITE TESTS
Note: Stripe does not currently allow for clock tests to be performed
with preseeded invoice IDs, so it is currently not possible to perform
clock tests in a way which maps CiviCRM user data or donation form
data to the donation. Successful Stripe clock tests will appear in
CiviCRM Staging as anonymous.
| # | What are we proving | Who's Testing? | Start when? | How are we proving it |
|----|------------------------------------------------------------|-----------------|-------------|---------------------------------------------------------------------------------------------------|
| 11 | Basic tire-kicking testing of non-donation pages and links | Tor staff (any) | 28 August | FAQ, Crypto page, header links, footer links; note any nonfunctional link(s) - WRITE INSTRUCTIONS |
|-----|-----------------------------------------------------------------------|----------------|-------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 11 | Ensure future credit card recurring payments are tracked | Matt, Stephen | ~27 August | Set up clock testing suite in Stripe backend with dummy user and for-testing CC# which starts on ~27 June or July, then advance clock forward until it can be rebilled. Observe behavior in CiviCRM (the donation will be anonymous as noted above). |
### Stripe and Paypal recurring transaction webhook event testing
| # | What are we proving | Who's Testing? | Start when? | How are we proving it |
|-----|-----------------------------------------------------------------------|----------------|-------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 12 | Ensure future credit card errors are tracked | Matt, Stephen | ~27 August | Trigger relevant webhook event with Stripe testing tools, inspect result as captured by CiviCRM |
| 13 | Ensure future Paypal recurring payments are tracked | Matt, Stephen | ~27 August | Trigger relevant webhook event with Paypal testing tools, inspect result as captured by CiviCRM |
| 14 | Ensure future Paypal errors are tracked | Matt, Stephen | ~27 August | Trigger relevant webhook event with Stripe testing tools, inspect result as captured by CiviCRM |
### NEWSLETTER SIGNUP
| # | What are we proving | Who's Testing? | Start when? | How are we proving it |
|----|------------------------------------------|----------------|-------------|-----------------------------------------------------------------------------------------------------------------------------------|
| 12 | Test standalone subscription form | Matt, Stephen | ~27 August | CiviCRM receives intent to subscribe and generates - and sends - a confirmation email |
| 13 | Test confirmation email link | Matt, Stephen | ~27 August | Donate-staging should show a success/thank-you page; user should be registered as newsletter subscriber in CiviCRM |
| 14 | Test "newsletter actions" | Matt, Stephen | ~27 August | Should be able to unsub/resub/cancel sub from bespoke endpoints & have change in status reflected in subscriber status in CiviCRM |
| 15 | Test donation form subscription checkbox | Matt, Stephen | ~27 August | Should generate and send confirmation email just like standalone form |
| 15 | Test standalone subscription form | Matt, Stephen | ~27 August | CiviCRM receives intent to subscribe and generates - and sends - a confirmation email |
| 16 | Test confirmation email link | Matt, Stephen | ~27 August | Donate-staging should show a success/thank-you page; user should be registered as newsletter subscriber in CiviCRM |
| 17 | Test donation form subscription checkbox | Matt, Stephen | ~27 August | Should generate and send confirmation email just like standalone form |
| 18 | Test "newsletter actions" | Matt, Stephen | ~27 August | Should be able to unsub/resub/cancel sub from bespoke endpoints & have change in status reflected in subscriber status in CiviCRM |
Here's the test procedure for step 12:
### POST LAUNCH transaction tests
| # | What are we proving | Who's Testing? | Start when? | How are we proving it |
|---|----------------------------------------------------------------------------------------------------|----------------|-------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 19 | Ensure gift card transactions are successful | Matt, Stephen | 10 September | Make payment with gift card and conspicuous donor name, then check donation list in CiviCRM |
| 20 | Ensure live Paypal transactions are successful | Matt, Stephen | 10 September | Make payments with personal Paypal accounts, then check donation list in CiviCRM |
Here's the test procedure for steps 15-17:
- https://staging.donate-review.torproject.net/subscribe/ (`tor-www` / blank)
- fill in and submit the form
......@@ -98,23 +130,24 @@ To be copy-pasted in an issue:
This is a summary of the checklist available in the TPA wiki:
#### General site testing
#### Naive user site testing
* [ ] 1 Basic tire-kicking testing of non-donation pages and links (Tor staff (any))
* [ ] 2 Donation form testing with test Stripe CC number (Tor staff (any))
#### BTCPay tests
* [ ] 2 Transaction goes through and Sue confirms it (Al,Sue)
* [ ] 3 Post-transaction screen deemed acceptable (and if we have to make one, we make it) (Al, Stephen)
* [ ] 4 Ensure that QR codes behave as expected when scanned with wallet app (Al?, Stephen)
* [ ] 3 Ensure that QR codes behave as expected when scanned with wallet app (Al?, Stephen)
* [ ] 4 Post-transaction screen deemed acceptable (and if we have to make one, we make it) (Al, Stephen)
* [ ] 5 Someone with Tor wallet access confirms receipt of transaction (Al, Sue)
#### Mock transaction testing
* [ ] 5 Ensure credit card one-time payments are tracked (Matt, Stephen)
* [ ] 6 Ensure credit card errors are not tracked (Matt, Stephen)
* [ ] 7 Ensure Paypal one-time payments are tracked (Matt, Stephen)
* [ ] 8 Ensure credit card recurring payments are tracked
* [ ] 9 Ensure Paypal recurring payments are tracked
* [ ] 6 Ensure credit card one-time payments are tracked (Matt, Stephen)
* [ ] 7 Ensure credit card errors are not tracked (Matt, Stephen)
* [ ] 8 Ensure Paypal one-time payments are tracked (Matt, Stephen)
* [ ] 9 Ensure credit card recurring payments are tracked
* [ ] 10 Ensure Paypal recurring payments are tracked
#### Stripe clock testing
......@@ -124,38 +157,35 @@ clock tests in a way which maps CiviCRM user data or donation form
data to the donation. Successful Stripe clock tests will appear in
CiviCRM Staging as anonymous.
* [ ] 10 Ensure future credit card recurring payments are tracked
* [ ] 11 Ensure future credit card errors are tracked
* [ ] 11 Ensure future credit card recurring payments are tracked
#### Paypal recurring transaction webhook event testing
#### Stripe and Paypal recurring transaction webhook event testing
Note: Paypal does not currently allow for webhook event tests to be
performed with preseeded invoice IDs, so it is currently not possible
to perform webhook tests against recurring transactions in a way which
maps CiviCRM user data or donation form data to the
donation. Successful Paypal clock tests will appear in CiviCRM Staging
as anonymous.
Neither Stripe nor Paypal allow for proper testing against recurring payments
failing billing, and Paypal itself doesn't even allow for proper testing of
recurring payments as Stripe does above. Therefore, we rely on a combination of
manual webhook event generation - which won't allow us to map CiviCRM user data
or donation form data to the donation, but which will allow for anonymous
donation events to be captured in CiviCRM - and unit testing, both in `donate-neo`
and `civicrm`.
* [ ] 12 Ensure future Paypal recurring payments are tracked
* [ ] 13 Ensure future Paypal errors are tracked
* [ ] 12 Ensure future credit card errors are tracked
* [ ] 13 Ensure future Paypal recurring payments are tracked
* [ ] 14 Ensure future Paypal errors are tracked
#### Newsletter infra testing
* [ ] 14 [Test standalone subscription form](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/service/donate#newsletter-signup) (Matt, Stephen)
* [ ] 15 Test confirmation email link (Matt, Stephen)
* [ ] 16 Test "newsletter actions" (Matt, Stephen)
* [ ] 15 [Test standalone subscription form](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/service/donate#newsletter-signup) (Matt, Stephen)
* [ ] 16 Test confirmation email link (Matt, Stephen)
* [ ] 17 Test donation form subscription checkbox (Matt, Stephen)
* [ ] 18 Test "newsletter actions" (Matt, Stephen)
#### Site goes live
#### Gift card testing
#### Live transaction testing
* [ ] 18 Ensure gift card credit card transactions are successful - this is a site navigation / design test (Tor staff)
* [ ] 19 Test PayPal interface using naive users and dummy PayPal info (Tor staff)
* [ ] 20 Check these transactions against staging CiviCRM (Matt)
* [ ] 21 Ensure credit card transaction against live card operates as expected (Matt, Stephen)
* [ ] 22 Ensure Paypal transaction against live account is tracked
(Matt, Stephen)
* [ ] 19 Ensure gift card credit card transactions are successful (Matt, Stephen)
* [ ] 20 Ensure live Paypal transactions are successful (Matt, Stephen)
# How-to
......@@ -309,6 +339,16 @@ present. A possible improvement to this might be to proactively add
IPs to the list once they cross a certain threshold and then redirect
users to a 403 page instead of giving a plain error code like this.
`donate-neo` implements IP rate limiting through [`django-ratelimit`](https://django-ratelimit.readthedocs.io/en/stable/).
It should be noted that while this library does allow rate limiting by IP,
as well as by various other methods, it has a known limitation wherein
information about the particular rate-limiting event is not passed outside
of the application core to the handlers of these events - so while it is
possible to log or generate metrics from a user hitting the rate limit,
those logs and metrics do not have access to _why_ the rate-limit event
was fired, or _what_ it fired upon. (The IP address can be scraped from the
originating HTTP request, at least.)
## Disaster recovery
A disaster, for the donation site, can take two major forms:
......@@ -476,15 +516,31 @@ Django stores data in SQLite database, in
Django fashion, it stores information about user sessions, users,
logs, and CAPTCHA tokens.
At present, `donate-neo` barely leverages Django's database; the
`django-simple-captcha` stores CAPTCHA images it generates there
(in `captcha_captchastore`), and that's all that's kept there beyond
what Django creates by default. Site copy is hardcoded into the templates.
`donate-neo` does leverage the Redis pool, which it shares with CiviCRM,
for a handful of transient get-and-set-like operations related to
confirming donations and newsletter subscriptions. While this was by design -
the intent being to keep all user information as far away from the front end
as possible - it is worth mentioning that the Django database layer could
also perform this work, if it becomes desirable to keep these operations out of Redis.
## Queues
Redis is used as a queue to process transactions from the frontend to
the CiviCRM backend. It handles those types of transactions:
- one-time donations
- recurring donations
- mailing list subscriptions (essentially a backend for
https://newsletter.torproject.org/)
- One-time donations (successful)
- Recurring donations (both successful and failed, in order to track
when recurring donations lapse)
- Mailing list subscriptions (essentially middleware between
https://newsletter.torproject.org and CiviCRM, so users have a way
to click a "confirm subscription" URL without exposing CiviCRM to the open web)
- Mailing list actions, such as "unsubscribe" and "optout" (acting as
middleware, as above, so that newsletters can link to these actions in the footer)
The Redis server runs on the CiviCRM server, and is accessed through
an IPsec tunnel, see the [authentication](#authentication) section below as
......@@ -492,7 +548,38 @@ well. The Django application reimplements the [resque](https://resque.github.io/
(originally written in Ruby, but ported to PHP by GiantRabbit) to pass
messages to the CiviCRM backend.
TODO: describe better the resque stuff.
Both types of donations and mailing list subscriptions are confirmed before
they are queued for processing by CiviCRM. In both cases, unconfirmed data
notionally bound for CiviCRM is kept temporarily as a key-value pair in Redis.
(See [Storage](#storage) above.) The keys for such data are created using information
unique to that transaction; payment-specific IDs are generated by payment providers,
whereas `donate-neo` creates its own unique tokens for confirming
newsletter subscriptions.
Donations are confirmed via incoming webhook messages from payment providers
(see [Interfaces](#interfaces) below), who must first confirm the validity of the
payment method. Webhook messages themselves are validated independently with the
payment provider; pertinent data is then retrieved from the message, which includes
the aforementioned payment-specific ID used to create the key which the form data
has been stored under.
Recurring donations which are being rebilled will generate incoming webhook messages,
but they will not pair with any stored form data, so they are passed along to CiviCRM
with a `recurring_billing_id` that CiviCRM uses to group them with a
recurring donation series.
Confirming mailing list subscriptions works similarly to confirming donations,
but we also coordinate the confirmation process ourselves.
Donors who check the "subscribe me!" box in the donation form generate
an initial "newsletter subscription requested" message (bearing the subscriber's
email address and a unique token), which is promptly queued as a Resque message;
upon receipt, CiviCRM generates a simple email to that user with a `donate-neo`
URL (containing said token) for them to click.
Mailing list actions have query parameters added to the URL by CiviCRM which
`donate-neo` checks for and passes along; those query parameters and their
values act as their own form of validation (which is CiviCRM-y, and therefore
outside of the purview of this writeup).
## Interfaces
......@@ -500,9 +587,18 @@ Most of the interactions with donate happen over HTTP. Payment
providers ping back the site with webhook endpoints which have to
bypass CSRF protections.
The views handling these endpoints are designed to only reply with HTTP
status codes (200 or 400). If the message is legitimate but was malformed
for some reason, the payment providers have enough context to know to try
resending the message; in other cases, we keep from leaking any useful data
to nosy URL-prodders.
## Authentication
TODO: do we have users in django, is the admin interface visible?
`donate-neo` does not leverage the Django admin interface, and the
`/admin` path has been excluded from the list of paths in `tordonate.url`;
there is therefore no front-end user authentication at all, whether for
users or administrators.
The public has access to the `donate` Django app, but not the
backend CiviCRM server. The app and the CiviCRM server talk to each
......
......