View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010124 | Taler | specification | public | 2025-06-23 13:47 | 2025-07-05 21:48 |
| Reporter | sebasjm | Assigned To | |||
| Priority | low | Severity | tweak | Reproducibility | have not tried |
| Status | acknowledged | Resolution | open | ||
| Target Version | post-1.0 | ||||
| Summary | 0010124: include password management / auth reset in dd49 | ||||
| Description | so we have the same API * libeufin use `old_password` and `new_password` in the /auth endpoint for password reset. * merchant the client ask for a token to change the password and use that token. | ||||
| Tags | No tags attached. | ||||
|
|
I am not sure about putting the account management in DD49 unless you really want THE SAME management API. It seems to me that the only thing (you) actually want is a password change API like the one in bank. The only thing to think about in that case (if we add it to merchant) is how to manage the rest of the account. For example, maybe the "normal" instance management through the /auth endpoint should not allow you to change the PW and instead always the (new) endpoint must be used. |
|
|
Notice also that merchant supports different authentication methods (well actually just one, password and nothing) whereas bank accounts do not. My suggestions: Modification 1) Add a PATCH [/instances/$INSTANCE]/private/auth API to merchant that mirrors https://docs.taler.net/core/api-corebank.html#patch--accounts-$USERNAME-auth Modification 2) Remove the ability to set the password in POST [/instances/$INSTANCE]/private/auth API of the merchant. Otherwise, you can always circumvent the password setting and/or simply disable authentication setting with an appropriate token. Idea: Maybe restrict this endpoint to admin access, e.g. specify a specific permission commonly not used by the SPA for this endpoint. Doing so allows us to keep the API semantics and solve the "problem" through access control. |
|
|
> It seems to me that the only thing (you) actually want is a password change API like the one in bank. No, as I said: If this is not strictly better we should not solve the same problem in 2 different ways I'm ok with following with the merchant API semantics but then we should adapt libeufin to handle this way I have also said that "i'm ok with not doing this right now". I just want to keep both API consistent. If we know that this is a better approach on how we want to handle password management / scope permission then we should create a issue in libeufin backlog for the future and move on |
|
|
We should indeed strive for consistency, I'm not yet sure what'll be the best resolution. But anyway, I'm not sure this one has a particularly high priority... |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-06-23 13:47 | sebasjm | New Issue | |
| 2025-06-23 16:23 | schanzen | Note Added: 0025325 | |
| 2025-06-23 16:23 | schanzen | Note Edited: 0025325 | |
| 2025-06-23 16:24 | schanzen | Note Added: 0025326 | |
| 2025-06-23 16:25 | schanzen | Note Edited: 0025326 | |
| 2025-06-23 16:28 | schanzen | Note Edited: 0025326 | |
| 2025-06-23 16:29 | schanzen | Note Edited: 0025326 | |
| 2025-06-23 18:14 | sebasjm | Note Added: 0025328 | |
| 2025-07-05 21:48 | Christian Grothoff | Priority | normal => low |
| 2025-07-05 21:48 | Christian Grothoff | Severity | minor => tweak |
| 2025-07-05 21:48 | Christian Grothoff | Status | new => acknowledged |
| 2025-07-05 21:48 | Christian Grothoff | Target Version | => post-1.0 |
| 2025-07-05 21:48 | Christian Grothoff | Note Added: 0025424 |
