View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004651 | Taler | exchange | public | 2016-09-12 13:41 | 2016-10-11 15:28 |
| Reporter | Florian Dold | Assigned To | Marcello Stanisci | 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 | normal | Severity | minor | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Product Version | 0.0 | ||||
| Target Version | 0.1 | Fixed in Version | 0.1 | ||
| Summary | 0004651: Should 'struct TALER_ContractPS' include receiver? | ||||
| Description | Right now, the TALER_ContractPS includes all information that is needed by the backend *except* for the payment receiver in the multi-account merchant scenario. We thus have to handle the receiver separately, and this defeats the purpose of having the TALER_ContractPS in the first place: The TALER_ContractPS does not only sign over the contract, but also over some fields extracted out of the contract that are required by the backend. IMHO we should either completely drop this optimization (for simplicity) or we should include the receiver field there. The receiver field is a bit awkward though, since it's a string, and thus we need to length-limit it or make TALER_ContractPS variable length. | ||||
| Tags | No tags attached. | ||||
| We should add the public key of the merchant, as that uniquely identifies the "receiver". The backend should be modified to check that the public keys are unique per receiver. | |
| all logic added, 'make check' fails. (Just incase, the code is on 'receiver' branch at merchant's git.) | |
| I'm confused. I don't see _any_ change in 'struct TALER_ContractPS', so how could that mean the logic was added!? | |
| Well, I've just modified the merchant to use hashmaps (as discussed) and check whether the keys are unique. I meant that for 'logic'. Nothing has been modified on TALER_ContractPS yet.. | |
| Fixed in: 0b8081fe, exchange 6d0eb81a, merchant | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-09-12 13:41 | Florian Dold | New Issue | |
| 2016-09-12 13:41 | Florian Dold | Status | new => assigned |
| 2016-09-12 13:41 | Florian Dold | Assigned To | => Christian Grothoff |
| 2016-09-18 22:57 | Christian Grothoff | Product Version | => 0.0 |
| 2016-09-18 22:57 | Christian Grothoff | Target Version | => 0.1 |
| 2016-09-22 12:12 | Christian Grothoff | Note Added: 0011134 | |
| 2016-09-22 12:13 | Christian Grothoff | Assigned To | Christian Grothoff => Marcello Stanisci |
| 2016-09-23 16:47 | Marcello Stanisci | Note Added: 0011141 | |
| 2016-09-23 16:48 | Marcello Stanisci | Note Edited: 0011141 | |
| 2016-09-23 16:48 | Marcello Stanisci | Note Edited: 0011141 | |
| 2016-09-23 21:46 | Christian Grothoff | Note Added: 0011142 | |
| 2016-09-23 22:05 | Marcello Stanisci | Note Added: 0011143 | |
| 2016-09-26 14:57 | Marcello Stanisci | Note Added: 0011167 | |
| 2016-09-26 14:57 | Marcello Stanisci | Status | assigned => informing |
| 2016-09-26 14:57 | Marcello Stanisci | Resolution | open => fixed |
| 2016-09-27 20:25 | Christian Grothoff | Fixed in Version | => 0.1 |
| 2016-10-11 15:28 | Christian Grothoff | Status | informing => closed |