View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009556 | Taler | specification | public | 2025-02-17 18:14 | 2025-03-22 22:12 |
| Reporter | Florian Dold | Assigned To | schanzen | ||
| Priority | low | Severity | feature | Reproducibility | have not tried |
| Status | assigned | Resolution | open | ||
| Target Version | 1.1 | ||||
| Summary | 0009556: address merchant auth token weirdness | ||||
| Description | * The /token endpoint currently takes only a **Bearer** token as auth and returns another Bearer token. Instead, the /token endpoint should accept credentials via basic auth (and a Bearer token only when refreshing a token). * For human-picked passwords (that are not auth tokens!), we should not require the secret-token: prefix. That prefix should only be necessary for *actual* tokens, not for login credentials. * The response body isn't consistent with the bank (auth_token vs token). | ||||
| Tags | No tags attached. | ||||
| related to | 0009646 | assigned | Florian Dold | Merchant authentication/token API not (fully documented) |
|
|
"Instead, the /token endpoint should accept credentials via basic auth (and a Bearer token only when refreshing a token)." plus "For human-picked passwords (that are not auth tokens!), we should not..." Needs further clarification: Is the (/private/token) endpoint ONLY supposed to accept "human-picked" passwords (or refresh tokens)? Are there any other type of credentials? What kind of credential is the configured access token going to become? My working assumption is also that this mainly related to the slightly messy taler-merchant-httpd.c:1883ff code, is that right? (If yes, this will require some rework regarding a lot of security-critical logic.) |
|
|
The answers (until now) are: The instance has a password, which can be set, for example, with taler-merchant-passwd. This password can and must be used for /private/token requests to get an access token. The access token can be used on all the other (private) APIs. Open question: What about the /auth endpoint (https://docs.taler.net/core/api-merchant.html#post-[-instances-$INSTANCE]-private-auth). It seems to have special case handling. It would be treated like any other API, I think, but somebody thought something else here it seems... |
|
|
I just now realized that this change will require new testing cmds to retrieve the access tokens and probably most tests needs to be modified in order to reflect the change. |
|
|
Started working on this here https://git.gnunet.org/merchant.git/log/?h=dev/schanzen/issue_9556 |
|
|
We also may have to/want to invalidate all tokens issued before a new password is set! |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-02-17 18:14 | Florian Dold | New Issue | |
| 2025-02-17 18:14 | Florian Dold | Status | new => assigned |
| 2025-02-17 18:14 | Florian Dold | Assigned To | => Christian Grothoff |
| 2025-02-17 20:13 | Christian Grothoff | Assigned To | Christian Grothoff => |
| 2025-02-17 20:13 | Christian Grothoff | Status | assigned => confirmed |
| 2025-02-17 20:13 | Christian Grothoff | Category | mechant backend => specification |
| 2025-03-21 15:00 | schanzen | Relationship added | related to 0009646 |
| 2025-03-21 15:00 | schanzen | Assigned To | => schanzen |
| 2025-03-21 15:00 | schanzen | Status | confirmed => assigned |
| 2025-03-22 11:17 | schanzen | Note Added: 0024279 | |
| 2025-03-22 18:07 | schanzen | Note Added: 0024282 | |
| 2025-03-22 21:30 | schanzen | Note Added: 0024283 | |
| 2025-03-22 21:39 | schanzen | Note Added: 0024284 | |
| 2025-03-22 22:12 | schanzen | Note Added: 0024285 |
