View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0008783 | Taler | merchant portal webui | public | 2024-05-01 07:39 | 2024-05-15 16:01 |
| Reporter | Christian Grothoff | Assigned To | sebasjm | 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 | fixed | ||
| Platform | i7 | OS | Debian GNU/Linux | OS Version | squeeze |
| Product Version | git (master) | ||||
| Target Version | 0.11 | Fixed in Version | 0.11 | ||
| Summary | 0008783: merchant SPA fails to URL encode bearer token | ||||
| Description | Florian reported that the merchant backend hangs when trying to set the following password: "@;#.G?gFT=%G;7a" I investigated, and this *was* a problem in libgnunetutils' URL decoder, that failed baldy when the input wasn't URL-encoded, and "%G" isn't "%" followed by a 2-digit number ;-). However, after fixing the URL decoder, this still leaves an issue in the SPA, as the Authorization header should be URL-encoded. Otherwise, the user could enter tokens that basically break the HTTP protocol because of use of characters that just should not be in an HTTP header. Basically, only printable ASCII (7-bit) is 'safe' for HTTP headers (see https://www.rfc-editor.org/rfc/rfc7230#section-3.2.4). As users could use "anything" in passwords, the SPA needs to URL-encode them before submission. The backend always did URL decoding already... This may also explain some of my more spectacular failures to set/reset passwords. | ||||
| Tags | No tags attached. | ||||
| creating the instance works curl 'http://merchant.taler.test:1180/management/instances' \ -H 'Authorization: Bearer secret-token:E2BQ184AG4HJKKT4CFRXR1YAM0WCK39HXYZN8JVMEK5MKGPTYM7G' \ --data-raw '{"id":"eee","user_type":"business","use_stefan":true,"default_pay_delay":{"d_us":7200000000},"default_wire_transfer_delay":{"d_us":172800000000},"name":"eee","auth":{"method":"token","token":"secret-token:%25%25%25"},"address":{},"jurisdiction":{}}' \ but getting the token doesn't curl 'http://merchant.taler.test:1180/instances/eee/private/token' \ -H 'Authorization: Bearer secret-token:%25%25%25' \ --data-raw '{"scope":"write","duration":{"d_us":"forever"},"refreshable":true}' { "code": 43, "hint": "The service refused the request as the given authorization token is malformed." } SPA is encoding the user input after 20353eda2..5db79542f | |
| When the token endpoint works, please assign it back to me so I can check the SPA before making a prebuilt | |
| Eh, it shouldn't be URL-encoded in the JSON! Only in the HTTP header! | |
| fixed in bf03157b6..f062d9f77 | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-05-01 07:39 | Christian Grothoff | New Issue | |
| 2024-05-01 07:39 | Christian Grothoff | Status | new => assigned |
| 2024-05-01 07:39 | Christian Grothoff | Assigned To | => sebasjm |
| 2024-05-03 12:20 | sebasjm | Note Added: 0022335 | |
| 2024-05-03 12:20 | sebasjm | Assigned To | sebasjm => Christian Grothoff |
| 2024-05-03 14:49 | sebasjm | Note Added: 0022337 | |
| 2024-05-03 15:07 | Christian Grothoff | Note Added: 0022338 | |
| 2024-05-03 15:07 | Christian Grothoff | Assigned To | Christian Grothoff => sebasjm |
| 2024-05-06 16:14 | sebasjm | Status | assigned => informing |
| 2024-05-06 16:14 | sebasjm | Resolution | open => fixed |
| 2024-05-06 16:14 | sebasjm | Note Added: 0022361 | |
| 2024-05-15 15:53 | Christian Grothoff | Fixed in Version | => 0.11 |
| 2024-05-15 16:01 | Christian Grothoff | Status | informing => closed |
| 2026-08-23 14:18 | Florian Dold | Category | merchant backoffice SPA => merchant portal webui |