add time based MatchRule

[foosinn]

Using a time based match rule would allow payload-hash-* secured hooks that are only valid for a configurable amount of time.

Using those would prevent a captured hook call once more, even if it has been payload-hash verified.

[moorereason]

@foosinn,
If you're asking about rate-limiting hook executions, this is a duplicate of #120. It was closed because @adnanh didn't have time to implement it back then even though @antoineco seemed to suggest he might submit a PR. ?

This probably is a useful feature for many, but we need to flesh this out into a proposal. If we can agree on the proposal, we can label this issue as help wanted and hope someone has the time and inclination to implement it. So...

Proposed Feature

• Add a rate-limit Hook property.
• The value is a time.Duration string (will be parsed by time.ParseDuration). Example: 90s.
• Used to rate limit the execution (not evaluation) of hook requests. Check rate limiting after trigger rule evaluation was successful.
• HTTP response code during rate limiting will be 429 (http.StatusTooManyRequests).

Sample Configuration

[
  {
    "id": "webhook",
    "execute-command": "/home/adnan/redeploy-go-webhook.sh",
    "command-working-directory": "/home/adnan/go",
    "rate-limit": "90s",
    "trigger-rule":
    {
      "match":
      {
        "type": "ip-whitelist",
        "ip-range": "104.192.143.0/24"
      }
    }
  }
]

[antoineco]

Indeed, I wanted to implement a rate-limiting hook which seems to match the description, but never got an answer and eventually stopped using webhook (for other reasons), so I never got the motivation to invest the time.

[foosinn]

No this is not about rate limiting.

I if did understand the docs correctly a person that manages to capture the webhook call can resend it anytime. Its possible to secure webhooks by using payload-hash-*, but this only verifies the content. If he sends the same content a potential attacker is able to rerun the webhook.

Or did i miss something?

[moorereason]

Sorry, I wasn't sure exactly what you meant. "Time based" sounds like rate limiting so assumed that's what you meant.

Can you please flesh out your request? Can you offer an initial proposal of exactly how this feature would be used and how it would work? How is it different from the general rate-limiting case?

[foosinn]

• The request has just a header field with the current unix time and is with a payload-hash-sha256 singed.
• Webhook checks if the time is unix timestamp is not older than a user configurable timestamp and verifies the payload-hash.
• If someone would resend that request the time is not matching anymore, even if the payload-hash is still correct.

This is not intended to do rate-limiting, its more like an additional access protection. Since we are using the payload hash the password itself is not submitted in the request.