Closed Bug 1588661 Opened 3 years ago Closed 2 years ago

Implement Webhooks

Categories

(bugzilla.mozilla.org :: General, enhancement)

Production
enhancement
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: emceeaich, Assigned: lisset.cuevasj)

References

(Blocks 1 open bug)

Details

This bug is the discussion for the WebHooks design.

Design requirements:

  • Don't leak information about security bugs
  • Leverage existing infrastructure for notifications
  • Keep it simple

Remember that a WebHook is a URL which an application will POST to on a given event.

A user should be able to set a WebHook URL for a change to a bug or a bug list.

In order to address security concerns, the payload sent to the WebHook's endpoint should be minimal, and the consumer will be responsible for fetching the change.

Scope questions:

  • Can a user set a WebHook for a product or component so they are notified about new bugs?
  • Can a user set up a WebHook through an API (this would be useful for many of our client applications?)

WebHook POST BODY

Should the BODY of the post to a WebHook be a list of all the bug ids the user has set up hooks for which have changes over a given period of time?

{
   "bugs": [ "bug_id", "bug_id", ... ]
}

The user would then fetch the bug and pick up the changes.

Or should it be a list of URLs, for a single use capability, which when sent an authenticated request, as the user who set the WebHook, will return the changes to the bug.

{
  "changes": [ "URL", "URL", ... ]
}
URL + Auth  =>
{
  "bug_id": "NNNNN",
  "changes": [ { ... }, { ... }, ... ]
}

I propose that we build off of the existing Push extension work as it has quite a bit of the framework needed already in place. Most of the work would be creation of the new tables to store the user specific data such as self-service of adding their own web hooks. This will need adding on to the Push extension as well as creation of a new extension called 'WebHooks'.

Push Extension

  • The Push extension allows for adding 'connector' modules that handle the decision on whether to send or not, and how to communicate with the external service.
  • The WebHooks connector in the Push extension will know about the WebHooks database tables and will determine from the user data whether a bug matches the trigger criteria and will get the URL that it needs to POST the data to.
  • The base Push framework will create a JSON structure of the bugs current state and whatever changes are made to the bug for that single transaction.
  • The Push framework also handles filtering of the JSON data based on whether the bug is public or not. If the bug is private, only the bug id and some other basic information is sent and the external system will need to query BMO over the REST API to get the actual details of the change(s).

WebHooks Extension

  • The WebHooks extension will handle the creation of the database tables, user preferences, and store the URL information for each webhook created by a user.
  • HTML page will be displayed allowing the user to specify the trigger criteria that will cause a bugs data to be sent to the URL.
  • In the beginning we could model this after the ComponentWatching extension in that we set up that a bugs data will be sent if the bug matches a product and/or component in BMO.
  • We could also maybe add some other specific cases where data is sent only if the status changes, or a comment is made, etc.
  • We do not need to handle every single condition that people can come up with. The external system itself can also decide whether to act on the data send or simply drop it.
  • We should also wrap the whole thing in a BMO security group that a user will need to be a member of in order to use webhooks. We can start small and work up to more people as we work out any issues or performance problems. It doesn't need to be available to 'everyone' IMO.

For the database table structure I would propose looking at the tables defined for component watching and build off of those using a naming structure like 'webhooks_*' for the names. Of course we will need a table that maps the URL that will be POSTed to to the user id in BMO.

Basic support for webhooks has landed in master. Additional bugs have been filed for further enhancements. Thanks to Lisset for all of her hard work on this and to the Outreachy program for sponsoring it.

Assignee: nobody → lisset.cuevasj
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED

Much πŸ’– to Lisset and :dkl for y'all's work on this!

Duplicate of this bug: 1292698
Duplicate of this bug: 1588662
Duplicate of this bug: 1588663
Summary: Design for WebHooks → Implement Webhooks
You need to log in before you can comment on or make changes to this bug.