You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CHANGELOG.md
+14Lines changed: 14 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,5 +1,19 @@
1
1
# Release Notes for Webhooks for Craft CMS
2
2
3
+
## 2.3.0 - 2020-07-18
4
+
5
+
### Added
6
+
- Added a settings page in the control panel.
7
+
- Webhooks have a new “Debounce Key Format” setting, which can be used to debouncing similar webhook requests. ([#27](https://github.com/craftcms/webhooks/issues/27))
8
+
- Webhook URLs can now be set to environment variables or Twig code. ([#18](https://github.com/craftcms/webhooks/issues/18))
9
+
- Webhooks can now send PUT requests. ([#21](https://github.com/craftcms/webhooks/issues/21))
10
+
- The Activity page now has a “Clear” button, which will clear out all request activity for completed requests. ([#32](https://github.com/craftcms/webhooks/issues/32))
11
+
- Added a new `guzzleConfig` plugin setting, which can be set from `config/webhooks.php` to customize the Guzzle config for webhook requests. ([#31](https://github.com/craftcms/webhooks/issues/31))
12
+
13
+
### Fixed
14
+
- Fixed a bug where webhooks would lose their custom payload template when enabled or disabled from the Manage Webhooks page. ([#22](https://github.com/craftcms/webhooks/issues/22))
15
+
- Fixed a bug where the Edit Webhook page wouldn’t immediately show available filters if the webhook didn’t have any preselected filters.
Copy file name to clipboardExpand all lines: README.md
+14-2Lines changed: 14 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -42,15 +42,15 @@ To configure Webhooks, create a `config/webhooks.php` file, which returns an arr
42
42
return [
43
43
'maxDepth' => 10,
44
44
'maxAttempts' => 3,
45
-
'attemptDelay' => 120,
45
+
'retryDelay' => 120,
46
46
];
47
47
```
48
48
49
49
The array can define the following keys:
50
50
51
51
-`maxDepth` – The maximum depth that the plugin should go into objects/arrays when converting them to arrays for event payloads. (Default is `5`.)
52
52
-`maxAttempts` – The maximum number of attempts each webhook should have before giving up, if the requests are coming back with non 2xx responses. (Default is `1`.)
53
-
-`attemptDelay` – The delay (in seconds) between webhook attempts. (Default is `60`.)
53
+
-`retryDelay` – The delay (in seconds) between webhook attempts. (Default is `60`.)
54
54
55
55
## Managing Webhooks
56
56
@@ -70,6 +70,8 @@ Webhooks listen to [events](https://www.yiiframework.com/doc/guide/2.0/en/concep
70
70
71
71
The Sender Class can be a subclass of the class that triggers the event. For example, all elements fire an [afterSave](https://docs.craftcms.com/api/v3/craft-base-element.html#event-after-save) event after they’ve been saved, courtesy of their base class, [craft\base\Element](https://docs.craftcms.com/api/v3/craft-base-element.html). However if you’re only interested in sending a webhook when an _entry_ gets saved, you can set the Sender Class to [craft\elements\Entry](https://docs.craftcms.com/api/v3/craft-elements-entry.html).
72
72
73
+
Webhook URLs can be set to an environment variable (`$VARIABLE_NAME`) or Twig code. If you set it to Twig code, you can reference the triggered event via an `event` variable.
74
+
73
75
See [Integrating with Task Automation Tools](#integrating-with-task-automation-tools) for examples on how to get a Webhook URL from various task automation tools.
74
76
75
77

@@ -90,6 +92,8 @@ Some events can have filters applied to them, which prevent webhooks from being
90
92
91
93
<imgsrc="./images/event-filters.png"width="414"height="381"alt="Screenshot of the Event Filters setting">
92
94
95
+
Ignored filters (`○`) will not have any impact. Positive filters (`✓`) will be required for a webhook to execute, and a negative filter (`×`) will prevent it.
96
+
93
97
Only element class events and certain `craft\services\Elements` events have any filters out of the box, but modules and plugins can register additional filters using the `craft\webhooks\Plugin::EVENT_REGISTER_FILTER_TYPES` event.
94
98
95
99
```php
@@ -132,6 +136,14 @@ class ArticleFilter implements FilterInterface
132
136
}
133
137
```
134
138
139
+
#### Debouncing Webhooks
140
+
141
+
You can prevent multiple similar webhooks from being sent by setting a “Debounce Key Format” on your webhook. This is a Twig template that defines a “debounce key” for the webhook. If two webhooks generate the same debounce key, only the second one will actually be sent.
142
+
143
+
An `event` variable will be available to it that references the event that was triggered.
144
+
145
+
For example, if your webhook is for an entry (`craft\elements\Entry`), then you could set the Debounce Key Format to `{{ event.sender.id }}` to prevent multiple webhook requests from being queued up at the same time.
146
+
135
147
#### Sending Custom Headers
136
148
137
149
You can send custom headers along with webhook requests using the Custom Headers setting.
If you discover a security vulnerability, please review these guidelines before submitting a report. We take security seriously and do our best to resolve security issues as quickly as possible.
6
+
7
+
## Guidelines
8
+
9
+
While working to identify potential security vulnerabilities, we ask that you:
10
+
11
+
- Share any issues you discover with us via [Github](https://github.com/craftcms/cms/security/advisories) or [our website](https://craftcms.com/contact) as soon as possible.
12
+
- Give us a reasonable amount of time to address any reported issues before publicizing them.
13
+
- Only report issues that are [in scope](#scope).
14
+
- Provide a quality report with precise explanations and concrete attack scenarios.
15
+
- Make sure you’re aware of the versions of Craft and Commerce that are actively [receiving security fixes](https://craftcms.com/knowledge-base/supported-versions).
16
+
17
+
## Scope
18
+
19
+
We are only interested in vulnerabilities that affect Craft or [first party Craft plugins](https://github.com/craftcms), tested against **your own local installation of the software**. You can install a local copy of Craft by following these [installation instructions](https://craftcms.com/docs/installing). Do **not** test against any Craft installation that you don’t own, including [craftcms.com](https://craftcms.com) or [demo.craftcms.com](https://demo.craftcms.com).
- Theoretical attacks without proof of exploitability
34
+
- Attacks that can be guarded against by following our [security recommendations](https://craftcms.com/guides/securing-craft).
35
+
- Server configuration issues outside of Craft’s control
36
+
-[Denial of Service](https://en.wikipedia.org/wiki/Denial-of-service_attack) attacks
37
+
-[Brute force attacks](https://en.wikipedia.org/wiki/Brute-force_attack) (e.g. on password or token hashes)
38
+
- Username or email address enumeration
39
+
- Social engineering of Pixel & Tonic staff or users of Craft installations
40
+
- Physical attacks against Craft installations
41
+
- Attacks involving physical access to a user’s device, or involving a device or network that’s already seriously compromised (e.g. [man-in-the-middle attacks](https://en.wikipedia.org/wiki/Man-in-the-middle_attack))
42
+
- Attacks that are the result of a third party Craft plugin should be reported to the plugin’s author
43
+
- Attacks that are the result of a third party library should be reported to the library maintainers
44
+
- Bugs that rely on an unlikely user interaction (i.e. the user effectively attacking themselves)
45
+
- Disclosure of tools or libraries used by Craft and/or their versions
46
+
- Issues that are the result of a user clearly ignoring common security best practices (like sharing their password publicly)
47
+
- Missing security headers which do not lead directly to a vulnerability via proof of concept
48
+
- Vulnerabilities affecting users of outdated/unsupported browsers or platforms
49
+
- Vulnerabilities affecting outdated versions of Craft
50
+
- Any behavior that is clearly documented
51
+
- Issues discovered while scanning a site you don’t own without permission
52
+
- Missing CSRF tokens on forms (unless you have a proof of concept, many forms either don’t need CSRF or are mitigated in other ways) and “logout” CSRF attacks
To show our appreciation for the work it can take to find and report a vulnerability, we’re happy to offer researchers a monetary reward.
58
+
59
+
Reward amounts vary depending upon the severity. Our minimum reward for a qualifying vulnerability report is $50 USD and we expect to pay $500+ USD for major vulnerabilities.
60
+
61
+
A report will qualify for a bounty if:
62
+
63
+
- Our [Guidelines](#guidelines) have been followed in full.
64
+
- The vulnerability was previously unknown to us, or your report provides more information or shows the vulnerability to be more extensive than we originally thought.
0 commit comments