Tracking Publisher Versions

Events in an audit log must be ordered

When sending events to your Audit Log, consumers of the Publisher API may send event metadata like the name and version of the vendor component that is sending the events. A minimal event payload that includes this metadata might look like

{
  "action": "user.login",
  "crud": "c",
  "group": {
    "id": "7890123",
    "name": "some.customer"
  },
  "actor": {
    "id": "123456",
    "name": "[email protected]"
  },
  "component": "authentication-api",
  "version": "ae242df"
}

Where component describes a single versioned piece of a architecture like authentication-api or spreadsheet-processor and version is usually one of

  • A git SHA of the component’s source code as in ae242df
  • A semantic version for the component as in 1.0.3
  • A build number of the component as in 129

Sending this information to the Audit Log will allow the service to give better guarantees about time windows during which an event did not occur.

Example

To better understand how this works, consider the following stream of events, in which the password.change action at 12:35 is the very first passwrd.change event seen in the Audit Log, because a recent new release of the vendor app is the first to start tracking password.change events.

action received
email.change 2017-01-01 11:14:00
user.login 2017-01-01 11:30:00
email.change 2017-01-01 12:01:00
user.login 2017-01-01 12:12:00
password.change 2017-01-01 12:35:00
user.login 2017-01-01 12:49:00
password.change 2017-01-01 12:52:00

Without any info about app versions, we can still say for certain that

  • no password.change events occured between 12:35 and 12:52.

We cannot say anything about whether or not any password.change events occurred before 12:35, because we have to assume that the vendor application was not publishing these events until we see the first one at 12:35.

action received component version
email.change 2017-01-01 11:14:00 authentication-api aeb22f1
user.login 2017-01-01 11:30:00 authentication-api aeb22f1
email.change 2017-01-01 12:01:00 authentication-api fd02eed
user.login 2017-01-01 12:12:00 authentication-api fd02eed
password.change 2017-01-01 12:35:00 authentication-api fd02eed
user.login 2017-01-01 12:49:00 authentication-api fd02eed
password.change 2017-01-01 12:52:00 authentication-api 493ef1d

Since we know the version of the component sending each event, we can know for sure that the app version that sends password.change events was sending email.change events as early as 12:01. In addition to what we knew before, that

  • no password.change events occured between 12:35 and 12:52

we now can also guarantee that

  • no password.change events occurred between 12:01 and 12:35.

Note: Being able to make these guarantees relies on an assumption that application versions change at the same time, and that there are never multiple versions of a single component running in parallel for significant periods of time. If Publisher API consumers rely on canary deploys or staged rollouts over several days, then component names will need to be rotated during the rollout.

Using SDKs

If you are using one of the official Audit Log SDKs, you can provide the version and component fields when the client is initialized, and they will be sent for every event.