View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006445 | Taler | merchant backend | public | 2020-07-25 19:17 | 2024-01-12 13:04 |
| Reporter | Christian Grothoff | Assigned To | Christian Grothoff | Resolution deadline | |
| Implementer | Reviewer | ||||
| Release signed by | Deployed by | ||||
| Verifier | Communicator | ||||
| Data protection authority notification required | No | ||||
| CSIRT notification required | No | ||||
| Estimated effort (hours) | Actual effort (hours) | 0 | |||
| Fast-track | No | ||||
| Work package | none | ||||
| Priority | high | Severity | major | Reproducibility | always |
| Status | closed | Resolution | reopened | ||
| Platform | i7 | OS | Debian GNU/Linux | OS Version | squeeze |
| Product Version | git (master) | ||||
| Target Version | 0.8 | Fixed in Version | 0.8 | ||
| Summary | 0006445: POST /private/orders is not idempotent | ||||
| Description | If a client posts _exactly_ the same request to /private/orders *with* an order_id specified (!), we currently generate an error. Instead, we should create exactly the same response a 2nd time. (Note that this ONLY applies if the client includes the order_id; if there is no order_id, we create one at random so the 2nd response would be different.) Fixing this requires additional logic to check that the request has an order_id and that we have exactly the same order (with the same terms) in the database. This is a bit tricky, as we modify/patch the order (adding merchant details, etc.), so really we can only do the idempotentcy check _after_ patching the incoming order. | ||||
| Tags | No tags attached. | ||||
| implemented in 859675f..b90d7d2. | |
| Actually, the fix doesn't work, I just encountered this with my WooCommerce tests. You do: if (1 == json_equal (order, contract_terms)) which likely fails because the stored contract_terms have been modified by the backend, and either (didn't check): - the 'order' has not yet been modified - the modifications are not exactly the same, say because we are adding some relative time as an offset and then the result ends up _slightly_ different. So yeah, getting this right will be a bit funky. :-( I propose we only compare a few fields: - products - summary / summary_i18n - fulfillment_url - locations - total price - order_id (doh) - auto_refund - extra and leave out the timestamps. Hopefully that'll work... | |
| c0f9922..6f8c224 implements a more principled approach by storing the hash of the original POST request into the DB and we check against that for idempotency. | |
| Deployments updated. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2020-07-25 19:17 | Christian Grothoff | New Issue | |
| 2020-07-25 19:17 | Christian Grothoff | Status | new => assigned |
| 2020-07-25 19:17 | Christian Grothoff | Assigned To | => jonathanbuchanan |
| 2020-08-02 02:01 | jonathanbuchanan | Status | assigned => informing |
| 2020-08-02 02:01 | jonathanbuchanan | Resolution | open => fixed |
| 2020-08-02 02:01 | jonathanbuchanan | Note Added: 0016540 | |
| 2020-08-06 23:44 | Christian Grothoff | Fixed in Version | => 0.8 |
| 2020-09-03 21:46 | Christian Grothoff | Assigned To | jonathanbuchanan => Christian Grothoff |
| 2020-09-03 21:46 | Christian Grothoff | Assigned To | Christian Grothoff => jonathanbuchanan |
| 2020-09-03 21:50 | Christian Grothoff | Status | informing => feedback |
| 2020-09-03 21:50 | Christian Grothoff | Resolution | fixed => reopened |
| 2020-09-03 21:50 | Christian Grothoff | Note Added: 0016832 | |
| 2020-09-04 23:47 | Christian Grothoff | Assigned To | jonathanbuchanan => Christian Grothoff |
| 2020-09-04 23:47 | Christian Grothoff | Priority | normal => high |
| 2020-09-04 23:47 | Christian Grothoff | Status | feedback => assigned |
| 2020-09-05 11:20 | Christian Grothoff | Note Added: 0016869 | |
| 2020-09-05 11:27 | Christian Grothoff | Status | assigned => informing |
| 2020-09-05 11:27 | Christian Grothoff | Note Added: 0016870 | |
| 2021-08-24 14:23 | Christian Grothoff | Status | informing => closed |
| 2024-01-12 13:04 | Christian Grothoff | Category | merchant backend API (C) => mechant backend |
| 2025-03-22 13:09 | Christian Grothoff | Category | mechant backend => merchant backend |