Documentation
¶
Index ¶
Constants ¶
const (
DefaultTransferAction = "default"
)
const Timeout = 30 * time.Second
Variables ¶
var ( ErrIdentityRequired = errors.New("identity payload is required in webhook response") ErrTransactionRequired = errors.New("pending or transaction payload is required in webhook response") )
var (
ErrInvalidHMACToken = errors.New("invalid authorization hmac token")
)
var MockConfig = config.WebhookConfig{
URL: mockURL,
}
Functions ¶
This section is empty.
Types ¶
type HMAC ¶ added in v1.0.0
type HMAC struct {
// contains filtered or unexported fields
}
HMAC implements an authorization header to authenticate webhook requests using a similar shared secret mechanism as AWS4-HMAC-SHA256 as defined here: https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-auth-using-authorization-header.html
Create an HMAC object with a 32 byte key and a string that represents the key ID. Headers then must be appended to the HMAC in order to generate the data to sign. Once signed, an HMAC-SHA256 signature is generated and can be used to create the Authorization header.
func (*HMAC) Append ¶ added in v1.0.0
Add the header and the header value to the HMAC object. Note that the order that the headers are added is important as the values will be appended without modification to the data to be signed. If the header is already present, it will not be added again. Headers are stored as lowercase values.
func (*HMAC) Authorization ¶ added in v1.0.0
Authorization returns the full Authorization header that can be added to the request headers of an outgoing webhook request.
func (*HMAC) Headers ¶ added in v1.0.0
Headers returns the semicolon list of request headers used to compute the signature. The list includes header names only, and the header names must be in lowercase. The order of the headers indicates the order the data was appended to create the signature.
type HMACToken ¶ added in v1.0.0
type HMACToken struct {
// contains filtered or unexported fields
}
HMACToken is parsed from an Authorization or Server-Authorization header and is used to verify the signature of a webhook request.
type Mock ¶
Mock implements the webhook Handler and is used for testing webhook interactions.
func (*Mock) UseFixture ¶
type Payload ¶
type Payload struct {
Identity *ivms101.IdentityPayload `json:"identity"`
Pending *generic.Pending `json:"pending,omitempty"`
Transaction *generic.Transaction `json:"transaction,omitempty"`
Sunrise *generic.Sunrise `json:"sunrise,omitempty"`
SentAt string `json:"sent_at"`
ReceivedAt string `json:"received_at,omitempty"`
}
Payload is a denormalized representation of a TRISA payload that includes type-specific data structures. The payload should always have an identity IVMS101 payload and a sent at timestamp. It will have either a pending message or a transaction but not both. If payload is in an envelope with an accepted or completed transfer state it will have a received at timestamp as well.
type Reply ¶
type Reply struct {
TransactionID uuid.UUID `json:"transaction_id"`
Error *trisa.Error `json:"error,omitempty"`
Payload *Payload `json:"payload,omitempty"`
TransferAction string `json:"transfer_action,omitempty"`
}
Reply represents the expected response from the callback webhook to the Envoy node. Either an error or a pending message is returned in the common case, though Envoy will also handle synchronous compliance responses.
func (*Reply) TransferState ¶
func (r *Reply) TransferState() trisa.TransferState
Determine the API transfer state based on the reply
type Request ¶
type Request struct {
TransactionID uuid.UUID `json:"transaction_id"`
Timestamp string `json:"timestamp"`
Counterparty *api.Counterparty `json:"counterparty"`
HMAC string `json:"hmac_signature,omitempty"`
PKS string `json:"public_key_signature,omitempty"`
TransferState string `json:"transfer_state,omitempty"`
Error *trisa.Error `json:"error,omitempty"`
Payload *Payload `json:"payload,omitempty"`
}
The Request object is sent to the webhook via a POST http call. The request represents an incoming message to the server as an unsealed, decrypted secure envelope (whether the request came from a TRISA or TRP remote client). The request is guaranteed to have a transaction ID, timestamp, and counterparty. If it has a payload, then it will also have an HMAC signature and public key signature. Requests will have either errors or payloads, but not both.