Improve postback documentation: #39
Conversation
melvyn-sopacua
commented
Oct 10, 2017
melvyn-sopacua
commented
- Mention that the checksum is transmitted through the Digest header
- Alter some sentences to clarify the process
- Use the word permanent to stress that failures are fatal
- Mention that the checksum is transmitted through the Digest header - Alter some sentences to clarify the process - Use the word permanent to stress that failures are fatal
Apparently I missed the checksum in the data dictionary example and figured the mechanism would be consistent with uploading a file. Fix this.
MrJoe
left a comment
MrJoe
left a comment
There was a problem hiding this comment.
Thanks for your time to make a pull request for our documentation.
Except for 25bb862#diff-64394bf08e74e8e16e2a36402516f57aL28
we won't merge the other changes.
Although your re-wording is correct we don't feel it makes it more or less obvious.
ps. our policy for markdown files is to place each sentence on its own line to reduce the number of changed lines when a change is made.
postback.md
Outdated
| ### Checksum | ||
|
|
||
| To verify that the postback responses are from SignHost you MUST verify our digital signature checksum. This signature is a hash of some parameters from the response and the sharedsecret. In order the generate the Checksum you will need a sharedsecret. | ||
| To verify that the postback responses are from SignHost you MUST verify our digital signature checksum. This signature is a hash of some parameters from the response and the sharedsecret. The checksum is transmitted via the `Digest` HTTP header. In order the generate the Checksum you will need a sharedsecret. |
There was a problem hiding this comment.
This is not correct, the Checksum is part of the (json) body.
| ### Request body formats | ||
|
|
||
| ``` | ||
| ```javascript |
There was a problem hiding this comment.
It should actually be json. However what is the advantage here specifying this as the syntax highlighting seems to happen anyway.
| In the meantime we will retry to deliver the first failed postback with an increasing interval (the first retry is within a few minutes). | ||
| After 5 successive failed attempts we will send you an email. | ||
| We will include the attachment with the received response (if any). | ||
| We will include an attachment containing the received response (if any). |
|
I reworded the bit about the failures, because:
|
|
In computer science a queue is afaik always the principle of having the oldest entry at the top.
'Mark as failed' is exact what it says. Eventually the marked as failed are indeed purged. We intend to improve this situation by manually registering a postback URL in the user portal so you are given the opportunity to mark a failed postback as retryable, although we won't keep an infinite amount of failed postbacks. So the wording 'failed' does not make it clear that it is permanent? What did you think what would happen with the failed postbacks? |
2 participants
