View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004993 | Taler | exchange | public | 2017-04-23 00:51 | 2017-06-06 14:18 |
| Reporter | Marcello Stanisci | Assigned To | Christian Grothoff | ||
| Priority | high | Severity | tweak | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Product Version | git (master) | ||||
| Target Version | 0.3 | Fixed in Version | 0.3 | ||
| Summary | 0004993: aggregator needs to authenticate | ||||
| Description | Due to recent changes, the bank's /admin/add/incoming, used to perform wire transfers from account A to account B, requires username and password of the client using this API, among the POSTed data. The aggregator thus must provide the following JSON: { "amount": {"value": x, "fraction": y, "currency": "z"}, "wtid": "wtid_string", "exchange_url": "https://exchange_url", "credit_account": n, "username": "Exchange", "password": "" } Yes, for the moment the bank assigns a "" password to the Exchange user, but that's another (not reported yet) issue. | ||||
| Tags | No tags attached. | ||||
|
|
This is incredibly ugly as an authentication mechanism. Can't we at least use something like HTTP digest authentication where the PW is not transmitted in the clear, and where the nonce provides some minimal protection against replay attacks? MHD supports this. |
|
|
I'm pretty sure this ugly way came out from some discussion we had. In any case, note there is no MHD involved, as this API is offered by the bank, and used by the aggregator, that goes with libcurl. |
|
|
Well, Django and curl also support digest authentication: https://github.com/juanriaza/django-rest-framework-digestauth https://curl.haxx.se/libcurl/c/CURLOPT_HTTPAUTH.html As far as our discussion is concerned, I recall saying that we should authenticate using username/password, but I don't recall discussing a precise specification. |
|
|
digestauth package is unfortunate - fails hard on installation (the last commit on the project dates back 2014). Do we still want this authentication? We can fall back to the old approach: run the /admin/add/incoming service on some protected interface. Opinions? (peel) mstan@tripwire:~$ pip3 install djangorestframework-digestauth Collecting djangorestframework-digestauth Downloading djangorestframework-digestauth-1.1.0.tar.gz Complete output from command python setup.py egg_info: Traceback (most recent call last): File "<string>", line 1, in <module> File "/tmp/pip-build-vituz1c9/djangorestframework-digestauth/setup.py", line 52 print "You probably want to also tag the version now:" ^ SyntaxError: Missing parentheses in call to 'print' ---------------------------------------- Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-build-vituz1c9/djangorestframework-digestauth/ |
|
|
Implemented in 27c921c..405859d. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2017-04-23 00:51 | Marcello Stanisci | New Issue | |
| 2017-04-23 00:51 | Marcello Stanisci | Status | new => assigned |
| 2017-04-23 00:51 | Marcello Stanisci | Assigned To | => Christian Grothoff |
| 2017-04-23 20:11 | Christian Grothoff | Note Added: 0012059 | |
| 2017-04-24 11:04 | Marcello Stanisci | Note Added: 0012060 | |
| 2017-04-24 11:26 | Christian Grothoff | Note Added: 0012061 | |
| 2017-04-26 11:21 | Marcello Stanisci | Note Added: 0012068 | |
| 2017-04-26 11:22 | Marcello Stanisci | Note Edited: 0012068 | |
| 2017-05-03 02:19 | Christian Grothoff | Priority | normal => high |
| 2017-05-03 02:19 | Christian Grothoff | Severity | minor => tweak |
| 2017-05-03 02:19 | Christian Grothoff | Product Version | => git (master) |
| 2017-05-03 02:19 | Christian Grothoff | Target Version | => 0.3 |
| 2017-05-04 11:19 | Christian Grothoff | Note Added: 0012099 | |
| 2017-05-04 11:19 | Christian Grothoff | Status | assigned => resolved |
| 2017-05-04 11:19 | Christian Grothoff | Resolution | open => fixed |
| 2017-05-04 11:19 | Christian Grothoff | Fixed in Version | => 0.3 |
| 2017-06-06 14:18 | Christian Grothoff | Status | resolved => closed |
