View Issue Details

IDProjectCategoryView StatusLast Update
0004520Talerexchangepublic2016-05-26 14:09
ReporterFlorian Dold Assigned ToChristian Grothoff  
PriorityhighSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version0.0 
Target Version0.0Fixed in Version0.0 
Summary0004520: TALER_EXCHANGE_deposit does not distinguish between merchant and customer errors
DescriptionThe function TALER_EXCHANGE_deposit returns NULL *both* when the signatures are invalid *and* when the merchant configuration is wrong (refund_deadline.abs_value_us > wire_deadline.abs_value_us).

This means that we're telling the wallet "invalid coin signatures", when in fact the source of the problem is somewhere else (bad merchant configuration).

We need:
a) error codes to distinguish between those error cases, so we can report back correctly to the merchant and the wallet
b) logging, because this kind of issue shouldn't log something like


May 23 13:26:09-220782 taler-merchant-httpd-25945 ERROR Assertion failed at exchange_api_deposit.c:411.
May 23 13:26:09-220799 taler-merchant-httpd-25945 WARNING External protocol violation detected at taler-merchant-httpd_pay.c:613.


since it makes diagnosing these kind of issues more annoying than it should be.
TagsNo tags attached.

Activities

Christian Grothoff

2016-05-24 20:31

manager   ~0010732

I don't think this is what we want. Basically, if we return different error codes, we also need to expect the clients to handle both cases. But we really don't want to write logic to handle the expiration/edate mess, as that is already a bug.

What we should do is not return two different error codes, but in the case of the API violation be more strict and just call GNUNET_assert(). That'll give us a nice core dump showing where and how the API was violated.

Christian Grothoff

2016-05-24 20:38

manager   ~0010733

Fixed in f471cfc..079ef7c. API violations (that client could and should have checked against and prevented) now result in GNUNET_assert().

Issue History

Date Modified Username Field Change
2016-05-23 13:39 Florian Dold New Issue
2016-05-23 13:39 Florian Dold Status new => assigned
2016-05-23 13:39 Florian Dold Assigned To => Christian Grothoff
2016-05-24 20:31 Christian Grothoff Note Added: 0010732
2016-05-24 20:38 Christian Grothoff Note Added: 0010733
2016-05-24 20:38 Christian Grothoff Status assigned => resolved
2016-05-24 20:38 Christian Grothoff Fixed in Version => 0.0
2016-05-24 20:38 Christian Grothoff Resolution open => fixed
2016-05-24 20:38 Christian Grothoff Product Version => 0.0
2016-05-24 20:38 Christian Grothoff Target Version => 0.0
2016-05-26 14:09 Christian Grothoff Status resolved => closed