Skip to main content

Test event subscription access

Before you rely on Events in production, confirm on a development site that only the right people can change subscriptions.

Before you start#

  • An app with at least one function (FUNCTION_ID).
  • Two credentials on the same site:
    • a site user token — an ordinary user of your application;
    • an API key from an organization owner or admin.

Site users can't change subscriptions#

As the site user, try to subscribe:

POST/api/cloud/events/RECORD_CREATE/subscribe/

X-Session-Token
$SITE_USER_SESSION_TOKEN
Content-Type
application/json
{
"function_id": "$FUNCTION_ID"
}
View cURL
curl --silent --show-error -X POST "$TARUVI_SITE_URL/api/cloud/events/RECORD_CREATE/subscribe/" \
-H "X-Session-Token: $SITE_USER_SESSION_TOKEN" \
-H "Content-Type: application/json" \
--data-binary @- <<JSON
{
"function_id": "$FUNCTION_ID"
}
JSON

403An ordinary site-user session cannot create subscriptions.

Expected: 403 Forbidden, and no subscription is created.

Repeat with POST .../unsubscribe/ and GET /api/apps/APP_SLUG/events/RECORD_CREATE/. Each returns 403 for the site user.

Owners and admins can manage subscriptions#

With the owner or admin API key:

  1. POST /api/cloud/events/RECORD_CREATE/subscribe/ with {"function_id": FUNCTION_ID} returns 201 Created.
  2. GET /api/apps/APP_SLUG/events/RECORD_CREATE/ returns 200 OK with total_subscribers of at least 1.
  3. POST /api/cloud/events/RECORD_CREATE/unsubscribe/ returns 200 OK, and step 2 then shows the function is gone.

Anyone signed in can list events#

GET /api/cloud/events/ returns 200 OK for both credentials, with names such as RECORD_CREATE in data.events.