View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0008353 | Taler | mechant backend | public | 2024-02-08 19:27 | 2024-03-07 20:49 |
| Reporter | sebasjm | Assigned To | sebasjm | ||
| Priority | urgent | Severity | major | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Product Version | git (master) | ||||
| Target Version | 0.9.4 | Fixed in Version | 0.9.4 | ||
| Summary | 0008353: already_paid_order_id should not include refunded order | ||||
| Description | get getting the state of an order https://docs.taler.net/core/api-merchant.html#get-[-instances-$INSTANCE]-private-orders-$ORDER_ID if a repurchase is detected, already_paid_order_id contain the order id of a previously paid order even if the order was refunded. in our demo frontend pages refunded orders are not enough to grant access to an article and make the field obsolete and confusing. workaround until fix: ignoring the field | ||||
| Tags | No tags attached. | ||||
| related to | 0008137 | confirmed | sebasjm | simplify merchant frontend order creation |
| child of | 0008364 | closed | Christian Grothoff | test, package and upload merchant 0.10 to ftp and stable Debian/Ubuntu server |
|
|
we should also consider that paid and partially refunded articles (of a previous pruchased order) may still be enough for other merchant so i'm not sure that "excluding refunded artciles from repurchase detection" is right. worst case of won't fix: * if the merchant wants to look for the latest paid then it can query /private/orders with session_id, fulfillment_url and refunded="no" * if refunded means no access (like in blog) then this field is useless |
|
|
When the order is refunded and the merchant creates a new order on the same session, it will be imposible to pay since: curl "http://merchant.taler.test:1180/instances/blog/orders/2024.039-03M93WKBY94FJ?token=QH8RZ2WH9EVMXG68PR8WBYZQX8&session_id=e1dd1902-3059-4915-a54d-28e4f44c1ba8" -v -H "Accept: text/html" < HTTP/1.1 302 Found < Location: http://localhost:8080/en/essay/Software_Patents_and_Literary_Patents From the docs: > In the case that the request was made with a claim token (even the wrong one) and the order was claimed and paid, the server will redirect the client to the > fulfillment URL. This redirection will happen with a 302 status code if the “Accept” header specified “text/html”, and with a 202 status code otherwise. Repurchase detection should not consider refunded orders. Or we can add a request param to avoid taking it into consideration if we want backward compatiblity and handle both cases |
|
|
I propose that we add a query parameter: "allow-refunded-for-repurchase" so that the paywall logic can simply decide if refunded orders should be included in refund detection or not. That should cover both relevant use-cases, right? I think it's OK if we have a (very minor) backwards-compatibility break an default to "no", thus "suddenly" not returning the refunded articles anymore. WDYT? Would this address the issue for you? |
|
|
This fix will the problem BUT right now: [A] if the frontend's session has an order => query status /orders/{ID}, repurchase may be detected with the sessionId [B] else if the frontend session dont have an order => query oders /orders?sessionid=XXX&fullfilment=XX&refund=no, checking for repurchase again else create a new one This can seen here https://git.taler.net/taler-merchant-demos.git/tree/talermerchantdemos/blog/blog.py?id=200b658d3152774345a4dbd6adfb10f62581233a#n373 This will be the main procedure to be implemented for frontend (mobile or web) so an easier procedure should be considered... that said what if we have an endpoint like this: /private/orders/latest-purchase?known-order={ID}&fulfillment=YYY&session=XXX&allow-refunded=no 1. will simplify 2 request into 1 in frontend 2. order id is optional (since the first time customer always go through [B] case) 3. if order is present in request param it behaves like /orders/{ID} and the allow-refunded flag affect already_paid_order_id field 4. this is only for storefront (/private/ endpoint) like our demo blog |
|
|
I think we should change to my proposed minimal protocol change to fix this. e5f80467..0a839007 (docs.git) documents the minimal required change (protocol v9). |
|
|
a63ae8bba773b5e2371ee82c23ba1172d9465bfe (merchant.git) should fix this. Please confirm (and if so, mark as resolved). |
|
|
i'm getting "request_payment" page instead of "offer_refund" when the order is refunded. When the user goes to the "order_status_url" More info: for a session bounded order that is refunded, private endpoint $ curl -s "http://merchant.taler.test:1180/instances/blog/private/orders/2024.054-035CYSACWQKK4?token=63DGHB9P2NR15AZ6DAPATGE9FG&session_id=60858596-f82c-45ea-bc7c-22d4fc0d8873&h_contract=Y7XTJJ8BCA6MQ1666BRNWCCGYJNTTGQF08AQYPS14CB0V1DB7JEZQY4EXMVVTCK4J1PPVP0S8Z634X1260N5KW6NSQ70TM7WKST4KP" | jq .refunded true getting the "payment request" in the public endpoint $ curl "http://merchant.taler.test:1180/instances/blog/orders/2024.054-035CYSACWQKK4?token=63DGHB9P2NR15AZ6DAPATGE9FG&session_id=60858596-f82c-45ea-bc7c-22d4fc0d8873&h_contract=Y7XTJJ8BCA6MQ1666BRNWCCGYJNTTGQF08AQYPS14CB0V1DB7JEZQY4EXMVVTCK4J1PPVP0S8Z634X1260N5KW6NSQ70TM7WKST4KP0" { "taler_pay_uri": "taler+http://pay/merchant.taler.test:1180/instances/blog/2024.054-035CYSACWQKK4/60858596-f82c-45ea-bc7c-22d4fc0d8873?c=63DGHB9P2NR15AZ6DAPATGE9FG", "fulfillment_url": "http://localhost:7777/en/essay/GNU-FSF_cooperation_update" } showing the json version which is equivalent. Also, _IF_ i add the new request parameter it fails with HTTP 500 $ curl -s "http://merchant.taler.test:1180/instances/blog/orders/2024.054-035CYSACWQKK4?token=63DGHB9P2NR15AZ6DAPATGE9FG&session_id=60858596-f82c-45ea-bc7c-22d4fc0d8873&h_contract=Y7XTJJ8BCA6MQ1666BRNWCCGYJNTTGQF08AQYPS14CB0V1DB7JEZQY4EXMVVTCK4J1PPVP0S8Z634X1260N5KW6NSQ70TM7WKST4KP0&allow_refunded_for_repurchase=yes" { "code": 53, "hint": "The service failed to fetch information from its database. The system administrator should check that the database is running and review the service logs.", "detail": "order by fulfillment" } LOGS INFO Handling request (GET) for URL '/instances/blog/orders/2024.054-035CYSACWQKK4' ERROR Assertion failed at pq_eval.c:231. |
|
|
1a695f0..ed0a154 should fix this. I also added a first test for repurchase detection. Please confirm! |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-02-08 19:27 | sebasjm | New Issue | |
| 2024-02-08 19:27 | sebasjm | Status | new => assigned |
| 2024-02-08 19:27 | sebasjm | Assigned To | => Christian Grothoff |
| 2024-02-08 19:38 | sebasjm | Note Added: 0021215 | |
| 2024-02-08 21:37 | sebasjm | Note Added: 0021217 | |
| 2024-02-08 21:45 | sebasjm | Relationship added | related to 0008137 |
| 2024-02-09 00:49 | Christian Grothoff | Relationship replaced | child of 0008137 |
| 2024-02-09 14:15 | Christian Grothoff | Note Added: 0021223 | |
| 2024-02-09 14:15 | Christian Grothoff | Assigned To | Christian Grothoff => sebasjm |
| 2024-02-09 14:15 | Christian Grothoff | Status | assigned => feedback |
| 2024-02-09 22:47 | sebasjm | Note Added: 0021232 | |
| 2024-02-09 22:47 | sebasjm | Assigned To | sebasjm => Christian Grothoff |
| 2024-02-10 00:18 | Christian Grothoff | Priority | normal => urgent |
| 2024-02-10 00:19 | Christian Grothoff | Relationship added | child of 0008364 |
| 2024-02-10 00:20 | Christian Grothoff | Relationship replaced | parent of 0008137 |
| 2024-02-10 00:20 | Christian Grothoff | Relationship added | parent of 0007956 |
| 2024-02-10 00:21 | Christian Grothoff | Relationship added | parent of 0008363 |
| 2024-02-10 00:21 | Christian Grothoff | Relationship added | parent of 0008358 |
| 2024-02-10 00:21 | Christian Grothoff | Relationship added | parent of 0008279 |
| 2024-02-10 00:22 | Christian Grothoff | Relationship added | parent of 0008276 |
| 2024-02-10 11:39 | Christian Grothoff | Note Added: 0021238 | |
| 2024-02-10 12:33 | Christian Grothoff | Relationship deleted | parent of 0007956 |
| 2024-02-10 12:33 | Christian Grothoff | Relationship deleted | parent of 0008137 |
| 2024-02-10 12:33 | Christian Grothoff | Relationship deleted | parent of 0008276 |
| 2024-02-10 12:33 | Christian Grothoff | Relationship deleted | parent of 0008279 |
| 2024-02-10 12:33 | Christian Grothoff | Relationship deleted | parent of 0008358 |
| 2024-02-10 12:34 | Christian Grothoff | Relationship deleted | parent of 0008363 |
| 2024-02-10 13:16 | Christian Grothoff | Note Added: 0021239 | |
| 2024-02-10 13:16 | Christian Grothoff | Assigned To | Christian Grothoff => sebasjm |
| 2024-02-23 14:44 | sebasjm | Note Added: 0021479 | |
| 2024-02-23 14:44 | sebasjm | Assigned To | sebasjm => Christian Grothoff |
| 2024-02-23 14:45 | sebasjm | Severity | minor => major |
| 2024-02-23 15:16 | sebasjm | Relationship added | related to 0008137 |
| 2024-02-24 17:54 | Christian Grothoff | Note Added: 0021485 | |
| 2024-02-24 17:54 | Christian Grothoff | Assigned To | Christian Grothoff => sebasjm |
| 2024-03-05 14:08 | sebasjm | Target Version | 0.10 => 0.9.4 |
| 2024-03-05 15:17 | sebasjm | Status | feedback => resolved |
| 2024-03-05 15:17 | sebasjm | Resolution | open => fixed |
| 2024-03-07 09:20 | Christian Grothoff | Product Version | 0.10 => git (master) |
| 2024-03-07 09:20 | Christian Grothoff | Fixed in Version | => 0.9.4 |
| 2024-03-07 20:49 | Christian Grothoff | Status | resolved => closed |
