Java SDK: callback validation expects millisecond-based time stamp but Fitconnect sends second-based timestamps
Description of the bug:
We are implementing a service for receiving Fitconnect submissions. We would like to use the callback feature of the destinations (Zustellpunkte), so we have imlemented a REST controller to handle callback requests fired by Fitconnect. According to the documentation we expect an HTTP header callback-timestamp. We pass this timestamp, together with other parameters to the call back validation service provided by the Fitconnect SDK.
However, it turns out that the validation code in dev.fitko.fitconnect.core.validation.DefaultValidationService expects the timestamp to be in milliseconds, whereas the timestamp received in the callback requests is second-based.
Of course, we cannot simply pass timestamp*1000 to the validation service because the timestamp is also part of the HMAC which is reconstructed and compared to the HMAC also received in the request. This subsequent check fails if we convert the timestamp.
At the moment, we help ourselves by overwriting the DefaultValidationService.validateCallback().
Beside this bug, I would like to recommend to extend the SDK and documentation for the callback usecase. It would help, for instance, to have a DTO class for the payload provided by the callback and a callback demo in the demo application.
Thank you, Kind regards, Rainer
Current behavior:
Expected behavior:
Environments:
Additional Information:
Dependency / relationship to other issues:
Responsible person / team:
Contact persons including contact details:
Screenshots / Logs / Requests:
Checklist:
-
Add Severity label -
Add team label -
Related/affected issues/stories/epics linked and explained in the bug issue -
Creation of an automated test -
Bugfix deployed on DEV -
Bugfix tested on DEV -
Bugfix deployed on TEST -
Bugfix tested on TEST (possibly also by the connection project itself) -
Successful fix reported to Team Operations (Teams channel) -
Bugfix deployed on STAGE -
Bugfix tested on STAGE if necessary -
Bugfix deployed on PROD -
Bugfix tested on PROD (possibly also by the connection project itself) -
Final communication by Team Operations if necessary -
Internal documentation was checked and updated if necessary -
External documentation has been checked and updated if necessary -
Updated changelog if necessary