Webhooks

Webhooks allow client applications to be notified via HTTP post requests when data changes in PageSeeder. A webhook can be configured to only send requests for certain event types, projects, groups or for server events, so it can be tailored to specific client applications.

Events

The following event types are supported by webhooks:

Admin

• webhook.ping

Group or project events

• comment.created
• comment.modified
• comment.archived
• comment.unarchived
• comment.deleted
• group.deleted, group.archived, group.modified
• groupproperties.modified
• groupfolder.created, groupfolder.deleted, groupfolder.modified
• membership.created
• membership.modified
• membership.deleted
• publication.created
• publication.modified
• publication.deleted
• task.updated (changes to any <task> attributes or content)
• workflow.updated (changes to any <workflow> attributes or content)
• uri.created (includes upload)
• uri.modified (includes move, edit, etc. - any time uri/@lastmodified is changed)
• uri.archived
• uri.deleted

Project events

• group.created
• project.deleted, project.archived, project.modified

Server events

• member.created
• member.modified
• member.deleted
• project.created

A uri/comment/task move between groups and a group/project rename produce a deleted and possible created (and modified for uri) event with the relevant groups for each.

A task/workflow/external URI change will produce a separate event for each group as the content for each group can be different.

Requests

• Webhook POST requests can be in XML or JSON format (shown below).
• Each request contains one or more webevents.
• Each webevent contains zero or more event groups (these are the PageSeeder groups the event affects).
• Each webevent will also contain an object in either minimal (private and public IDs only) or basic format depending on the webhook configuration.
• For delete events the object will always have minimal format.

See Element reference for details on the XML elements below.

XML format

<webevents>
    <webhook id="123" [name="xyz"] />
    <webevent id="[object id].[nano time]"
              datetime="2012-11-23T22:35:12+10:00"
              type="[object].[action]">
        <event>
            <group id="" name="">
           [<group .../> ...]
        </event>
        <webhook|uri|comment|task|workflow|membership|member|...
              id=""
              [name="[group name]"]
              [docid=""] [path=""]
              [username=""]
              [email=""]
              [...]>
            [...]
        </...>
    </webevent>
    ...
</webevents>

The publication.* events are generated for any URIs added to the publication or already in the publication which are modified, removed or deleted. They are represented in the web event XML as follows:

<webevents>
    <webhook id="123" [name="xyz"] />
    <webevent id="[object id].[nano time]"
              datetime="2012-11-23T22:35:12+10:00"
              type="publication.modified">
        <event>
            <group id="" name="">
        </event>
        <publication id="mypub1" ... >
          [<added>
            <uri ... >...</uri>
            ...
          </added>]
          [<modified>
            <uri ... >...</uri>
            ...
          </modified>]
          [<removed>
            <uri ... >...</uri>
            ...
          </removed>]
          [<deleted>
            <uri id="123" />
          </deleted>]
        </publication>
    </webevent>
    ...
</webevents>

JSON format

{
  "webhook": {
    "id" : "123", 
    "name" : "xyz"
  },
  "webevents": [
    { 
      "id": "[object id].[nano time]", 
      "datetime": "2012-11-23T22:35:12+10:00", 
      "type": "[object].[action]",
      "event": [
        {"id":"", "name":""}
      ], 
      "webhook|uri|comment|task|...": {
        ...
      }
    },
    ...
  ]
}

Configuration

Webhooks can only be configured by PageSeeder administrators using the Web service API or the user interface by selecting the Admin > Client admin page and following the steps below.

Step 1: Create a client

On the Client admin page click the Clients button and then on Register new client. Enter the details required and click Register.

Most of the details are related to OAuth  configuration so that the client application can also connect to PageSeeder and access data.

If a Webhook secret is entered it will be used to sign all POST requests to this client with an HMAC of the request body and send it in an  X-PS-Signature HTTP header. This is so the application can verify the POST is coming from PageSeeder. Below is an example Java code snippet that could be used to check the signature:

import org.pageseeder.bridge.util.Base64;
...
SecretKeySpec key = new SecretKeySpec(
  webhook_secret.getBytes(StandardCharsets.UTF_8), "AES");
Mac mac = Mac.getInstance("HmacSHA1");
mac.init(key);
String signature = new String(Base64.encode(mac.doFinal(body)));

Step 2: Start the client application

When a webhook is created it will immediately send a webhook.ping event POST to the URL for the webhook. If the client application replies with HTTP 200 and HTTP header X-PS-Secret set to the same value as was sent in that header on the POST, then the webhook status will change from "pending" to "active".

This confirms that the client wishes to receive webhook POST requests from PageSeeder and helps guard against PageSeeder sending unwanted or SPAM requests. It is similar to the immediate confirmation mechanism described here http://resthooks.org/docs/security/ .

Therefore, it is a good idea to ensure the client application is running before creating a webhook. If it is not, a webhook.ping event can be initiated later from the  Client admin > Webhooks page once the application is accessible (this will update the status as above).

Step 3: Create a webhook

On the Client admin page, click the Webhooks button and then on Register new webhook. Choose the client, enter a URL plus other details (see below) if required and click Register.

• Object type: minimal – means that only private and public IDs will be returned for the object (no other content). This includes no attributes for groupproperties, id only for comment, task, workflow, membership and the following:

• uri: id, docid, path

• member: id, username, email

• groupfolder: id, path

• group: id, name

• project: id, name

• webhook: id, name

• Support insecure SSL – means that the SSL certificate will not be checked when sending requests. This can be useful for development servers but should not be used for production.
• Event filters – means the events that will be sent to this webhook. Multiple event types can be specified by selecting different event types repeatedly.
• Include server events – means include the following events which are not specific to a project or group: member.created, member.modified, member.deleted, project.created.

Check the Webhooks page to ensure the webhook has a status of "active". Event POST requests will only be sent to "active" webhooks.

Troubleshooting

Below are the possible status values for a webhook and the remedies required:

If any webhooks have status warning, unreachable or error they will be displayed on the Admin > Console page. View the Recent logs to see detailed messages.

Webhook caches

The following message may appear on the Console page:

The webhooks caches were corrupted probably due to an unclean shutdown so unprocessed events before the shutdown will not have been sent (see general logs).

In this case, view the General logs for the day the server was shutdown and look for the following lines in the general log to see if there were any unprocessed events. If any numbers are non-zero or these lines are missing, the client application caches may need to be cleared or updated for the missing events.

There was 0 unprocessed webhook events at shutdown.
There was 0 unprocessed webhook jobs at shutdown.
There was 0 unprocessed failed webhook jobs at shutdown.

The contents of the webhook caches can be viewed under the Cache section of the Admin > System info pages. Click on info next to the webhook-events, webhook-failed-jobs or webhook-jobs cache, then click on each entry to see detailed information.

Failed POST requests

Below are the rules used to process failed POST requests to a webhook URL.

• If POST fails with 3xx or 410 error set webhook status to unreachable and stop sending to that webhook.
• If POST fails with 4xx, 5xx or other error increment RetryNumber and retry again using exponential backoff after 2retries x 10 seconds (e.g. 10s, 20s, 40s, 80s, ... ~12 hrs for webhookRetries=12). Also set webhook status to warning.
• If RetryNumber > webhookRetries (see below) set webhook status to unreachable and stop sending to that webhook

Global properties

If there are issues with memory, performance or failure processing the following global properties can be adjusted to modify the system.

Created on 19 December 2017 , last edited on 27 April 2020 at 10:07